forbidding serialization methods as members of records

[forax at univ-mlv.fr]

> De: "Vicente Romero" <vicente.romero at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>, "Chris Hegarty" <chris.hegarty at oracle.com>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Jeudi 31 Octobre 2019 13:51:04
> Objet: Re: forbidding serialization methods as members of records

> On 10/31/19 8:33 AM, Remi Forax wrote:

>>> De: "Chris Hegarty" [ mailto:chris.hegarty at oracle.com |
>>> <chris.hegarty at oracle.com> ]
>>> À: "Vicente Romero" [ mailto:vicente.romero at oracle.com |
>>> <vicente.romero at oracle.com> ]
>>> Cc: "amber-spec-experts" [ mailto:amber-spec-experts at openjdk.java.net |
>>> <amber-spec-experts at openjdk.java.net> ]
>>> Envoyé: Jeudi 31 Octobre 2019 13:25:53
>>> Objet: Re: forbidding serialization methods as members of records

>>>> On 31 Oct 2019, at 12:21, Vicente Romero < [ mailto:vicente.romero at oracle.com |
>>>> 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.

>> It is necessary from a user point of view to have a javac error, having
>> something that silently fails is the worst in term of user experience.

> would a warning be an option?
Why letting the option for a user to shoot itself in the foot ? It's not like it will work sometimes. 

Rémi 

>>> -Chris.

>> Rémi

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