Updates to the Original Java Specification Request (JSR)
The following updates have been made to the original JSR.
2010年02月15日:
Maintenance Lead: Alex Buckley
E-Mail Address: alex.buckley
Telephone Number: +1 408 276 3065
2006年11月02日:
Maintenance Lead: (削除) Danny Coward (削除ここまで)
E-Mail Address: (削除) danny.coward@sun.com (削除ここまで)
Telephone Number: (削除) +1 408 276 7049 (削除ここまで)
Fax Number: (削除) +1 408 276 7700 (削除ここまで)
It is intended that this JSR will be delivered as part of the J2SETM "Tiger" release.
Identification | Request | Contributions
Section 1: Identification
Section 2: Request
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
It is explicitly not required that the system
a) Provide downward binary compatibility: It is
not necessary that class
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
first-class types.
b) Type parameters (e.g., T) should be first-class
types.
(A consequence of this is that List
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
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.
Section 3: Contributions
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 http://www.pmg.lcs.mit.edu/polyj/.