Towards better serialization

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Mercredi 12 Juin 2019 01:01:38
> Objet: Re: Towards better serialization

>>> There are surely a range of options here, but the one you propose takes
>>> two orthogonal considerations and couples them -- which is reinventing
>>> one of the sins of original serialization.  (And, other frameworks
>>> (e.g., dependency injection, mocking, etc) have similar need for dynamic
>>> access to members that are not intended as part of the "front door" API
>>> anyway.)
>> you want to special mechanism for the serialization, no ?
> 
> No, I want an _unspecial_ mechanism for the serialization.  I want the
> user to code with ordinary constructors and pattern extractors, and have
> serialization just call them, informed by metadata (which is how we pass
> information to frameworks.)
> 
>> Otherwise, we already have java.lang.invoke.Lookup.privateLookupIn() and the
>> open keyword on the module/package.
> 
> Yes, Lookup is a possible implementation mechanism for such an relaxed
> encapsulation mechanism.  But aligning with what modules do, just at a
> finer-grained level, is extending an existing concept in a natural way,
> which seems preferable to adding a new concept to the programming model.
> 
>> It already encodes the semantics "we believe in encapsulation but sometimes we
>> don't".
>> Having a finer grain version of "open" goes against what was decided by the JPMS
>> EG in my humble opinion.
>>
> 
> We could surely ditch it, and say "If you want to have serializable
> classes in your module, open the whole module."  And some users might be
> OK with that, even though it is squashing a bug with a tank.  But, in
> reality this _is_ a new category of accessibility modifier -- that a
> method is dynamically accessible regardless of its static
> accessibility.  And having this appear clearly in the source file makes
> it much more obvious what is going on.  The high-order bit here is
> "banish the magic".

I understand that you want a more fine grained mechanism but i don't think we need it (see a sibling thread) and changing the security model of Java AGAIN is really time consuming for a lot of people (every frameworks / languages that are using the reflection has to be fixed).
I would prefer that part to be considered separately to avoid us developers to have to wait a long time to have all the other good fixes to the serialization that you are proposing.

Rémi