Re: JDK1.5, improved FOR loop and generics - How?!

[Neal Gafter]

Thanks for the response, Neal, but I'm aware it's possible to
literally pass the Class type that you are trying to check for and use
its isInstance method. But the point I was trying to make is
intuitively, this information should already be present because of the
generic type (and would be present without type erasure) specified on
the class.

The example you sited is a static method that wraps an already typed
collection (type E) but still requires you to supply the class type.
Thus, for a collection of strings, you would have:

Collections.checkedCollection(new ArrayList<String>(), String.class);

What I find unannoying and unintuitive is the need to supply
"String.class" when the type of the collection is already supplied via
"new ArrayList<String>()". I guess ultimately this is just an
inconvenience, but seeing all this redundant code really clashes with
the whole spirit of generics.

I agree completely. That is the price we pay for transition compatibility. See
section 6 of <http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf>. If we
were designing the language from scratch and didn't have to worry about
interoperating with existing code we certainly would prefer to reify type
parameters.

 

[Roedy Green]

would prefer to reify type
parameters.

You could please define these terms:
"reify"
"type erasure"

 

[Neal Gafter]

You could please define these terms:
"reify"

From <http://dictionary.reference.com/search?q=reify>:
"To regard or treat (an abstraction) as if it had concrete or material
existence." In the context of programming language design, this generally means
giving the entity a representation at runtime.

"type erasure"

This is spelled out in quite some detail in the jsr14 specification and in the
Generics tutorial at <http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf>.