Skip to main content

Non intrusive runtime-level generics with erasures in JVM.

4 replies [Last post]
euxx
Offline
Joined: 2003-06-10
Points: 0

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:

CONSTANT_Class_info {
u1 tag;
u2 name_index;
}

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.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
euxx
Offline
Joined: 2003-06-10
Points: 0

The idea is to do not change erasured Class, but instead add a new method to Object that will return complete runtime information for given instance.

regexguy
Offline
Joined: 2003-06-20
Points: 0

I don't know enough about the reason runtime data was left out -- but I sure hope this addresses it. It would be really nice to have the runtime information.

I can think of one problem...

Currently if I do this
List l1 = ...;
List l2 = ...;
if(l1.getClass() == l2.getClass()) {
// true
}

if we use this suggestion the above code will give a different answer than it does now.

Perhaps this can be dealt with by making getClass()
find the erased class. Then we could have some other mechanism, say a static method named Class.getTypedClass(Object),
to extract the typed class from the object.

subanark
Offline
Joined: 2004-11-26
Points: 0

Runtime has nothing to do with it.
If types were not easure then for compadibility reasons it could not be applied to current classes.
Also it is nice if the user is not penalitized for new features that they don't use.

My suggestion would be to allow an option to use strong typing (in the decleration of the class). Which can be represented as a public final Class variable in the class. You could do this yourself (use Class.cast to aviod compile time warnings), but it would not be very seamless.

regexguy
Offline
Joined: 2003-06-20
Points: 0

Not sure I understand how euxx's idea would penalize users who don't use runtime generics. It doesn't add to the size of the java.lang.Object class.