Non intrusive runtime-level generics with erasures in JVM.
Major problem with erasure-based generic implementation is that instance is not receiving information on generic type upon creation. Reason is the NEW bytecode instruction that has a single parameter, which is pointer to a CONSTANT_Class entry in a constant pool. The structure of CONSTANT_Class is:
where tag is a static marker and name_indes is index of CONSTANT_Utf8_info entry in a constant pool which actually contain string that is representing a class name. In order to keep compatibility with older JVM's we can't put generic type information into this string, so javac is erasing this information.
However, there is a trick that Java VM and javac compiler could use to persist generic information. The idea is to add special class attribute that will link to CONSTANT_Class structure from constant pool to correspond generic information (e.g. using same grammar as used by bytecode Signature attribute). javac has to be updated to generate multiple CONSTANT_Class entries in constant pool for erasures with different generic types. That should allow JVM to resolve generic information in runtime when used for NEW bytecode instruction and also make it available trough reflection API. This may even allow to eliminate some CHECKCAST bytecode instructions inserted by Java5 compiler and used for bytecode verification.