forbidding serialization methods as members of records

[Jerven Bolleman]

Dear Vicente, All,

I second Rémi, I think it is a long standing Java principle to not allow 
dead code as much as possible. It is my belief that this should be true 
here as well. If the code can't do anything it should not be allowed to 
exist.

I can already imagine the hours wasted wondering why code someone wrote 
is not being executed. Especially if upon otherwise reasonable belief it
should have.

Regards,
Jerven

On 10/31/19 1:56 PM, forax at univ-mlv.fr wrote:
>> 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