Updated Draft specs for JEP 359 (Records)

[Gavin Bierman]

I have made a further change to the online version. 

There was a missing case in 8.10.3, as it should be required that an explicitly declared accessor method is not static.

Gavin

gbierman$ hg diff -c 30704:012cc50cb363
diff -r 9f5a21334115 -r 012cc50cb363 closed/src/java.se/share/specs/records-jls.md
--- a/closed/src/java.se/share/specs/records-jls.md	Thu Nov 28 14:06:43 2019 +0000
+++ b/closed/src/java.se/share/specs/records-jls.md	Tue Dec 03 11:27:03 2019 +0000
@@ -2433,6 +2433,8 @@
 
   - The accessor method must be declared `public`
 
+  - The accessor method must not be declared `static`
+
   - The accessor method must not have a `throws` clause
 
   - All other rules for a method in a normal class declaration must be


> On 26 Nov 2019, at 14:17, Gavin Bierman <gavin.bierman at oracle.com> wrote:
> 
> Thanks Alex; have made these changes to the online version.
> 
> Gavin
> 
>> On 26 Nov 2019, at 02:23, Alex Buckley <alex.buckley at oracle.com> wrote:
>> 
>> // Cutting amber-dev
>> 
>> On 11/25/2019 3:23 PM, Gavin Bierman wrote:
>>> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jls.html
>> 
>> The JLS draft is good. Some technical rewordings:
>> 
>> 1. 8.10.3: "and the type as the declared type" -- missing a "same"
>> 
>> 2. 8.10.3: Say "This field is annotated with the annotations, if any, that appear on the corresponding record component and whose annotation types are applicable in the field declaration context or in type contexts or both."  (Later, for implicitly declared accessor methods, the phrase "whose annotation type is" should be "whose annotation types are". We do not constrain all the annotations to have the same annotation type, nor all the annotation types to be applicable in the same way. You could introduce an existential qualifier if you like -- "For each annotation A that appears on the corresponding ..." -- but I don't think it's necessary.)
>> 
>> 3. 8.10.3: "A method ***declared*** in a record type R is said to be an accessor method" -- this raises questions of "explicitly or implicitly". It's too easy to think it means "explicitly" when that's not always true. Sidestep the problem by speaking more directly: "In a record type R, an _accessor method for a record component_ is a method whose name is the same as the name of the record component, and whose formal parameter list is empty." Then some refactoring because long list items are hard to follow:
>> 
>> -----
>> For each record component appearing in the record component list:
>> 1. An implicitly declared private final field ...
>> 2. An accessor method for the record component. [THAT'S IT. DON'T RULE ON THE FORM OF EXPLICITLY DECLARED METHODS HERE. JUST MAKE SURE ALL THE METHODS EXIST:]
>> 
>>  If an accessor method for the record component is not explicitly declared, then one is implicitly declared with the following properties:
>>  - The name is the same as ...
>>  - ...
>> 
>>  It is a compile-time error if the implicitly declared accessor method is override-equivalent (8.4.2) with a non-private method of the class Object. [THIS PARAGRAPH IS TROUBLE. PLEASE MAKE AN EXPLICIT RULE IN 8.10.1 THAT SPELLS OUT IN CLEAR NORMATIVE TEXT THAT A RECORD COMPONENT MUST NOT HAVE BE CALLED CLONE, FINALIZE, ETC. RELYING ON A SUBTLE RULE IN A DIFFERENT SECTION ABOUT IMPLICITLY DECLARED STUFF IS *TOO HARD*. IT SUGGESTS THAT THE COMPILER SHOULD POSITION THE CARET FOR THE ERROR AT SOME POINT IN THE RECORD'S BODY, WHERE THE IMP.DECL. METHOD WOULD LIVE, RATHER THAN IN THE RECORD'S HEADER.]
>> 
>> [ITEM 2 ENDS HERE. NON-LIST TEXT FOLLOWS.]
>> 
>> If an accessor method for a record component is declared explicitly, then it must satisfy the following rules, or else a compile-time error occurs:
>> - The return type of the accessor method ...
>> - ...
>> 
>> [THE FOLLOWING PARAGRAPH IS DISTINCTLY SURE -- "IS NOT ANNOTATED" -- THAT AN EXPLICIT METHOD HAS NO ANNOTATIONS LIKE THE ONES ON THE RECORD COMPONENT. WHAT IF THE DEVELOPER WRITES ANNOTATIONS EXPLICITLY? PLEASE CHANGE THE PARAGRAPH TO AN INFORMATIVE NOTE WHERE YOU CAN SAY: ANNOTATIONS THAT APPEAR ON THE CORRESPONDING RECORD COMPONENTS ARE NOT CARRIED OVER TO EXPLICITLY DECLARED ACCESSOR METHODS, IN CONTRAST TO HOW IMPLICITLY DECLARED ACCESSOR METHODS ARE ANNOTATED ACCORDING TO BLAH BLAH.]
>> An explicitly declared accessor method is not annotated with any applicable annotation that appears on the corresponding record component.
>> -----
>> 
>> 4. 8.10.4: It's odd to see in "derived constructor signature" that a ctor has a name R, since 8.8 doesn't admit to a ctor having a name. That said, 8.8.2 speaks of "two constructors with override-equivalent signatures (§8.4.2) in a class", and the definition of override equivalent implies a name is present, so I'll set my concern aside. Just a minor rewording for flow -- push derivation of formal parameter list down one level, as it's not used by anything else (OK, one place, but I'll get to that) :
>> 
>> -----
>> To support proper ... corresponding to the record components.
>> 
>> A record type R has a derived constructor signature with the name R, with no type parameters, and with a formal parameter list that is derived from the record component list of R as follows:
>> 
>> - For each record component ...
>> -----
>> 
>> 8.10.5: Construct good things, or else people will wonder:  "At most one compact constructor declaration can be declared for a record type." + "In a record type R, the signature of a compact constructor declaration is the _derived constructor signature_ of R (8.10.4)."   Don't say in normative text that "one which is derived from the record component list of R is added implicitly" -- "added" is too imperative -- this is an opportunity to write an informative note that compares and contrasts a compact ctor with all other ctors in Java -- "Unlike ctors in records, and indeed in classes in general, no explicit formal parameter list is given for a compact ctor. The record component list provides the X from which a Y is derived."
>> 
>> Alex
>