Talk:Comparison of C Sharp and Java

How does Java have a simpler language? The CLR has some JIT time optimizations as well as runtiem 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 enum keyword.

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

— JIP | Talk 10:32, 25 October 2005 (UTC)