GJ is an extension of the Java programming language that supports
generic types.

Support for generics. Many data types are generic over
some other data type, and this is especially common for reusable
libraries such as collection classes. GJ supports the use of such
types, for instance allowing one to write the GJ type
Vector<String> as opposed to the Java type
Vector. With GJ, fewer casts are required, and the compiler
catches more errors.

Superset of the Java programming language. Every
Java source program is still legal and retains the same meaning in GJ.
The GJ compiler can be used as a Java compiler.

Compiles into the Java Virtual Machine. GJ compiles
into JVM code, so GJ programs run on any Java platform, including Java
compliant browsers. Class files produced by the GJ compiler can
be freely mixed with those produced by other Java compilers.

Compatible with existing libraries. One can call
any Java library function from GJ, and any GJ library function from
Java. Further, where it is sensible,
one can assign GJ types to existing Java libraries. For instance,
the GJ type Vector<String> is implemented by the
Java library type Vector.

Efficient translation. GJ is translated by erasure: no
information about type parameters is maintained at run-time. This
means GJ code is pretty much identical to Java code for the same
purpose, and equally efficient.

Freely available and fully documented. The GJ compiler
is itself written in GJ, so it runs on any platform that supports
Java. The GJ compiler is available for
download,
and there is extensive
documentation.

Related work.
There are several related attempts to add
generic types to Java, including our previous work on Pizza. GJ differs from these in that it
places a premium on compatibility with old Java programs,
which is important to developers that want to evolve smoothly from
Java to GJ.

GJ was designed by
Gilad Bracha
of JavaSoft,
Martin Odersky
of the University of South Australia,
David Stoutamire
of JavaSoft, and
Philip Wadler
of Bell Labs, Lucent Technologies.
Although JavaSoft employees contributed to its design, GJ is not a
product of JavaSoft or Sun Microsystems and neither JavaSoft nor Sun
Microsystems makes any claims regarding it.

Our expectation is that generics will be formally adopted through the JCP
[Java Community Process] and will ship in the next
major release of the JDK , JDK1.5.
The final specification will be integrated into the Java Language Specification,
3rd edition, which should be published before generics ship.

GJ is an excellent design and implementation for adding generic types
to the Java programming language. It provides a workable and practical
facility for the immediate future that can solve many of today's
problems in programming and debugging. In the long term, I would hope to
see it compatibly extended to carry run-time type parameter information
in the manner that Robert Cartwright and I have proposed; but even if
that does not occur, GJ as it is currently designed is a useful and
workable tool that deserves widespread study and use.

-- Guy Steele (quoted from e-mail, with permision)

Also: Guy Steele's delightful keynote address at OOPSLA 98,
Growing a Language,
argues that Java will age better if it is extended to
include operator overloading and generic types.
(Available in:
ps,
pdf.)
(This is a preliminary version. The final version was published as: Guy
L. Steele, Jr., ``Growing a Language'',
Journal of Higher-Order and Symbolic Computation
(Kluwer) 12, 3 (October 1999), 221--236.)

We're continuing to work on the idea of catching more of the errors
during development, putting a parameterized type system in the
language. For me, it's not so much to make the language more
expressive, but to get rid of casts so there are less errors found
after you ship the code.

After you ship, it costs you about 10,000 times as much to fix a
software bug, and as a programmer, it's also really annoying. If the
bug is caught at compile time, you're sitting near what's going
on. The code concepts are in your mind. If the bug report comes in
from the field, it gets assigned to bug tracking and eventually makes
it back to your desk or to somebody else's desk, and the thinking that
went into the original design isn't there anymore. You have to reload
your "cache" memory in your brain. So this whole idea of catching
errors up front is a real advantage.