Home
Mirrors
Distribution
Documents
Applications
People
Related
FAQ

A Generic Java Language Extension

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.

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.

Sun maintains a Bug Parade 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 4064105, 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.)

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.)

In an update 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.

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.

-- Bill Joy, speaking at Java-One, June 1999

• Bill Joy on GJ (see answer to first question, on parametric types).
• James Gosling on GJ (see answer to fifth question, on templates).

Left to right: Philip Wadler, Martin Odersky, Gilad Bracha, Dave Stoutamire

Making Java easier to type, and easier to type