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