Find JSRs
Submit this Search

Ad Banner

Summary  |  Proposal  |  Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 14: Add Generic Types To The JavaTM Programming Language

Stage Access Start Finish
Final Release Download page 30 Sep, 2004  
Final Approval Ballot View results 31 Aug, 2004 13 Sep, 2004
Proposed Final Draft 2 Download page 18 Aug, 2004  
Proposed Final Draft Download page 27 Jul, 2004  
Public Review Download page 07 May, 2001 01 Aug, 2001
Community Draft Ballot View results 02 Oct, 2000 09 Oct, 2000
Community Review Login page 07 Sep, 2000 09 Oct, 2000
CAFE   18 May, 1999 05 Jul, 1999
JSR Approval   11 May, 1999 17 May, 1999
Status: Final
JCP version in use: 2.1
Java Specification Participation Agreement version in use: 1.0

Extending the JavaTM programming language with generic types (aka parameterized types).

Please direct comments on this JSR to the Spec Lead(s)

Specification Leads
  Alex Buckley Oracle
Expert Group
  Borland Software Corporation Marx, Stefan Odersky, Martin
  Oracle Software AG Sun Microsystems, Inc.

Updates to the Original Java Specification Request (JSR)

The following updates have been made to the original JSR.


Maintenance Lead: Alex Buckley
E-Mail Address:
Telephone Number: +1 408 276 3065


Maintenance Lead: Danny Coward

E-Mail Address:

Telephone Number: +1 408 276 7049

Fax Number: +1 408 276 7700

2.11 Please describe the anticipated schedule for the development of this specification.

It is intended that this JSR will be delivered as part of the J2SETM "Tiger" release.

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 is now posted at
Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1: Identification

Submitting Participant: Sun Microsystems
Name of Contact Person: Gilad Bracha
E-Mail Address:
Telephone Number: 408-863-3116
Fax Number: 408-343-1797

Section 2: Request

2.1 Please describe the proposed Specification:
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.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)
All platforms
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 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.

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, com.something, etc.)
2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?
2.8 Are there any security issues that cannot be addressed by the current security model?
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 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.

The PolyJ system was developed at MIT. For documentation and an implementation, see

3.2 Explanation of how these items might be used as a starting point for the work.
The specifications listed above could be used as a basis for the public draft. Where they fall short of stated goals or constraints, further work will be needed to determine the best course of action.

*As used on this web site, the terms "Java virtual machine" or "JVM" mean a virtual machine for the Java platform.