forbidding serialization methods as members of records

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Thu Oct 31 14:15:36 UTC 2019


On 31/10/2019 14:09, Jonathan Gibbons wrote:
>
> On 10/31/19 5:25 AM, Chris Hegarty wrote:
>>
>>> On 31 Oct 2019, at 12:21, Vicente Romero <vicente.romero at oracle.com> 
>>> wrote:
>>>
>>> Hi,
>>>
>>> In the past we discussed about forbidding the declaration of some 
>>> serialization related methods in records. In particular:
>>>
>>>   writeObject(ObjectOutputStream)
>>> readObjectNoData()
>>> readObject(ObjectInputStream)
>>> I wonder if we still want to enforce that restriction, meaning that 
>>> it should be reflected in the spec, or if it is not necessary anymore,
>> Where we ended up with Serializable Records, is that the runtime is 
>> specified to ignore these methods if they appear in a serializable 
>> record ( there are tests that assert this ).  The javac restriction 
>> is no longer strictly necessary, but of course catches 
>> effectively-useless declarations early, and without resorting 
>> checkers, inspection, etc.
>>
>> -Chris.
>>
> This seems to be in line with the general philosophy of the 
> serialization specification in which candidate declarations for 
> serialization-related members are ignored if they don't fulfill all 
> the required properties.  Without commenting on the merits of the 
> policy, it would at least be good if the policy was consistent. 
> Failing that, a warning (-Xlint:serial) would be in line with current 
> javac behavior.

I think we're talking about useless declarations - to me a warning is 
exactly the right fit for something like this.

There's also a general desire to keep the JLS free from any jargon 
introduced by the serialization spec (and for a good reason). A warning 
gives us flexibility in that respect - an hard error doesn't (as the JLS 
will have to justify it).

Maurizio

>
> -- Jon
>


More information about the amber-spec-experts mailing list