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