A Generic Java Language
Current compiler version: 0.6m
GJ is an extension of the Java programming language that supports
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
and there is extensive
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
of the University of South Australia,
of JavaSoft, and
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.
May 1999: Sun proposes to Add Generics to Java, based on GJ.
Sun has put forward a proposal to
Add Generic Types To The Java Programming Language, based on GJ.
The activity goes by the name JSR 14; it is part of the
Java Community Process;
and is spearheaded by Gilad Bracha, one of the GJ designers.
Comments may be sent to
Sun maintains a
where users can vote to give feedback on which shortcomings in Java they
would like to see fixed. A request to add generics to Java is bug number
and is in
The Top Twenty-five Requests for Enhancements.
(You need to register with Sun's
Java developer connection
to follow the above links.)
May 2001: Sun releases prototype for Adding Generics to Java.
In connection with the above JSR, Sun releases a prototype for
Adding Generics to Java, based on the GJ
compiler. Both object and source are available.
(Again, you need to register with Sun's
Java developer connection
to follow the above link.)
January 2003: Generics headed for inclusion in Java 1.5.
on the status of JSR 14, Gilad Bracha writes:
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.
Guy Steele on GJ
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.
(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.)
Bill Joy on Generics in Java
More mentions of GJ at Java One:
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.
-- Bill Joy, speaking at Java-One, June 1999
Left to right:
Philip Wadler, Martin Odersky, Gilad Bracha, Dave Stoutamire
Making Java easier to type, and easier to type
Comments and bug reports to the Pizza Group,
Java is a trademark of
All software and documents on the Pizza site are © Copyright
1996, 1997 by the respective authors as attributed on each.