Updated Draft specs for JEP 359 (Records)

Chris Hegarty chris.hegarty at oracle.com
Thu Oct 31 20:10:49 UTC 2019



> On 31 Oct 2019, at 17:14, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> 
> On 31/10/2019 16:11, Chris Hegarty wrote:
>> 
>>> On 31 Oct 2019, at 15:29, Brian Goetz <brian.goetz at oracle.com> wrote:
>>> 
>>>> "It is a compile-time error for a record declaration to declare a record component with the name |clone|, |finalize|, |getClass|, |hashCode|, |notify|, |notifyAll|, |readObjectNoData|, |readResolve|, |serialPersistentFields|, |serialVersionUID|, |toString|, |wait|, or |writeReplace|."
>>>> 
>>>> Chris says that the serialization spec ignores all the serialization-related methods if they appear inside a record; should we lift the restrictions?
>>> But, I think we later decided we are not ignoring _all_ of the serialization-related methods — that a readResolve() method is OK.
>> 
>> FTR
>> 
>> For records, the serialization runtime does consider the following:
>> 
>>   1) writeReplace(), readResolve(), and
>>   2) the serialVersionUID field
>> 
>> The serialization runtime ignores the following:
>> 
>>   a) writeObject, writeObjectNoData, readObject, and
>>   b) serialPersistentFields, and
>>   c) writeExternal and readExternal - for what they’re worth!
> 
> Ok, so, error on (1) and (2) and warnings in all the other cases?

In terms of restrictions on record component name...

 - 1 and 2 should be errors
 - I think that a, b, and c, should probably be errors too. It would be super confusing to the reader to see component, field, accessors, names with such names. But if not errors, warnings would be good.

In terms of javac restrictions in the record declaration…

 - 1 and 2 much be allowable, no issue
 - a, b, and c, should be lint warnings.

-Chris.



More information about the amber-dev mailing list