[java] Java 5 Generics - Syntactic sugar or more?

Started by
8 comments, last by smiley_horse 19 years, 2 months ago
Simple question - can Java 5 generics improve performance? I've heard that they're just syntactic sugar for casts, but does using them help the compiler to avoid runtime type checks? For example:
//Java 1.4
ArrayList list = new ArrayList();
list.add("a string of text");
String myString = (String) list.get(0); //A runtime type check must be done here to ensure that the value returned is a String
And the 1.5 version (please forgive me if the syntax is off - I have yet to use Java generics):
//Java 1.5
ArrayList<String> list = new ArrayList<String>();
list.add("a string of text");
String myString = list.get(0); //Is a runtime check (cast) still occuring here internally?
Will these two examples each get compiled exactly the same internally, or can the latter perform optimizations to eliminate the runtime type checking? Thanks in advance!
Advertisement
I can't answer your question about performance since I haven't used 1.5, but as far as I can tell it's mostly syntactic sugar. There was an interesting discussion (or rant?) about it on the javagaming boards.

shmoove
Sigh... Too bad Sun didn't go for a more .NET-ish approach to generics (IMO). Guess I will stick with 1.4 for now, as I don't mind a few casts here and there. Thanks!
At least generics prevent you from putting objects of a wrong type in your container. In your 1.4 example above, what would happen if someone put an object of type Integer into the ArrayList ? At some later point the application would crash because of a type cast exception. Finding the bug is very difficult.
As I understand it, there haven't been any real changes to the Java-VM. This means that at the very least the VM must do the appropriate runtime type checks when getting a String form a List. So basically it's just syntactic sugar, but very sweet kind, might I add. Goes well with the new for-loops.
Unfortunately, generics in Java (and the up-coming C# 2.0) are a leaky abstraction. That is, when they work, they work well. But if something goes wrong, you need to understand how they are implemented to be able to grok the problem.

For example, in both C# 2.0 and Java 1.5, the following is illegal:

class MyGeneric<T>{  public void Method(object o)  {    if (o is T) // error    {      T tmp = new T(); // error    }  }  public void Blah(T var)  {    var.OtherMethod(); // error  }}


These things may seem valid to someone familiar with C++, but are not allowed in either C# or Java.

At least C# provides some performance benefits when using generics. Because they're part of the byte code, you don't have those runtime casts anymore. It also includes further benefits when using value types, because it removes the implicit boxing required now when you store a value type as an object.

The other problem is that it's still possible in Java to get a CastException - even when your code contains no casts, because at the bytecode allows you to add objects of a different type to your generic collection and when you get an object out of it, java adds the implicit cast for you.

Anyway, that's enough of a rant from me :)
Quote:Original post by nmi
At least generics prevent you from putting objects of a wrong type in your container.


It is nearly impossible to find any situation in the real world where this ever happens.

Sun has highly paid morons who tour the country telling us we'll be saved from CCE's. The last time I saw a CCE - either in my code, my customer's code, or any colleague or friend's code - was last century. The same is true for almost all java programmers. **

So...it's pure marketing BS by idiots at sun who've done a terrible thing and now desperately have to defend their jobs. If you've spend enough time in big corps you'll probably have seen this same pattern hundreds of times, although it's the first time I personally have ever been hit badly by the FUBAR, which makes me pretty annoyed :(.

**: PS: the CCE's I last saw were in fact from Sun's own buggy implementation of their own standard libraries!
Quote:Original post by nmi
At least generics prevent you from putting objects of a wrong type in your container. In your 1.4 example above, what would happen if someone put an object of type Integer into the ArrayList ? At some later point the application would crash because of a type cast exception. Finding the bug is very difficult.

it will only prevent this at runtime, unlike C++ templates which is a compile time check.

No, there will be no performance gain, java generics are nothing more than a preprocessor directive to replace all your get calls with the appropriate typecast.

[Formerly "capn_midnight". See some of my projects. Find me on twitter tumblr G+ Github.]

Quote:Original post by Anonymous Poster
It is nearly impossible to find any situation in the real world where this ever happens.

Sun has highly paid morons who tour the country telling us we'll be saved from CCE's. The last time I saw a CCE - either in my code, my customer's code, or any colleague or friend's code - was last century. The same is true for almost all java programmers. **

So...it's pure marketing BS by idiots at sun who've done a terrible thing and now desperately have to defend their jobs. If you've spend enough time in big corps you'll probably have seen this same pattern hundreds of times, although it's the first time I personally have ever been hit badly by the FUBAR, which makes me pretty annoyed :(.

**: PS: the CCE's I last saw were in fact from Sun's own buggy implementation of their own standard libraries!
I must admit I tend to agree. Sun is sacrificing too much in the name of remaining backward-compatible with older JVMs (IMO). No telling what the future will bring, but if Sun keeps up with this trend, my guess would be that Java is due to be extinguished by .NET in the not too distant future. Oh well, I guess we'll have to live with what they give us. [headshake]
Unfortunately only syntatic sugar - at least in this reincarnation. As I have understand from release notes in latest jdk - new generics are translated to old jvm because of compatibility. It still uses dynamic runtime cast internally. Maybe in new release of jvm they will do it more eficiently or something - but in this one it's merely a convinience for a programmer. In my opinion they also missed opportunity to make some better way of doing templates then how it looks like in c++. I never liked the c++ syntax for templates, it's kind-a gluttered on top & can really be pain in the ass to read fast when you read the code (at least for me). I guess they wanted templates in java to be easy to learn for c++ programmers as the rest of syntax, but I wish they found some other syntax, more readable that felt more like a part of language - not as artificial add on. It's like you have volvo 240 and put a wing on back - it just doesn't cut it.

This topic is closed to new replies.

Advertisement