
==========> jsr14_adding_generics-2_2-ea

Changes are primarily bug fixes and stabilization of the compiler.
The previous (2_1) release was internal only.

We now require using a 1.4.2 bootstrap VM.  It might work with 1.4.1,
but I won't support that anymore.

==========> jsr14_adding_generics-2_1-ea

We have dropped variant type parameters from the prototype.  Based on
feedback received, we believe this syntax is simply to difficult.  We
are not putting anything like variant arrays into the language in
Tiger.  Instead, we are simply disallowing all of the constructs
involving arrays that are not sound.  Consequently, we have removed
from the prototype download the documents describing variance, and the
compiler no longer supports it.  We continue to investigate
alternatives that would allow arrays to be used with generic classes
for some future release.

This version contains support for wildcard and bounded wildcard type
parameters, a feature of the draft JSR14 spec that has previously been
missing from the prototype.  This lets you use more concise signatures
for many generic methods.  The method

	<T extends E> void addAll(Collection<T> c);
is now written
	void addAll(Collection<? extends E> c);
using an "extends bounded wildcard".

while the method

	<U extends Comparable<U>, T extends U> void sort(List<T> l);
is now written
	<T extends Comparable<? super T>> void sort(List<T> l);
using a "super bounded wildcard".

the method
	<T> void shuffle(List<T> l);
is now
	void shuffle(List<?> l);
using an "unbounded wildcard".

There are occasional situations that can be expressed using wildcards
that were previously inexpressible.  See, for example, the classes in
java.lang.ref.

We hope you find wildcards more readable than variance.  The syntax
for wildcard types is due to Neal Gafter, Gilad Bracha, Lars Bak, and
Bob Deen.

The syntax for varargs has changed slightly to improve readability.
The new syntax is due to James Gosling:

	void printf(String fmt, Object... args);

Within this method, the "args" variable is of type Object[].

Boxing and unboxing conversions are currently only implemented as
argument conversions.  It is almost certain that this is not what the
JSR 201 expert group will specify.  When we have more guidance from
JSR 201, we will update the prototype.

==========> jsr14_adding_generics-2_0-ea

There have been substantial changes since the last prototype.  Most
significantly, we have added support for variant type parameters.  You
should consider this experimental, but this set of features is under
serious consideration.  We solicit your *early* feedback on this issue
in particular.  Please tell us whether you used variance or not, 
whether you liked it or not, and any other comments you might have.

See variance-whitepaper.pdf and variance-overview-slides.pdf for a
discussion of the variance feature and its rationale.

The introduction of variance is incompatible with earlier releases of
the jsr14 prototype.  If you have existing generic code that wont
compile with this feature because of the language change, you can get
generics without variance by using the -novariance compiler flag.  

Specifically, the incompatibility is this: variance enabled dialect
introduces statically safe array types, and requires that arrays that
have parameterized types as their component types use the statically
sound arrays.

If we include variance in the Tiger release of J2SE, we won't support
the -novariance flag, so you will be forced to port your code to the
new syntax.  Since the generification of the core classes depends on
whether or not variance is available in the language, we have included
stubs for variance enabled and variance disabled.  We provide the
script scripts/javac-novariance to invoke the compiler without
variance against stubs for the generic (but nonvariant) platform
classes, so that the compiler used in this way is largely compatible
with the previous JSR14 prototype.

There is now a syntax for explicitly giving type arguments to generic
method calls.  The various forms are

	Classname.<typeargs>methodname(arguments)
	expression.<typeargs>methodname(arguments)
	<typeargs>super(arguments)
	expression.<typeargs>super(arguments)
	<typeargs>this(arguments)
	new <typeargs> Typename(arguments)
	expression.new <typeargs>Typename(arguments)

With the inclusion of this explicit syntax, we have also significantly
simplified the specification for type inference.  

We have changed the behavior of type inference in the case where
the context in which the method call expression appears is used. 
Specifically, inference is now less sophisticated about when the
call is in the context of an argument position to a (possibly overloaded) 
method call.  This makes litle difference in most typical Java code.  

You may notice the difference if you write functional-style programs
in which the type arguments cannot be inferred from the method's value
arguments.  To get the old behavior, use the secret compiler flag
-complexinference.  That flag will not be supported in the product, so
please chime in now if you have a preference on way or another.

With variance comes a generification of class Class.  T.class is now
of type Class<T>; for primitives, the argument is the boxed version,
so int.class is of type Class<Integer>.  java.lang.reflect.Constructor
is now generic as well.  As a result of these changes,
T.class.newInstance() is of type T!

This version of the compiler also includes support for a number of
other language features anticipated in 1.5.  Specifically, the
features being discussed under JSR201.  The features supported include
static import, the extended for loop, enums, autoboxing and unboxing,
and varargs.

In addition to these changes, we have fixed hundreds of bugs in the
compiler.  Admittedly, most of those have nothing to do with generics.
Regrettably, a handful of known generics bugs remain.

==========> jsr14_adding_generics-1_3-ea

Generics are now enabled using
	-source 1.5
rather than the previous
	-gj

The -source 1.5 flag appears in the scripts provided to invoke the
compiler, so when using those scripts generics are enabled by default.

We now require you use a 1.4.1 or later JDK due to changes in the
packaging of the compiler.

This update fixes all known bugs both in generics and in the
underlying java compiler, with the exception of the following generics
issues:

http://developer.java.sun.com/developer/bugParade/bugs/4739399.html
     crash after error regarding bounds on type variable
http://developer.java.sun.com/developer/bugParade/bugs/4736963.html
     failing regression test
http://developer.java.sun.com/developer/bugParade/bugs/4738171.html
     problem with equivalence of generic types
http://developer.java.sun.com/developer/bugParade/bugs/4668254.html
     problems with proposed signature for Collections.unmodifiableCollection
http://developer.java.sun.com/developer/bugParade/bugs/4757416.html
     erasure clash not detected.
http://developer.java.sun.com/developer/bugParade/bugs/4711572.html
     problem with type inference for recursive methods

and the following non-generics issue whose resolution will likely
require JLS changes and has therefore been deferred:

http://developer.java.sun.com/developer/bugParade/bugs/4758654.html
     incorrect overload resolution for super.method() when inherited abstract

Other than adding support for generics, this compiler is (probably)
very close to the one that will be shipped in Sun's J2SE 1.4.2.

==========> jsr14_adding_generics-1_2-ea

Sorry, I didn't provide a change log for 1.2.

==========> jsr14_adding_generics-1_1-ea

Changed comments and environment variables to require using a 1.4 VM
instead of a 1.3 VM because the compiler and stubs now use features
new to 1.4.

Added scripts/javac.bat (thanks to Steven Chapel of McGraw-Hill).

==========> jsr14_adding_generics-1_0-ea

Initial version.

