Java Generics, Type Erasure and Frameworks

[Sebastian Millies]

I have started looking at Java Generics recently. At first, what
I struck me as valuable was that type parameters allow one to express
constraints that cannot (or not easily) be expressed using simple
polymorphism.

(An example would be a generic sort method that only accepted
a collection if its members were comparable with themselves,
cf. http://www.mindview.net/WebLog/wiki-0050)

However, when I learned about the type erasure implementation
of generics, it seemed to me that the added expressiveness was of no
use to people designing frameworks and libraries. After all, there is no
generic run-time type information in the jar-file you'll eventually
distribute. So, for example, you could not create a library containing
a sort method with the above restriction - not even if you required
clients to use the Tiger jre.

I then read about NextGen, and the possibility of including run-time generic
types in Java (e.g. http://www.cs.rice.edu/~eallen/papers/nextgen-final.pdf)
Is anything like that planned by Sun for a future Java release? If not,
there
seems to be little gain in using Java generics for framework development.

-- Sebastian

 

[Chris Uppal]

However, when I learned about the type erasure implementation
of generics, it seemed to me that the added expressiveness was of no
use to people designing frameworks and libraries. After all, there is no
generic run-time type information in the jar-file you'll eventually
distribute.

The type information is included in the jar files. It's just that it isn't
used by the JVM itself, only by any 1.5-style compiler that is compiling
against those jar files.

There are a bunch of new "attributes" added to classfiles generated by the new
compiler, some of which provide type information for generics. The compiler
knows how to read and use that data when if is compiling code that uses the
classes.

(After all, uses of the newly generic standard library are type checked, so it
clearly possible ;-)

-- chris