forbidding serialization methods as members of records

[Brian Goetz]

The language is somewhat schizoid about whether it errors or warns on useless constructs.  (We error on unreachable code, for example.)  And similarly, due to mistakes in 1997, the nature of serialization is somewhat schizoid — it wants to be a library feature, but it really isn’t.  So I think we’re justified here in giving either a warning or an error.  

> On Oct 31, 2019, at 10:15 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> 
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20191031/957438be/attachment-0001.html>