Updated Draft specs for JEP 359 (Records)

Alex Buckley alex.buckley at oracle.com
Thu Nov 21 20:24:29 UTC 2019

On 11/21/2019 7:01 AM, Gavin Bierman wrote:
> A hopefully final draft language spec for JEP 359 (Records) is available at:
> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191121/specs/records-jls.html
> This incorporates (I hope!) all the very helpful suggestions from everyone on these lists - many thanks.

1. 8.10.1 says "As a record component corresponds to an accessor method, 
restrictions on accessor methods (8.10.3) mean that it is always a 
compile-time error for a record header to declare a record component 
with the name finalize, getClass, hashCode, notify, notifyAll, or 
toString." -- `record Foo(int wait){}` is also in error because 8.10.3 
will see that the imp.decl. accessor method `int wait()` is 
override-equivalent with the non-private method `void wait()` in Object. 
Similarly for `record Bar(Object clone){}`. `equals` is a different 
story, and that's a surprise, so explain it -- show `record Quux(boolean 
equals){}` as legal because the accessor method is `public boolean 
equals()` which merely (albeit rather confusingly) overloads the 
inherited `public boolean equals(Object)` method. The relationship 
between each of Object's methods and the implicit record components 
should be spelled out explicitly in the note.

2. 8.10.3: Technical rewording: from "The implicitly declared accessor 
method is annotated with the annotation that appears on the 
corresponding record component, if this annotation type is applicable to 
a method declaration or type context." to "The implicitly declared 
accessor method is annotated with the annotations, if any, that appear 
on the corresponding record component and whose annotation types are 
applicable in the method declaration context or in type contexts or 
both. Note: This means that an annotation on a record component may not 
necessarily be carried over to the corresponding implicitly declared 
accessor method."

3. 8.10.4: A canonical ctor is defined as a public ctor, and then 
there's an error if an explicit canonical ctor is not public. That error 
will never occur because a canonical ctor is always public. This was the 
discussion on November 4, which doesn't seem to have been considered. I 
think "It is a compile-time error if a record declaration contains more 
than one explicit declaration of the canonical constructor." is the 
catch-all solution, but then the JLS must explain in a note why THE 
canonical ctor can have multiple declarations.

4. 8.10.4: Technical rewording: from "The canonical constructor must not 
declare type variables." to "The canonical constructor must not be 
generic (8.8.4)."

I assume the November JVMS draft at 
is still being updated?


More information about the amber-spec-experts mailing list