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.
To read all comments associated with this story, please click here.
Member since:2005-07-06
- 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.
Member since:2005-07-06
- 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 :-).
Member since:2005-07-24
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.
Member since:
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.