What do people think about the different Generic Java approaches?

Question

I have seen a lot of different approaches for Generic Java, and when people find problems with each approach the normal response has been: the other approach is worse with such and such a problem, do you have a better way?
The different approaches I have seen are: (in no particular order)
Please correct me if I am wrong and add other approaches if they are worthy of mention.
1) PolyJ - by MIT
This is a completely different approach than the others, that introduces a new where clause for bounding the types, and involves changing java byte codes in order to meet it's goals.
Main comments were not a java way of doing things and far too greater risk making such big changes.
2) Pizza - by Odersky & Wadler
This aims at extending java in more ways than just adding Generics. The generic part of this was replaced by GJ, but with Pizza's ability to use primitives as generic types removed, and much bigger changes allowing GJ to interface with java.
Main comments were that Pizza doesn't work well with java, and many things in Pizza were done in parallel with java, hence were no longer applicable.
3) GJ - by Bracha, Odersky, Stoutamire & Wadler
This creates classes with erased types and bridging methods, and inserts casts when required when going back to normal java code.
Main comments are that type dependent operations such as new, instanceof, casting etc can't be done with parametric types, also it is not a very intuitive approach and it is difficult to work out what code should do.
4) Runtime Generic Information - by Natali & Viroli
Each instance holds information about its Runtime Type.
Main comments from people were that this consumes way too much memory as each instance holds extra information about its type, and the performance would be bad due to checking Type information at runtime that would have been known at compile.
5) NextGen - by Cartwright & Steele
For each parameterized class an abstract base class with types erased is made and then for each new type a lightweight wrapper class and interface are created re-using code from the base class to keep the code small.
Main comments from people were that this approach isn't as backwards compatible as GJ due to replacing the legacy classes with abstract base classes which can't be instantiated.
6) .NET common runtime - by Kennedy & Syme
This was written for adding Generics to C#, however the spec is also targeted at other languages such as VB.
Main comments from people were that this approach isn't java, hence it is not subject to the restrictions of changing the JVM like java is.
7) Fully Generated Generic Classes - by Agesen, Freund & Mitchell
For each new type a new class is generated by a custom class loader, with all the code duplicated for each different type.
Main comments from people were that the generated code size gets too big, and that it is lacking a base class for integration with legacy code.
8) JSR-14 - by Sun
This is meant to come up with a solution Generic Solution to be used in java. Currently it is heavily based on GJ and suffering from all the same problems as GJ, along with the fact that it is constantly undergoing change and so no one knows what to expect.
See this forum for comments about it.
As if we didn't have enough approaches already, here is yet another one that hopefully has all of the benefits, and none of the problems of the other approaches. It uses information learnt while experimenting with the other approaches. Now when people ask me if I think I have a better approach, I will have somewhere to point them to.
(I will be happy to answer questions concerning this approach).
9) Approach #x - by Phillips
At compile time 1 type is made per generic type with the same name.
e.g.class HashSet<TypeA> extends AbstractSet<TypeA> implements Cloneable, Serializable will be translated to a type: class HashSet extends AbstractSet implements Cloneable, SerializableAn instance of the class using Object as TypeA can now be created in 2 different ways.
e.g.Set a = new HashSet();
Set<Object> b = new HashSet<Object>();
//a.getClass().equals(b.getClass()) is trueThis means that legacy class files don't even need to be re-compiled in order to work with the new classes. This approach is completely backwards compatible.
Inside each type that was created from a generic type there is also some synthetic information.
Information about each of the bounding types is stored in a synthetic field.
Note that each bounding type may be bounded by a class and any number of interfaces, hence a ';' is used to separate bounding types. If there is no class Object is implied.
e.g.class MyClass<TypeA extends Button implements Comparable, Runnable; TypeB> will be translated to a type: class MyClass {
  public static final Class[][] $GENERIC_DESCRIPTOR = {{Button.class, Comparable.class, Runnable.class}, {Object.class}};This information is used by a Custom Class Loader before generating a new class in order to ensure that the generic types are bounded correctly. It also gets used to establish if this class can be returned instead of a generated class (occurs when the generic types are the same as the bounding types, like for new HashSet<Object> above).
There is another synthetic field of type byte[] that stores bytes in order for the Custom Class Loader to generate the new Type.
There are also static methods corresponding to each method that contain the implementation for each method. These methods take parameters as required to gain access to fields, contructors, other methods, the calling object, the calling object class etc. Fields are passed to get and set values in the calling object. Constructors are passed to create new instances of the calling object. Other methods are passed when super methods are called from within the class. The calling object is almost always passed for non static methods, in order to do things with it. The class is passed when things like instanceof the generated type need to be done.
Also in this class are any non private methods that were there before, using the Base Bounded Types, in order that the class can be used exactly as it was before Generics.
Notes: the time consuming reflection stuff is only done once per class (not per instance) and stored in static fields. The other reflection stuff getting done is very quick in JDK1.4.1 (some earlier JDKs the same can not be said).
Also these static methods can call each other in many circumstances (for example when the method getting called is private, final or static).
As well as the ClassLoader and other classes required by it there is a Reflection class. This class is used to do things that are known to be safe (assuming the compiler generated the classes correctly) without throwing any exceptions.
Here is a cut down version of the Reflection class: public final class Reflection {
  public static final Field getDeclaredField(Class aClass, String aName) {
    try {
      Field field = aClass.getDeclaredField(aName);
      field.setAccessible(true);
      return field;
    catch (Exception ex) {
      throw new Error(ex);
  public static final Object get(Field aField, Object anObject) {
    try {
      return aField.get(anObject);
    catch (Exception ex) {
      throw new Error(ex);
  public static final void set(Field aField, Object anObject, Object aValue) {
    try {
      aField.set(anObject, aValue);
    catch (Exception ex) {
      throw new Error(ex);
  public static final int getInt(Field aField, Object anObject) {
    try {
      return aField.getInt(anObject);
    catch (Exception ex) {
      throw new Error(ex);
  public static final void setInt(Field aField, Object anObject, int aValue) {
    try {
      aField.setInt(anObject, aValue);
    catch (Exception ex) {
      throw new Error(ex);
}Last but not least, at Runtime one very lightweight wrapper class per type is created as required by the custom class loader. Basically the class loader uses the Generic Bytes as the template replacing the erased types with the new types. This can be even faster than loading a normal class file from disk, and creating it.
Each of these classes has any non private methods that were there before, making calls to the generating class to perform their work. The reason they don't have any real code themselves is because that would lead to code bloat, however for very small methods they can keep their code inside their wrapper without effecting functionality.
My final example assumes the following class name mangling convention:
* A<component type> - Array
* b - byte
* c - char
* C<class name length><class name> - Class
* d - double
* f - float
* i - int
* l - long
* z - boolean
Final Example: (very cut down version of Vector)public class Vector<TypeA> extends AbstractList<TypeA> implements RandomAccess, Cloneable, Serializable {
  protected Object[] elementData;
  protected int elementCount;
  protected int capacityIncrement;
  public Vector<TypeA>(int anInitialCapacity, int aCapacityIncrement) {
    if (anInitialCapacity < 0) {
      throw new IllegalArgumentException("Illegal Capacity: " + anInitialCapacity);
    elementData = new Object[initialCapacity];
    capacityIncrement = capacityIncrement;
  public synchronized void setElementAt(TypeA anObject, int anIndex) {
    if (anIndex >= elementCount) {
      throw new ArrayIndexOutOfBoundsException(anIndex + " >= " + elementCount);
    elementData[anIndex] = anObject;
}would get translated as:public class Vector extends AbstractList implements RandomAccess, Cloneable, Serializable {
  public static final Class[][] $GENERIC_DESCRIPTOR = {{Object.class}};
  public static final byte[] $GENERIC_BYTES = {/*Generic Bytes Go Here*/};
  protected Object[] elementData;
  protected int elementCount;
  protected int capacityIncrement;
  private static final Field $0 = Reflection.getDeclaredField(Vector.class, "elementData"),
                             $1 = Reflection.getDeclaredField(Vector.class, "elementCount"),
                             $2 = Reflection.getDeclaredField(Vector.class, "capacityIncrement");
  static void $3(int _0, Field _1, Object _2, Field _3, int _4) {
    if (_0 < 0) {
      throw new IllegalArgumentException("Illegal Capacity: " + _0);
    Reflection.set(_1, _2, new Object[_0]);
    Reflection.setInt(_3, _2, _4);
  static void $4(int _0, Field _1, Object _2, Field _3, Object _4) {
    if (_0 >= Reflection.getInt(_1, _2)) {
      throw new ArrayIndexOutOfBoundsException(_0 + " >= " + Reflection.getInt(_1, _2));
    ((Object[])Reflection.get(_3, _2))[_0] = _4;
  public Vector(int anInitialCapacity, int aCapacityIncrement) {
    $3(anInitialCapacity, $0, this, $2, aCapacityIncrement);
  public synchronized void setElementAt(Object anObject, int anIndex) {
    $4(anIndex, $1, this, $0, anObject);
} and new Vector<String> would get generated as:public class Vector$$C16java_lang_String extends AbstractList$$C16java_lang_String implements RandomAccess, Cloneable, Serializable {
  protected Object[] elementData;
  protected int elementCount;
  protected int capacityIncrement;
  private static final Field $0 = Reflection.getDeclaredField(Vector$$C16java_lang_String.class, "elementData"),
                             $1 = Reflection.getDeclaredField(Vector$$C16java_lang_String.class, "elementCount"),
                             $2 = Reflection.getDeclaredField(Vector$$C16java_lang_String.class, "capacityIncrement");
  public Vector$$C16java_lang_String(int anInitialCapacity, int aCapacityIncrement) {
    Vector.$3(anInitialCapacity, $0, this, $2, aCapacityIncrement);
  public synchronized void setElementAt(String anObject, int anIndex) {
    Vector.$4(anIndex, $1, this, $0, anObject);
}Comparisons with other approaches:
Compared with PolyJ this is a very java way of doing things, and further more it requires no changes to the JVM or the byte codes.
Compared with Pizza this works very well with java and has been designed using the latest java technologies.
Compared with GJ all type dependent operations can be done, and it is very intuitive, code does exactly the same thing it would have done if it was written by hand.
Compared with Runtime Generic Information no extra information is stored in each instance and hence no extra runtime checks need to get done.
Compared with NextGen this approach is completely backwards compatible. NextGen looks like it was trying to achieve the same goals, but aside from non backwards compatibility also suffered from the fact that Vector<String> didn't extend AbstractList<String> causing other minor problems. Also this approach doesn't create 2 types per new types like NextGen does (although this wasn't a big deal anyway). All that said NextGen was in my opinion a much better approach than GJ and most of the others.
Compared to .NET common runtime this is java and doesn't require changes to the JVM.
Compared to Fully Generated Generic Classes the classes generated by this approach are very lightweight wrappers, not full blown classes and also it does have a base class making integration with legacy code simple. It should be noted that the functionality of the Fully Generated Generic Classes is the same as this approach, that can't be said for the other approaches.
Compared with JSR-14, this approach doesn't suffer from GJ's problems, also it should be clear what to expect from this approach. Hopefully JSR-14 can be changed before it is too late.

Answer 1

(a) How you intend generic methods to be translated.
Given that Vector and Vector<Object> are unrelated types,
what would that type be represented as in the byte code of
the method? In my approach Vector and Vector<Object> are related types. In fact the byte code signature of the existing method is exactly the same as it was in the legacy code using Vector.
To re-emphasize what I had said when explaining my approach:
System.out.println(Vector.class == Vector<Object>.class);  // displays true
System.out.println(Vector.class == Vector<String>.class);  // displays false
Vector vector1 = new Vector<Object>(); // legal
Vector<Object> vector2 = new Vector();  // legal
// Vector vector3 = new Vector<String>(); // illegal
// Vector<String> vector4 = new Vector();  // illegal
Vector<String> vector5 = new Vector<String>();  // legal
You must also handle the case where the type
parameter is itself a parameterized type in which the type
parameter is not statically bound to a ground instantiation.This is also very straightforward: (let me know if I have misunderstood you)
(translation of Vector given in my initial description)
public class SampleClass<TypeA> {
  public static void main(String[] args) {
    System.out.println(new Vector<Vector<TypeA>>(10, 10));
}would get translated as:public class SampleClass {
  public static final Class[][] $GENERIC_DESCRIPTOR = {{Object.class}};
  public static final byte[] $GENERIC_BYTES = {/*Generic Bytes Go Here*/};
  private static final Constructor $0 = Reflection.getDeclaredConstructor(Vector$$C16java_util_Vector.class, new Class[] {int.class, int.class});
  static void $1(Constructor _0, int _1, int _2) {
    try {
      System.out.println(Reflection.newInstance(_0, new Object[] {new Integer(_1), new Integer(_2)}));
    catch (Exception ex) {
      throw (RuntimeException)ex;
  public static void main(String[] args) {
    $1($0, 10, 10);
}and SampleClass<String> would get generated as:public class SampleClass$$C16java_lang_String {
  private static final Constructor $0 = Reflection.getConstructor(Vector$$C37java_util_Vector$$C16java_lang_String.class, new Class[] {int.class, int.class});
  public static void main(String[] args) {
    SampleClass.$1($0, 10, 10);
Also describe the implementation strategy for when these
methods are public or protected (i.e. virtual).As I said in my initial description that for non final, non static, non private method invocations a Method may be passed into the implementing synthetic method as a parameter.
Note: the following main method will display 'in B'.
class A {
  public void foo() {
    System.out.println("in A");
class B extends A {
  public void foo() {
    System.out.println("in B");
public class QuickTest {
  public static void main(String[] args) {
    try {
      A.class.getMethod("foo", null).invoke(new B(), null);
    catch (Exception ex) {}
}This is very important as foo() may be overwritten by a subclass as it is here. By passing a Method to the synthetic implementation this guarantees that covariance, invariance and contra variance all work exactly the same way as in java. This is a fundamental problem with many other approaches.
(b) The runtime overhead associated with your translationAs we don't have a working solution to compare this to, performance comments are hard to state, but I hope this helps anyway.
The Class Load time is affected in 4 ways. i) All the Generic Bytes exist in the Base Class, hence they don't need to be read from storage. ii) The custom class loader, time to parse the name and failed finds before it finally gets to define the class. iii) The generation of the generic bytes to parametric bytes (basically involves changing bytes from the Constant Pool worked out from a new Parametric type, Utf8, Class and the new Parametric Constant types may all be effected) iv) time to do the static Reflection stuff (this is the main source of the overhead). Basically this 1 time per class overhead is nothing to be concerned with, and Sun could always optimize this part further.
The normal Runtime overhead (once Classes have been loaded) is affected mainly by reflection: On older JDKs the reflection was a lot slower, and so might have made a noticeable impact. On newer JDKs (since 1.4 I think), the reflection performance has been significantly improved. All the time consuming reflection is done once per class (stored in static fields). The normal reflection is very quick (almost identical to what is getting done without reflection). As the wrappers simply include a single method call to another method, these can be in-lined and hence made irrelevant. Furthermore it is not too difficult to make a parameter that would include small methods in the wrapper classes, as this does not affect functionality in the slightest, however in my testing I have found this to be unnecessary.
(c) The space overhead (per instantiation)There are very small wrapper classes (one per new Type) that simply contain all non private methods, with single method calls to the implementing synthetic method. They also include any fields that were in the original class along with other synthetic fields used to store reflected information, so that the slow reflection only gets done once per new Type.
(d) The per-instance space overheadNone.
(e) Evidence that the proposed translation is sound and well-defined for all relevant cases (see below)Hope this is enough, if not let me know what extra proof you need.
(f) Evidence for backward compatibility
(For example, how does an old class file that passes a Vector
to some method handle the case when the method receives a Vector<T>
where T is a type parameter? In your translation these types are unrelated.)As explained above, in my approach these are only unrelated for T != Object, in the legacy case T == Object, hence legacy code passing in Vector is exactly the same as passing in Vector<Object>.
(g) Evidence for forward compatibility
(How, exactly, do class files that are compiled with a generics compiler run on an old VM)They run exactly the same way, the byte codes from this approach are all legal java, and all legal java is also legal in this approach. In order to take advantage of the Generics the Custom Class Loader would need to be used or else one would get ClassNotFoundExceptons, the same way they would if they tried using Collections on an old VM without the Collections there. The Custom Class Loader even works on older VMs (note it may run somewhat slower on older VMs).
(h) A viable implementation strategyType specific instantiations are at Class Load time, when the Custom Class Loader gets asked for a new Class, it then generates it.
The type specific instantiations are never shipped as they never get persisted. If you really wanted to save them all you need to do is save them with the same name (with the $$ and _'s etc), then the class loader would find them instead of generating them. There is little to be gained by doing this and the only reason I can think of for doing such a thing would be if there was some reason why the target VM couldn't use the Custom Class Loader (the Reflection class would still need to be sent as well, but that is nothing special). Basically they are always generated at Runtime unless a Class with the same name already exists in which case it would be used.
The $GENERIC_DESCRIPTOR and $GENERIC_BYTES from the base class along with the new Type name are all that is required to generate the classes at runtime. However many other approaches can achieve the same thing for the generation, and approaches such as NextGen's template approach may be better. As this generation is only done once per class I didn't put much research into this area. The way it currently works is that the $GENERIC_DESCRIPTOR are basically used to verify that a malicious class files is not trying to create a non Type Safe Type, ie new Sample<Object>() when the class definition said class Sample<TypeA extends Button>. The $GENERIC_BYTES basically correspond to the normal bytes of a wrapper class file, except that in the constant pool it has some constants of a new Parametric Constant type that get replaced at class load time. These parametric constants (along with possibly Utf8 and Class constants) are replaced by the Classes at the end of the new type name, a little more complex than that but you probably get the general idea.
These fine implementation details don't affect the approach so much anyway, as they basically come down to class load time performance. Much of the information in the $GENERIC_BYTES could have been worked out by reflection on the base type, however at least for now simply storing the bytes is a lot easier.
Note: I have made a small syntax change to the requested class:
public T(X datum) --> public T<X>(X datum)
class T<X> {
  private X datum;
  public T<X>(X datum) {
    this.datum = datum;
  public T<T<X>> box() {
    return new T<T<X>>(this);
  public String toString() {
    return datum.toString();
  public static void main(String[] args) {
    T<String> t = new T<String>("boo!");
    System.out.println(t.box().box());
}would get translated as:
class T {
  public static final Class[][] $GENERIC_DESCRIPTOR = {{Object.class}};
  public static final byte[] $GENERIC_BYTES = {/*Generic Bytes Go Here*/};
  private Object datum;
  private static final Field $0 = Reflection.getDeclaredField(T.class, "datum");
  private static final Constructor $1 = Reflection.getDeclaredConstructor(T$$C1T.class, new Class[] {T.class});
  static void $2(Field _0, Object _1, Object _2) {
    Reflection.set(_0, _1, _2);
  static Object $3(Constructor _0, Object _1) {
    try {
      return Reflection.newInstance(_0, new Object[] {_1});
    catch (Exception ex) {
      throw (RuntimeException)ex;
  static String $4(Field _0, Object _1) {
    return Reflection.get(_0, _1).toString();
  static void $5() {
    T$$C16java_lang_String t = new T$$C16java_lang_String("boo!");
    System.out.println(t.box().box());
  public T(Object datum) {
    $2($0, this, datum);
  public T$$C1T box() {
    return (T$$C1T)$3($1, this);
  public String toString() {
    return $4($0, this);
  public static void main(String[] args) {
    $5();
}as the generic bytes aren't very meaningful and by no means a requirement to this approach (NextGen's template method for generation may work just as well), here are the generated classes with some unused code commented out instead:
class T$$C28T$$C22T$$C16java_lang_String {
  private T$$C22T$$C16java_lang_String datum;
  private static final Field $0 = Reflection.getDeclaredField(T$$C28T$$C22T$$C16java_lang_String.class, "datum");
//  private static final Constructor $1 = Reflection.getDeclaredConstructor(T$$C34T$$C28T$$C22T$$C16java_lang_String.class, new Class[] {T$$C28T$$C22T$$C16java_lang_String.class});
  public T$$C28T$$C22T$$C16java_lang_String(T$$C22T$$C16java_lang_String datum) {
    T.$2($0, this, datum);
//  public T$$C34T$$C28T$$C22T$$C16java_lang_String box() {
//    return (T$$C34T$$C28T$$C22T$$C16java_lang_String)T.$3($1, this);
  public String toString() {
    return T.$4($0, this);
  public static void main(String[] args) {
    T.$5();
class T$$C22T$$C16java_lang_String {
  private T$$C16java_lang_String datum;
  private static final Field $0 = Reflection.getDeclaredField(T$$C22T$$C16java_lang_String.class, "datum");
  private static final Constructor $1 = Reflection.getDeclaredConstructor(T$$C28T$$C22T$$C16java_lang_String.class, new Class[] {T$$C22T$$C16java_lang_String.class});
  public T$$C22T$$C16java_lang_String(T$$C16java_lang_String datum) {
    T.$2($0, this, datum);
  public T$$C28T$$C22T$$C16java_lang_String box() {
    return (T$$C28T$$C22T$$C16java_lang_String)T.$3($1, this);
  public String toString() {
    return T.$4($0, this);
  public static void main(String[] args) {
    T.$5();
class T$$C1T {
  private T datum;
  private static final Field $0 = Reflection.getDeclaredField(T$$C1T.class, "datum");
//  private static final Constructor $1 = Reflection.getDeclaredConstructor(T$$C6T$$C1T.class, new Class[] {T$$C1T.class});
  public T$$C1T(T datum) {
    T.$2($0, this, datum);
//  public T$$C6T$$C1T box() {
//    return (T$$C6T$$C1T)T.$3($1, this);
  public String toString() {
    return T.$4($0, this);
  public static void main(String[] args) {
    T.$5();
class T$$C16java_lang_String {
  private String datum;
  private static final Field $0 = Reflection.getDeclaredField(T$$C16java_lang_String.class, "datum");
  private static final Constructor $1 = Reflection.getDeclaredConstructor(T$$C22T$$C16java_lang_String.class, new Class[] {T$$C16java_lang_String.class});
  public T$$C16java_lang_String(String datum) {
    T.$2($0, this, datum);
  public T$$C22T$$C16java_lang_String box() {
    return (T$$C22T$$C16java_lang_String)T.$3($1, this);
  public String toString() {
    return T.$4($0, this);
  public static void main(String[] args) {
    T.$5();
}the methods from the Reflection class used in these answers not given in my initial description are:
  public static final Object newInstance(Constructor aConstructor, Object[] anArgsArray) throws Exception {
    try {
      return aConstructor.newInstance(anArgsArray);
    catch (InvocationTargetException ex) {
      Throwable cause = ex.getCause();
      if (ex instanceof Exception) {
        throw (Exception)ex;
      throw new Error(ex.getCause());
    catch (Exception ex) {
      throw new Error(ex);
  public static final Constructor getDeclaredConstructor(Class aClass, Class[] aParameterTypesArray) {
    try {
      Constructor constructor = aClass.getDeclaredConstructor(aParameterTypesArray);
      constructor.setAccessible(true);
      return constructor;
    catch (Exception ex) {
      throw new Error(ex);
  }