Is there a final specification of Java generics?

Question

The longer I look into the draft specification the more mysterious it looks to me. This cannot be the final specification of a new language feature. Does anybody know where the feature is actually specified?
Just as an example: page 13 of the draft spec (dated April 27, 2001) says:
Given the method declarations:
static <A> Seq<A> nil() { return new Seq<A>(); }
static <A> Seq<A> cons(A x, Seq<A> xs)
{ return new Seq<A>(x, xs); }
The following is a legal expression:
cons(new IOException(), cons(new Error(), nil())) // of type: Seq<Throwable>
The generics compiler, however, rejects it saying:      
cons<A>(A,Seq<A>) cannot be applied to (IOException,Seq<Error>)
Frankly said, I think, the compiler is right and the draft specification is wrong. Seemingly the idea of type parameter inference is that each actual argument type is a subtype of the corresponding formal argument type that was found by means of type parameter inference.
In the example above, if type Throwable were deduced for the type variable A, then the first formal method argument were of type Throwable and the actual argument would be of a subtype, namely IOException. Fine. But the second formal method argument would then be Seq<Throwable> and the actual argument is a Seq<Error>, which is not a subtype of Seq<Throwable>. I think, there is no parameter inference possible that makes sense for this example. Hence the compiler rightly rejects it.
I guess, obvious mistakes like this have long been fixed in the specification. Where is the most recent release of the spec? I could not find anything on Sun's website.

Answer 1

Just to be more helpful, my corrected grammar for MethodInvocation is:
MethodInvocation ::= MethodExpr ( ArgumentListOpt )
MethodExpr     ::= MethodName
           |  Primary . TypeArgumentsOpt Identifier
           |  super . TypeArgumentsOpt Identifier
           |  Name . super . TypeArgumentsOpt Identifierwhile the original grammar contained this production:
MethodExpr     ::= TypeArgumentsOpt MethodName
                 |  ...Type arguments in front of an unqualified method name can't be unambiguously parsed, so they have been made illegal. You need to use a primary (a class expression for non-static methods or a class name for static methods) to resolve the ambiguity.
Similarly, the corrected constructor invocation productions are:
ClassInstanceCreationExpression ::= new TypeArgumentsOpt
     ClassOrInterfaceType ( ArgumentListOpt ) ClassBodyOpt
                     |  Primary . new TypeArgumentsOpt
     Identifier TypeArgumentsOpt ( ArgumentListOpt ) ClassBodyOptwhile the original was:
ClassInstanceCreationExpression ::= TypeArgumentsOpt new
                     ClassOrInterfaceType TypeArgumentsOpt
                                            ( ArgumentListOpt ) ClassBodyOpt
                                    |  Primary.TypeArgumentsOpt new
                     Identifier TypeArgumentsOpt
                                            ( ArgumentListOpt ) ClassBodyOpthere the placement of the TypeArguments productions had to be moved in order to resolve grammar ambiguities; in addition "ClassOrInterfaceType" already includes an optional final TypeArguments clause, and so the extra one in the first alternative needed to be removed.