Towards better serialization

[Brian Goetz]

>> 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".