Seth Nickell

Graydon’s c#/java post, I think rightfully, mostly concludes that Java and C# are more or less same-ish. Dare’s C# for Java programmers document, which Miguel linked to as a more rigorous technical comparison, says roughly the same thing in its “Conclusion” section. I’d paraphrase it roughly as “Java programmers will probably find that C# has more nice extras available than vice versa. Java and C# are similar enough though that useful code has been, and probably will continue to be continue to be ported back and forth between them.“.

Looking through that (old) list of things C# has that Java doesn’t, most of the major ones are now present in Java 5: varargs, generics, foreach, metadata. Most of the rest of them are things that are arguable back and forth as to whether they’re a good idea (I hope everyone learned from C++ that more features != better) such as having a pre-processor. Delegates and Structs stand out as exceptions to this. Structs can, I think, be argued back and forth. Java is in certain ways more determinedly high level than C#, this would be an example of that (not exposing a distinction between stack adn heap). But, on the whole, there have been enough cases where I really do damn well want to allocate things quickly on the heap that this feature seems to be a win for C#. Delegates are quite a bit cleaner than the equivalent Java idiom and very nice. But neither of these is world changing features. Really.

On the flip-side Java has checked and unchecked exceptions. It was an intentional language decision to not include these in C#, I’m sure (just as, say, not including pre-processor in Java was almost certainely discussed and rejected). Some people hate having to catch all the exceptions. Personally, I think it makes code better. I’d trade structs for Java’s declared exceptions any day (perhaps not for delgates through). Java can also, e.g. dynamically instantiate classes from byte streams. But who really cares?

Probably the most practically important difference doesn’t seem to be mentioned in Dare’s analysis, which is the ease with which Mono code will be able to avail of existing C libraries. I think this is very important, and shame on Sun for making this such a PITA with JNI. Unlike this and that language construct I think this will have significant impact on how the language is actually used.

Java and C# remain the most similar major languages evar (that I know of at least). C# is pretty damn clearly an iteration of Java. Its a good improvement, and in turn Java picked up a number of the best improvements and integrated them into its next release. But the differences are not earth shaking.

My personal suspicion is that Eclipse makes a bigger difference (both in terms of productivity and in terms of how clean the codebase is since it makes all sorts of refactoring so easy) than the language construct differences. But then, I am a known IDE junkie.

Oh, I should add that Miguel is absolutely right that JDK 5 has not been replicated in the free software context, and, IMO, shame on the classpath developers for that being true. It was clear which of the JSR bits would be included in JDK 5 long before it was released. ecj, Eclipse’s built in Java compiler which we’ve now extracted as a standalone thing does support JDK 5 stuff, but the class libraries still need to be genericized and such. So you can already do varargs and stuff like that. The main thing that’s missing from the free java stack right now, wrt to JDK 5, is that the standard libraries don’t come in genericized versions so you can’t do List yet. That’s pretty important obviously, though you can write your own genericized classes already.