The resulting system must meet all of the following constraints

C1) Upward compatibility with existing code. Pre-existing code must work on the new system. This implies not only upward compatibility of the class file format, but also interoperability of old applications with parameterized versions of pre-existing libraries, in particular those used in the platform library and in standard extensions.
C2) Upward source compatibility. It should be possible to compile essentially all existing
Java language programs with the new system.
C3) Timeliness. The revised system should be plausibly implementable in a reasonable time frame, without imposing an undue burden on vendors of virtual machines, IDEs and compilers. As the amount of code written in the Java programming language expands, the effort involved in upgrading to the revised language expands as well. Hence it is the interest of the Java community that any extensions should be made available quickly.
C4) Support for migration of existing APIs. It should be possible to parameterize existing APIs
without undue pain. In particular, there should be a clean, demonstrable migration path
for the Collections APIs that were introduced in the Java 2 platform.
C5) Insofar as possible, the design of generic classes should not introduce nonobvious or far-reaching changes in other parts of the language.
C6) Preservation of performance of existing code. The performance of non-generic programs written in the Java programming language should not be materially influenced by the presence of the generic extension. At most, a penalty of 1-2% in space or time might be acceptable.
C7) Preservation of the spirit of the Java programming language. The generic language should integrate well with the existing design and philosophy of the Java programming language.
C8) Good performance of generic code. Code written to use the generics feature should not be a lot slower or a lot more memory-intensive than non-generic code. Using ten percent more space or time than
non-generic code may be acceptable; using twice the space or time is not.

The system also has additional goals. Goals are different from constraints. Whereas all constraints must be met, it may not be possible to meet all the goals. Goals may be traded off against each other, or may be abandoned because they contradict constraints. No priority is implied by the ordering of the goals.

Goals for the system include

G1) Good collections support. The core Collections APIs and similar APIs are
perhaps the most important customers of genericity, so it is essential that
they work well as, and with, generic classes.
G2) Elimination of needless casts and improved static typechecking.
G3) Support parameterized throws clauses: It should be possible to use type
parameters in throws clauses to abstract over the types of exceptions.
G4) Simplicity. Keep it simple for users, but not necessarily for implementors: It's okay
to place a larger burden upon VM and compiler implementors (within reason)
if that will make generics more natural and easy to use.
G5) The Principle of Least Astonishment. Don't surprise the user
G6) Minimal design risk. The consequences of the design for usability, compatibility, performance and implementability must be fully understood.
G7) First class generics. Types involving parameters should be first-class types. This goal consists of several subsidiary goals:
a) Instantiated parameterized types (e.g., List) should be
first-class types.
b) Type parameters (e.g., T) should be first-class types.
(A consequence of this is that List is a first class type).
By "first-class" we mean that these new sorts of type expressions can be
used in exactly the same ways as existing type expressions. In particular,
it should be possible to cast a value expression to one of these sorts of
types, and to test whether an object is an instance of such a type.
c) Reflection should recognize generic type definitions, and provide accurate information about formal type parameters in classes, interfaces and methods

It is explicitly not required that the system

a) Provide downward binary compatibility: It is not necessary that class
files compiled under the generic compiler should run on previous releases, whether they
use generics or not.
b) Support the use of primitive types as type arguments: While allowing the use of primitive types (e.g., int, boolean) as type arguments would be nice, it should not be a goal of the design. The separation of primitive and reference types is a fundamental property of the Java programming language.

The Nextgen proposal is upward compatible with GJ. It differs primarily in that it provides run time support for generic types in exchange for weaker compatibility properties. See:
"Compatible Genericity with Run-time Types for the Java(tm) Programming Language", Robert Cartwright and Guy Steele, Proceedings of the 13th ACM Conference on Object Oriented Programming, Systems and Applications, Vancouver, B.C., October 1998.

The PolyJ system was developed at MIT. For documentation and an implementation, see http://www.pmg.lcs.mit.edu/polyj/.