----- Mail original ----- > De: "Brian Goetz" <brian.go...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "amber-spec-experts" <amber-spec-experts@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
