> De: "Vicente Romero" <[email protected]> > À: "Remi Forax" <[email protected]>, "Chris Hegarty" > <[email protected]> > Cc: "amber-spec-experts" <[email protected]> > 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:[email protected] | >>> <[email protected]> ] >>> À: "Vicente Romero" [ mailto:[email protected] | >>> <[email protected]> ] >>> Cc: "amber-spec-experts" [ mailto:[email protected] | >>> <[email protected]> ] >>> 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:[email protected] | >>>> [email protected] ] > 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
