A specification for extending the Java programming
language with generic types. Ultimately, the Java Language Specification
should be revised to integrate the proposed changes. The proposed specification
will include language changes. If necessary, it may contain class file
format changes needed to implement it. These would require Java Virtual
Machine* Specification updates as well.

2.3 What need of the Java community
will be addressed by the proposed specification?

Many programs and libraries written in the Java
(tm) programming language are intrinsically generic. However, the Java
programming language lacks the ability to specify generic types. As a result,
programs are unnecessarily hard to read and maintain, and are more likely
to fail with runtime type errors. This feature is one of the most frequently
requested language extensions on the JDC (no. 7 on the bug parade - no.
2 among language extensions).

2.4 Why isn't this need met by
existing specifications?

This can only be addressed at the language level,
i.e., by the Java Language Specification.

2.5 Please give a short description
of the underlying technology or technologies:

We propose to extend the Java programming language
with notions of genericity based on parametric polymorphism.These are well established constructs for genericity
that have been used by numerous other programming languages, and received
extensive theoretical study.

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

2.6 Is there a proposed package
name for the API Specification? (i.e., javapi.something, org.something,
com.something, etc.)

No

2.7 Does the proposed specification
have any dependencies on specific operating systems, CPUs, or I/O devices
that you know of?

No

2.8 Are there any security issues
that cannot be addressed by the current security model?

No

2.9 Are there any internationalization
or localization issues?

Trivial. Some error messages might need to be
issued in different languages.

2.10 Are there any existing specifications
that might be rendered obsolete, deprecated, or in need of revision as
a result of this work?

Revisions will be needed, primarily the JLS.
Possibly, there may be effects on the JVMS. Optionally, any number of API
specifications should be revised to reflect their generic type signatures.
Certainly this would include the Collection API in the core platform.

Section 3: Contributions

3.1 Please list any existing documents,
specifications, or implementations that describe the technology. Please
include links to the documents if they are publicly available.

The GJ specification, as well as a tutorial and
a research paper describing and motivating the design, are all available
at http://www.cs.bell-labs.com/who/wadler/pizza/gj/.
The GJ compiler implements the GJ specification, and may be downloaded
at the same website.A candidate revision of the Collection API has
been implemented as part of the GJ implementation.

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.