The generics support in the Java programming language is the most significant syntax change in its history. This article highlights how Eclipse has responded and the changes wrought by generics to the Java language. It shows how to take full advantage of generics within Eclipse, including support in Quick Assist, Quick Fix, refactoring, and project preferences. It also shows some subtle and important aspects of a fully generic language.
http://www.artima.com/intv/generics2.html
“For example, with Java generics, you don’t actually get any of the execution efficiency that I talked about, because when you compile a generic class in Java, the compiler takes away the type parameter and substitutes Object everywhere. So the compiled image for List<T> is like a List where you use the type Object everywhere. Of course, if you now try to make a List<int>, you get boxing of all the ints. So there’s a bunch of overhead there. Furthermore, to keep the VM happy, the compiler actually has to insert all of the type casts you didn’t write. If it’s a List of Object and you’re trying to treat those Objects as Customers, at some point the Objects must be cast to Customers to keep the verifier happy. And really all they’re doing in their implementation is automatically inserting those type casts for you. So you get the syntactic sugar, or some of it at least, but you don’t get any of the execution efficiency. So that’s issue number one I have with Java’s solution.
Issue number two, and I think this is probably an even bigger issue, is that because Java’s generics implementation relies on erasure of the type parameter, when you get to runtime, you don’t actually have a faithful representation of what you had at compile time. When you apply reflection to a generic List in Java, you can’t tell what the List is a List of. It’s just a List. Because you’ve lost the type information, any type of dynamic code-generation scenario, or reflection-based scenario, simply doesn’t work. If there’s one trend that’s pretty clear to me, it’s that there’s more and more of that. And it just doesn’t work, because you’ve lost the type information. Whereas in our implementation, all of that information is available. You can use reflection to get the System.Type for object List<T>. You cannot actually create an instance of it yet, because you don’t know what T is. But then you can use reflection to get the System.Type for int. You can then ask reflection to please put these two together and create a List<int>, and you get another System.Type for List<int>. So representationally, anything you can do at compile time you can also do at runtime.”
Use C#, it has no such bloat as Java/C++ since parametric polymorphism is supported directly inside CLR. Moreover, reduced casts make the code much more faster.
– this subject is irrelevant to the news item.
– C# generics are still not available. Java has it for 1 year
– The usage of generics are almost same in C# and Java for user perspective.
– The performance issue is more related with primitive (value types) usage in collections, which is usually a rare case. In object usage Java VM has similar performance values.
– In general Java VM is faster than .Net VM. if you expect applications to be faster just because of this issue you are a fool.
– C# generics are still not available. Java has it for 1 year
C# has had generics since the early 2.0 pre-beta releases…well over a year at this point.
At any rate, it’s yet to be seen how quickly the adoption of generics takes off in either languages. They are great for library/component builders, but for every day programming tasks they really aren’t necessary as often as something like anon methods (aka closures). I hope they don’t end up being overused like templates are in C++…meaning hopefully they won’t suffer the whole “everything looks like a nail” syndrome. But in the end I see people overusing them simply b/c they can :-).
well, beta products are generally not used in real world applications. so my comment was correct. Oficially there is no generics in C# right?
anyhow, i agree with you comment that generics does not really bring a lot, less casting and more compile time type protection. And usage of generics makes collection related API’s creation harder than it was.
Java’s generics implementation relies on erasure of the type parameter, when you get to runtime, you don’t actually have a faithful representation of what you had at compile time
This is indeed problematic – though appearantly inevitable in Java’s, ’cause the people who cooked all this up are Smart.
Type erasure can lead to ClassCastExceptions in places where you’re not casting anything. You can add a String to a List<Int> by casting, and not get an exception. Only when you then retrieve the element from the List<Int>, without casting, the runtime system finds out something went wrong and gives a ClassCastException.
Now of course this behaviour is still marginally better than C++, but I think Java is starting to show its age. Modern functional or .Net-based languages, like the new C# or Nemerle, tend to get this right – not neccessarily because they’re better, but because they have less legacy to drag along.
Very interesting and enlightening posts. While I am tending to agree with the first poster, I would like to see benchmarks. Maybe they will be out soon enough. That said we have seen a lot of cases already where 1.5 is faster than 1.4. Whether that includes generics or not i am not so sure.
If you actually took the first post seriously, you’re obviously a PHB, artist or sales person.
He compared a managed language, to a managed language and C++.
Come on, although I’m firmly with the Java camp, you can’t compare .NOT and Java to something like C++.
Whoops, that should be “.NET and Java.”
Who cares about C# outside of people still stuck on Microsoft platforms?
Who cares about C# outside of people still stuck on Microsoft platforms?
Haha, Java is dead on the open source desktop. There’s so much more development done on Mono than there ever will be with Java-Gnome or Java-KDE.
The vast majority of people are “stuck” on Microsoft for the client and will remain so for the foreseeable futures no matter how much idiot zealots scream.
Haha, Java is dead on the open source desktop. There’s so much more development done on Mono than there ever will be with Java-Gnome or Java-KDE.
You’re not really comparing like with like here. Java-Gnome and KDE Java are language bindings projects equivalent to GTK#. I agree that both of them haven’t been a roaring success to date, but I think they both could be great development environments combined with Eclipse. I don’t know if there are any projects to integrate Java-Gnome or KDE Java project templates in Eclipse, but it would make a big difference. Or integrating the javadoc docs into .jar files so that Eclipse can pick it up, would make a large difference for very little effort.
Mono is more equivalent to gcj, and gcj/gcc are certainly being actively developed. gcj’s CNI is a better integration technology for C++ libraries like Qt/KDE than JNI or P/Invoke. And Eclipse is better than any other Open Source IDE I know of for java programming, there isn’t a C# equivalent anywhere near as complete. So there is potential to create very nice Java programming environment for Gnome and KDE if someone makes the effort.
I don’t know about C# or Java generics though, they just seem to be a huge headache for very little gain to me. I’ve been reading Bruce Eckel’s articles on Artima about Java generics, and all he does is put me off ever going near them.
“I don’t know if there are any projects to integrate Java-Gnome or KDE Java project templates in Eclipse, but it would make a big difference.”
You want to have a look at http://www.bagu.org/wp/?p=13
It also shows some subtle and important aspects of a fully generic language.
And this has to do with java how?
One of my biggest gripes is the inability to construct T or T[].
The “solution” is to pass around “Class” objects which is a big ugly hack and really defeats one of the major benefits of generics.
Which do you prefer?
public T Foo<T>()
{
return new T();
}
or:
public <T> T Foo(Class someclass)
{
return (T)someclass.newInstance();
}
I like java wildcards (which allow List<Bar> to be compatible with List<Object>) but the lack of type information just sucks.
The whole point of using type erasure was to ensure backwards compatiblility with older JVMs but that’s now a moot point since java generics is no longer backwards compatible.
Sun screwed up.