Java Generics: Let The Other Shoe Drop
(Via the original GJ: Generic Java page)
Guy Steele on GJ: GJ is an excellent design and implementation for adding generic types to the Java programming language. It provides a workable and practical facility for the immediate future that can solve many of today's problems in programming and debugging. In the long term,
I would hope to see it compatibly extended to carry run-time type parameter information in the manner that Robert Cartwright and I have proposed; but even if that does not occur, GJ as it is currently designed is a useful and workable tool that deserves widespread study and use.—Guy Steele (quoted from e-mail, with permission)
My recent reading of the O'Reilly book Java Generics and Collections convinced me that Java generics is too much trouble for too little gain for the average Java developer like me.
Eric commented "This is too hard. Sigh." And I agree. And in my frustration I posted a comment to the Java.net poll on What one feature would you most like to see in JDK 7?:
Me: My biggest wish for a future version of Java, not necessarily Java 7, is to have the other half of Java generics (runtime support for generic types) implemented, thus removing the need for erasure.
I believe I'm not alone in this desire.
Thinking that what I hoped might be just a common Java language user's fantasy that is not doable in reality, I did some search on The Google on the topic. And what did I find?:
- That it's not a mere fantasy of a mere language user
- That a run-time type parameter information proposal has been on the table since 1998
- That one of its authors is none other than Guy L Steele, Jr.
I couldn't read the proposal but I did find the quote at the beginning of this post.
So I believe I'm standing on very firm ground when I yell:
ERASE ERASURE
Re: Java Generics: Let The Other Shoe Drop
The generics puzzler you previously posted had more to do with method overloading than generics. It reminds me of array-based arguments others have used against generics. Arrays are broken, not generics; use collections, and everything will work great (though it is a shame we tied varargs to arrays instead of collections). Yes, Java may have holes, but it's much more thought out than many other languages.
As for their complexity, generics do make writing good APIs quite a bit more difficult, but they also make using APIs quite a bit easier. When it comes to API design, we're just beginning to see the new doors generics can open. I've had to make an effort to forget design idioms and retry patterns I wouldn't have considered before generics because I would have lost too much type information.
What specifically about erasure bothers you? i.e. what have you tried to do that you couldn't? Do you run into erasure problems often in day to day coding?
I'm not sure if you've read this or not, but Neal outlined what it would take to get rid of erasure. When people talk about erasure maintaining backward compatibility, they don't just mean using code compiled with an old compiler. They mean, without erasure, you can't use generic code with non-generic code. I'd personally rather hold off on full blown generics until the next language, or at least the next major, backward-compatibility-breaking version of the Java language, i.e. where'd we fix arrays, primitives, etc.
Re: Java Generics: Let The Other Shoe Drop
I think the method overloading restriction is unnatural. Why should the following innocent looking class be illegal?
import java.util.*;
public class Breakfast {
private List<Egg> eggs;
private List<Muffin> muffins;
public void add(List<Egg> moreEggs) {
this.eggs.addAll(moreEggs);
}
public void add(List<Muffin> moreMuffins) {
this.muffins.addAll(moreMuffins);
}
// ...
}
Of course the reason is erasure.
Another question I ask is "What can I do that I couldn't before generics?" And my first impression is "None." Again because of erasure.
As for things that I would like to do but couldn't, I'll nominate the factory:
public class Factory<Foo> {
public Foo createInstance() {
return new Foo();
}
}
I understand that we are just starting to scratch the surface of Java generics. And I eagerly awaits novel uses of generics that surprise me.
However, I have a nagging feeling that when we are done scratching the surface and the secret text is revealed, it will read: "No. You can't do it. Because of erasure."
Re: Java Generics: Let The Other Shoe Drop
My possible use cases are a bit hand-wavy, I haven't thought them through, which is why I'm not arguing for reification.
Perhaps you (Weiqi) have some use cases that might be persuasive. Most of mine could be replaced by a liberal dose of the visitor pattern (perhaps I'd rather see multiple dynamic dispatch).