Reification

[Wouter Oet]

I don't really know the details but this looks interesting:

http://twitpic.com/37ky8w

It's from Mark Reinhold's presentation at Devoxx.

[Jelle Klap]

Hmm, run-time availability of type-information (generics).
No more type erasure? Well, there goes binary compatibility...
I don't see this happening anywhere in the immidiate future.

[Pat Farrell]

I'm not convinced that type-erasure is a good idea, long term. It was a needed hack to allow pre-Java-5 bytecode to run, but it adds a lot of complexity and can bring subtle bugs.

I would be happy if it went away in some suitable future Java-like language.

[Rob Spoor]

Jelle Klap wrote:Hmm, run-time availability of type-information (generics).

I probably missed something, because I didn't see anything like that. All I saw was:
- being able to use primitives as generic types
- type inference for the instantiation

[Jesper de Jong]

I don't know why Mark Reinhold showed this example while he was talking about type reification (see the photo: the title of the slide is "Language Futures: Reification").

Type erasure was an unfortunate idea that made it into Java, only because raw types needed to be supported for backward compatibility. Type erasure has lead to a number of warts, like the impossibility of creating arrays of a concrete parameterized type. Other languages, Scala for example, are also bothered by type erasure; in Scala there is an ugly workaround (manifests) to get generic type information at runtime.

In my opinion, generics should never have been implemented with type erasure - and now it is much harder to add type reification to Java because everything has to stay backward compatible. It would be nice if we could get rid of type erasure in Java and the JVM, but it's not going to be easy.

[Rob Spoor]

I fully agree on type erasure. Without it, it would (probably) even be possible to instantiate instances and arrays (new T[10] anyone?) of generic types. I even made up a syntax for the first:

<T extends Serializable> void doSomething1(); // no constructor requirements so cannot instantiate; current syntax and situation
<T() extends Serializable> void doSomething2(); // no-parameter constructor required; new T() is possible
<T(String) extends Serializable> void doSomething3(); // String-only constructor required; new T("hello") is possible
<T(int, String) extends Serializable> void doSomething4(); // int + String constructor required; new T(1, "hello") is possible

In this example, Integer can only be used with doSomething1 and doSomething3. It misses the constructors required for doSomething2 and doSomething4 and therefore cannot be used there.