Talk:Comparison of C Sharp and Java
General discussion and enums
How does Java have a simpler language? The CLR has some JIT time optimizations as well as runtime optimizations. Java and C# run at about the same speed really. It might not be true that Java is faster.
The article needs to be cleaned a bit... Some entries are listed as both advantages for one language and disadvantages for the other, which is at best redundant. Otherwise, it's not bad; quite complete now. GregorB 22:49, Jan 31, 2005 (UTC)
I think there is good reason for pointers to be listed as both an advantage and a disadvantage for C#. I don't think there exists enough consensus about whether pointers should be used in managed languages. It might be appropriate to go into more detail about how pointers are implemented with relative safety in C# on another page and then link it. Tbjablin 05:36, 8 Feb 2005 (UTC)
I've decided it belongs in differences after all. Tbjablin 05:44, 8 Feb 2005 (UTC)
- Both languages allow the use of enumerations, via the
enumkeyword.
As far as I recall, this is false. C# uses the enum keyword, whereas Java uses a Class (link java.lang.Enum) introduced in Java 1.5. I haven't edited the page to reflect this, as I am unsure and would like confirmation first.
In Java 5.0 enums are lower case, like types, and have their own syntax.
private enum Coin {
penny(1), nickel(5), dime(10), quarter(25);
Coin(int value) { this.value = value; }
private final int value;
public int value() { return value; }
}
Also enums can be used in switches. Classes cannot be used this way.
switch(menu) {
case FILE:
System.out.println("FILE Menu");
break;
case EDIT:
System.out.println("EDIT Menu");
break;
case FORMAT:
System.out.println("FORMAT Menu");
break;
case VIEW:
System.out.println("VIEW Menu");
break;
}
Check out http://java.sun.com/developer/technicalArticles/releases/j2se15langfeat/ http://zamples.com/JspExplorer/samples/jdk1_5.jsp http://java.sun.com/j2se/1.5.0/docs/guide/language/enums.html
In Java even arrays are technically classes ie
Object o = new int[10];
Further compiling:
public class Test {
private int enum = 10;
}
Yields the error:
Test.java:2: as of release 1.5, 'enum' is a keyword, and may not be used as an identifier
(try -source 1.4 or lower to use 'enum' as an identifier)
private int enum = 10;
^
1 error
My inclination is to call it a keyword, because of the new syntax, and the compiler error. Tbjablin 04:34, 9 Mar 2005 (UTC)
- Yeah, it seems pretty clear that
enum is a keyword in Java. Neilc 01:08, 10 Mar 2005 (UTC)
Keyword or not, enum is a feature of all (or nearly all?) programming languages in the C language family, and as such is uninteresting in this context. I've deleted the reference, hope that's OK... GregorB 12:37, Apr 29, 2005 (UTC)
Virtual machine?
C# is compiled to MSIL which is compiled into native machine code; Java is compiled into .class files which are interpreted by the JVM. The article says they both run on a virtual machine, but C# does not. I ran a series of benchmarks which I posted here and am quite sure that C# is appreciably faster than Java.
Both C# and Java use JIT compilation. Java can run in interpretted mode and even has a flag for it
java -Xint, but java -Xmixed (interpretted mode mixed with compilation) is the default. You might want to try rerunning your benchmark with java -server -Xincgc -Xmx512M and Java 1.5 Tbjablin 01:25, 24 Apr 2005 (UTC)
Also, looking at your benchmarks they are quite clearly dominated by Java's slow startup time. You might consider benchmarks that run for atleast a minute. Compare your results with [[1]] at that time Java was outprerforming C# in every area except trig performance, but things may have changed since then. Tbjablin 01:33, 24 Apr 2005 (UTC)
So I tried to repeat your benchmark. Here's what I found:
cat Test.java
public class Test {
public static void main(String[] args) {
long time = System.currentTimeMillis();
for(int i = 1; i < 1000000000; i++) {
}
System.out.println((System.currentTimeMillis() - time));
}
}
java -hotspot Test
1612
java -server Test
3
Tbjablin 03:05, 24 Apr 2005 (UTC)
Event Handling?
I'm not sure if your observation is correct about event handling. In java one ActionListener can listen to many different UI elements. I think that the net result is the same as in C#, and that the difference is really semantic. Tbjablin 02:28, 24 Apr 2005 (UTC)
I think this link supports my point: [[2]]
--Agreed, the only difference between the use of event handling in Java vs C# is simply an overloaded operator. --capnmidnight
- I have to put back at least initial sentence. I left out the other junk about it streamlining code and running faster (I totally support this omission). However, I think it is an (arguably) advantage--albeit minor-- that
event is a C# keyword. If you edit this, at the very least just remove it from "advantages". It is certainly a valid difference. -- Chris 03:14, 29 August 2005 (UTC)
Method invocation of Java is simpler than C#?
The article states about Java:
"Method invocation model is simpler, making it easier to implement and at times easier to read."
Maybe it's just me, but I don't see the difference between
javaObject.methodCall()
and
csharpObject.methodCall()
Am I missing something? Maybe you are talking about the "best practice" of capitalizing method names. This is not a feature of C# any more than creating meaningful variable names, or using for loops instead of while loops, i.e. it's up to programmer preference.
"C# includes delegates, whereas Java does not. Some argue that delegates are extremely useful, but others point out that their inclusion complicates the method invocation model." This is what that line was refering to. I didn't understand it when I read it either, so I changed it. Hopefully, it is clearer now. Tbjablin 05:02, 24 Apr 2005 (UTC)
- What do you understand by "method invocation model"? Is it compile-time or run-time? If you say compile-time, I agree, the same syntax/grammar is used to call a delegate and to call a single method. If you say run-time, I disagree, because by then it will either iterate the delegate OR call the method, it won't decide which to do at run-time because that's already hard-coded. So, you MUST clear which do you mean, compile-time or run-time. I suggest renaming it to "method invocation syntax", assuming compile-time since in run-time it's nonsense to say it's simpler in Java.
- Did you read the link at the bottom of the discussion? [3] The author has evidence that delegates use relfection implicitly, and that they are not simply pointers to functions. If you can produce some disassembly that disagrees with his results, or can explain his results, I would be very interested.
--In that case, delegates don't complicate the model, they expand the model. One can completely ignore delegates and still be a quite succesful coder in C#. I think it gives a false impression that C# is more difficult to learn than Java. While it will certainly take you longer to learn completely (since there are more language-level features in C#), base functionality in both languages is a nearly identical task.
If anything, if we define a task T that is particularly suited to being implemented with a delegate pattern, then Java is technically more complicated. One would have to use a lot of interfaces, annonymous inner classes, and the Reflection API to achieve all the same things that delegates achieve very easily. I shudder to think of the ugly hack that would result from trying to reimplement delegate concatenation in Java.
This is the same arguement that C zealots make against C++, that C++'s inclusion of additional keywords made it a more complicated, and more difficult to learn. It's just not true, more language features make languages easier. We invent new langauges to make our jobs as programmers easier, not to make them more difficult. Imagine if your speaking vocabulary were cut in half, would you be able to express yourself as easily?
Delegates are there if you know how to use them, and they sit out of the way if you don't. They're not there at all in Java, so even if you know how to use them, you're out of luck.
--capn_midnight
I think the criticism is that determining which method is actually called at run-time more complicated, and can incur a performance hit. Check this out [4], but I guess all OO features are more complicated than just calling static function. Tbjablin 13:16, 25 Apr 2005 (UTC)
Switching Strings
Just throwing a question out there: should we mention that C# allows for strings to be used in switch statements? It is a minor feature, but it is a difference. Does Java have this yet? DoomBringer 08:12, 8 May 2005 (UTC)
- Java does not support switching on strings. It seems like a minor feature to me though. Also, does C# support just switching on Strings, or switching on all Objects? Tbjablin 13:26, 8 May 2005 (UTC)
- C# Language Specification lists "possible governing types" of a switch statement as: sbyte, byte, short, ushort, int, uint, long, ulong, char, string. Switching on strings would thus be the only difference compared to Java. Not a groundbreaking feature, but it's very useful nonetheless... GregorB 11:13, May 9, 2005 (UTC)
- I would say that it is a noteworthy feature. Any neato feature like that prevents me from doing a huge if-elseif-... construct, which can get ugly. The claim was made that switching on a string in C# isn't as horrible for performance as some would think, but I don't know the underlying implementation, so I can't say for sure. I just know that I like being able to switch on strings. DoomBringer 07:09, 18 May 2005 (UTC)
I've added it, since no one had any issues here. If you feel otherwise, post something here first.
ROTOR mention?
Should we mention the ROTOR implementation of the CLI? You can run .NET code on BSD Unix (I think), and it is "shared source". It isn't a feasible enterprise solution, as I think the license prohibits it, IIRC. DoomBringer 07:14, 18 May 2005 (UTC)
Call by reference
Note that call by reference doesn't apply just to primitive types, as it might seem at first sight. Variables in Java which are not of primitive types hold a reference to an instance, and since all method calls pass arguments by value, the reference held by the variable is passed, since that is the value of the variable. But imagine you want the variable to "point" to another instance after the method returns; then you have to pass a reference to the variable itself, not the reference the variable holds.
A non-pragmatic but straight example in C#:
void ChangeVariable(ref string s) {
s = "-+" + s + "+-";
}
void SeeChange() {
string s = "Test";
ChangeVariable(ref s);
Console.WriteLine(s);
}
Output:
-+Test+-
I see your point. Perhaps a better example is:
void ChangeVariable(ref string s) {
s = "Test";
}
void SeeChange() {
string s;
ChangeVariable(ref s);
Console.WriteLine(s);
}
The point is that Java lacks what would be "<class_type>** name" style pointers to pointers in C++.
Tbjablin July 3, 2005 04:48 (UTC)
'Enormous and highly active user base'? NPOV ... need numbers vs C#
This language is not neutral, is vague, and does not go toward the point of the article. If the user base is 'enormous' and 'highly active', it must be assumed that this is in contrast to that of C#. Does anyone have a citation?
Measuring the user base of a language is incredibly hard. You can look at the number of published C# books versus the number of Java books on Amazon. So "Java language" yields 2k hits versus 400 hits for "C# language." Alternatively if you look at Google hits for the same query its 29M hits versus 3M hits. MSN shows 36M hits versus 250K hits. Sourceforge records 16K Java projects and 2.5k C# projects. All of these samples are subject to error and source bias, but they all seem to indicate that the number of Java developers is substantially larger than the number of C# developers. The statement is somewhat vague because although no one knows the real numbers, we can still make comparisons between the two user bases. The point of the article is a comparison of C# and Java. One of the ways that the languages differ is that Java seems to have a greater mindshare.
Tbjablin
- All good points. And I like your 'large' change. Thanks for the response. -- Chris 18:58, 2 August 2005 (UTC)
Speed comparison in Java SE 5.0 and .NET 2003
C# is a bit faster then Java and significant faster in nested loops (like matrix multiplication). Also, GUI might be much faster in C# then in Java.
Performance comparison C++, C# and Java
LZMA implementation speed comparison
I think this piece of text needs significant revision, and may not be appropriate to the article. The basic premise of the first sentence is that C# is faster than Java in nested loops, but this is contradicted by both of the links the author provides. Furthermore, the links appear to be microbenchmarks, the results of which are frequently not born out in more detailed studies. These tests can be dramatically influenced by how many times a compiler unrolls a tight loop. Also, the first benchmark is of the hotspot client vm, which is much slower than the server version for many tasks.
What exactly is the comparative performance of two languages? Basically, any sort of comparison will be between particular compilers, particular VMs, and particular machines. The language itself doesn't enter into the equation.
If we are going to make a comparison between Java and C# based on performance it should be well-researched position. It would talk about what specific parts of Java or C# effect performance, based on results that are repeatable, significant, and generalizable across the range of supported platforms. For example: Java's floating point implementation is slower than C#'s because Java guarantees the results of floating point calculations across platforms and therefore does not use special hardware.
The second sentence appears to be speculation.
Tbjablin 07:12, 17 August 2005 (UTC)
Major Reorganization
I just made a big change to the article, in response to concerns raised on the AFD page. Most of the facts in the original article were kept, but their order and sometimes their wording was changed. In some cases two bullets were merged. Please flame me under this heading if you do not like it. Tbjablin 00:25, 19 October 2005 (UTC)
AfD result
This article was nominated for deletion on October 18, 2005. The result of the discussion was keep.
— JIP | Talk 10:32, 25 October 2005 (UTC)
Changed name from Comparison of C Sharp to Java
Changed name to use more neutral language. – Doug Bell talk•contrib 05:10, 6 March 2006 (UTC)
Cleanup tags
I've tagged this page with three cleanup tags: advert, importance, and tone.
- Advert: This article has a strong pro-C# bias.
- Importance: What information does this article provide that is not available in C Sharp or Java programming language?
- Tone: Most encyclopedias avoid direct comparisons of subjects, and for good reason. Rather than a prosaic discussion of fundamental differences, this page seems to provide large bulleted lists of features of dubious importance.
—donhalcon╤ 05:38, 6 March 2006 (UTC)
- Advert: Does the page really have a C# bias? I think it is a neutral fact that C# has more features than Java. Whether or not more is better and whether the features are actually useful is left to the reader.
- Importance: I'm willing to concede that the article contains no information not found in C Sharp or Java programming language, but that's true of all comparison articles.
- Tone: The article is more encylopedic than Comparison_of_browsers, but that isn't setting the bar particularly high. It's substantially similar to Comparison of Java and C++, which I see you've also marked for cleanup. I suppose we might look to Abrahamic religion as an alternative model.
- I think it might be a worthwhile experiment to convert parts of the article to prose. Maybe over the weekend if I have time. Tbjablin 05:34, 7 March 2006 (UTC)
- I think I'm going to AfD "Comparison of web browsers" soon, so that bar is a bit too low. Abrahamic religion is a good model; a page already exists with that potential for this article and Java/C++ at curly bracket programming languages, so maybe we could merge some of this content over there. Comparative content has potential, it just needs to be encyclopedic — and preferably more concise that one article per possible pair of languages. —donhalcon╤ 05:56, 7 March 2006 (UTC)
- If Comparison of Web Browsers then why not Comparison of linux distributions or Comparison of operating systems. I think there exists an unwritten policy that comparison type article are held to a different standard. List of countries by GDP (PPP) is a really a comparison article too. I think that for a certain class of articles a gazeteer type standard of quality is more appropriate and consistant with the defacto standard. Tbjablin 06:52, 7 March 2006 (UTC)
- Actually to be consistant you should AFD everything in [5], some of those articles have less prose than Comparison of web browsers. Tbjablin 06:55, 7 March 2006 (UTC)
- There is no unwritten policy that says that Wikipedia policies don't apply to certain articles; lists have historically been accepted as a way to index the encyclopedia, not as a separate space for content (WP:NOT deals with indiscriminate lists explicitly). I don't believe that poor quality should be excused in an encyclopedia article just because it doesn't belong in an encyclopedia in the first place.
- I already did (successfully) AfD list of multi-threading libraries, which was strikingly similar to comparison of web browsers; I will almost certainly AfD the other unencyclopedic lists you've mentioned and many others as I work to clean up Category:Comparisons. I've already tagged a significant fraction of Category:Programming language comparison for cleanup and fully intend to AfD anything in it that can't be turned into content that belongs in an encyclopedia. The tags are there to let people know that the articles either need some serious work to reach encyclopedic quality, or need to be merged out to the articles where their content actually belongs — I have nothing against including the content, it just needs to meet basic standards of quality, and it needs to be in an appropriate ___location. —donhalcon╤ 07:17, 7 March 2006 (UTC)
- I've looked at list of multi-threading libraries and I think it was at all similar to comparison of web browsers. I think you should AFD comparison of web browsers immediately, because it will provide useful precedent for what is or is not considered a quality list. WP:NOT does deal directly with the subject of indiscriminate lists, but I don't think that these comparisons fall under that clause, but I could be wrong. If Comparison of web browsers dies in AFD then we should add a new clause to WP:NOT specifically damning non-prosaic technical comparisons. Tbjablin 07:54, 7 March 2006 (UTC)
- I'm in the process of listing it now, but I don't think that result will necessarily set any kind of precedent, nor would its deletion entail revisions to existing policy — WP:NOT already excludes indiscriminate collections, FAQs, instruction manuals, and original research, which I think are sufficient to cover a large portion of Category:Comparisons. —donhalcon╤ 14:46, 7 March 2006 (UTC)
- Which of those items (indiscriminate collections, FAQs, instruction manuals, or original research) do you think comparison of web browsers is? Tbjablin 20:33, 7 March 2006 (UTC)
- That's fairly irrelevant here, considering that this is the talk page for Comparison of C Sharp and Java. —donhalcon╤ 20:47, 7 March 2006 (UTC)
- I think the consensus that is forming at Wikipedia:Articles_for_deletion/Comparison_of_web_browsers and Wikipedia:Articles_for_deletion/Comparison_of_Internet_forum_software would be relevant for nearly all the pages in Category:Comparisons. Tbjablin 20:54, 7 March 2006 (UTC)
- Could be, but even if they still exist they still need to meet the same standards of quality as the rest of the encyclopedia. —donhalcon╤ 21:15, 7 March 2006 (UTC)
- I agree generally with a lot of these points. It's not that bullet pointed lists aren't useful, but rather this article has a bit too many of them. I think "Differences in maturity" can be kept largely as is, and "Philosophical differences" could be kept as the only list in the article (with some 'too specific' points merged or dropped). The opening lists should be replaced by prose, with all minor nitty-gritty differences dropped in favour of a more general discussion of how the intended audience/market of each language has shaped its development. The article should probably be headed by a short section on the 'supposed' rivalry between the Java and C# camps (which is, after all, probably the real reason why the article exists.) JavaKid 17:49, 10 March 2006 (UTC)
- As to the "importance" tag, the first paragraph of the article states the importance. As well, examining importance, this article passes every piece of important criteria, not just the one as is required to pass the test of "importance". - Chris 21:33, 10 March 2006 (UTC)
- OK, I've removed both the {{advert}} and the {{importance}} tags. I addressed the importance above. As for the "advert", I suppose that's subjective, but the article seems as NPOV as possible. It may fall under {{tone}}, but I still think it's totally fact-based and written quite formally. - Chris 21:38, 10 March 2006 (UTC)
- I've broken the ice by posting a quick first draft of a prose-based discussion which avoids listing features. (Hope this is okay?) It instead looks at the historic rivalry between the two camps (which I personally think is overplayed - I don't see many attacks in their community on the other these days - but that's just my POV). I've then added a breakdown of the various markets in which Java and C# might compete, presently and in the future. I've left the bullet point lists in for now - but at some point they should be zapped IMHO. This stuff needs some C# details urgently, to add balance. It would also be nice to get some citations and supporting material for the two 'theories' as to C#'s political (or not) origins. Feel free to add/rewrite/shred this new material if it doesn't meet the 'tone' requirements. JavaKid 19:41, 11 March 2006 (UTC)
- Actually I thought has occured to me that my material perhaps strays a little too much towards comparing the API's and frameworks associated with each language. Problem is, the only way to compare any two languages without resorting to a list of features is to consider their history, rivalry, 'culture' and 'environment' - which inevitably brings in material about associated APIs, frameworks and usage. JavaKid 19:52, 11 March 2006 (UTC)