Towards better serialization
Brian Goetz
brian.goetz at oracle.com
Tue Jun 11 23:01:38 UTC 2019
>> 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".
More information about the amber-spec-experts
mailing list