[rit]

Totally reactionary, prejudiced statement.

But my first reaction on headline before reading the article was "Ugh. I'm sorry". (I will read it in a second, I felt this obdurate urge to rant BEFORE I read it).

I coded in Java for work (After being hired to do Java) for years, then went over to Python, and worked with some C# for about a year. Now I'm back working with Java, and Scala (for which I have lots of love - it has a lot of what I love about Python but in many cases better).

There are little things in C# that just really give it an edge over Java. Among other things relating to Generics (Which are awful to begin with in that the JVM currently erases type information at compile time [Scala has a few clever hacks to get around it]) - as I understand it, C#/CLR automatically generates multiple specialized paths for all possible primitive types with generic collections.

And being a fan of closures, anonymous functions, etc. Java is just painful. C# has these, and more.

Now Off to read the article :)

[jcromartie]

No programmer that knows both would tell you that Java-the-language beats C#-the-language. There have to be other reasons for one to switch.

[runT1ME]

As an Open Source advocating, anti-MS, java fanboy, I agree completely. C# the language blows java out of the water. I give MS a lot of respect for really evolving the language.

I do think, however, that the JVM is much more advanced than the CLR, and really the only one of the two that is truly cross platform and open.

[bruceboughton]

I'm interested to hear in what ways the JVM is more advanced than the CLR (no, genuinely I am).

As for cross-platform, well that's not a goal of the CLR so the JVM wins de-facto.

[runT1ME]

The G1 collector, for starters, is a lot more advanced in terms of GC technology. From what I remember, the CLR is a simple generational collector.

I've also seen examples of the JVM running well on extremely large boxes, where as I have not seen it with the CLR.

[brazzy]

I keep seeing people bash Java's Generics because of type erasure - but what exactly is so awful about it? All the questions on stackoverflow where the answer is "impossible because of type erasure, or use this workaround" don't seem to be about terribly important or useful things.

[bad_user]

Java's Generics are awful because they are useless, while being the most complex feature added to Java.

Templates in C++ or the generic types from Haskel enable parametric polymorphism which is a lot more elegant for certain problems than subtype-polymorphism (i.e. OOP).

Java's generics is only a hack to make it look as though some piece of code that's using subtype-polymorphism is parametric ... but it only saves you explicit type-casts, which are also useless.

dotNet's generics are different ... while sharing the same limitations (i.e. no late binding and not implicit interfaces), because the types are available at runtime the runtime dispatches being made aren't just hacks and you can use the reflection mechanism to workaround many of the problems associated.

[fauigerzigerk]

The most horrible thing about it is that all primitives have to be boxed using huge amounts of memory. And there are lots of other bad consequences like not being able to call a constructor for a type parameter. But Java's horrible generics implementation is only my second most pressing problem. The first being the lack of structured value types (i.e struct in C#).

I am rewriting a C# app in Java right now and I'm being forced into extremely awful hacks to prevent memory consumption from exploding. To illustrate how bad the situation is let me tell you that I'm seriously thinking about rewriting everything in C++ :-)

[thejake]

The case that I've bumped up against several times is when trying to get the class of the generic object. Something like:

  T obj;
  obj = getObjFromSomewhere();
  log(T.class);

This type of operation is most useful if writing framework type of some sort. I've come across it when trying to write a generic JPA base DAO type of class.

[rit]

Scala has Manifests to emulate reified types for just this reason.

http://www.scala-blogs.org/2008/10/manifests-reified-types.h...

It's improved a bit in 2.8 - in porting some code I discovered a nice little hack that lets you declare your variance like this:

[A <: SomeBaseClass <: Manifest]

Which tells the compiler in an oh so gentle manner to reify for you.

[jared314]

It is useful for doing metaprogramming, while keeping it type safe and well specified.

[Kototama]

The decision taken in the article is clear : it's not so a matter of language but a matter of platforms. The JVM has a lot to offer in this way.