Towards better serialization

[Kasper Nielsen]

>   - I think you may have over-rotated towards the "reflection is dead"
> meme.  Yes, Lookup is "better" because it is explicit, and allows the
> access checks to be done at lookup time rather than on each invocation.
> But, reflection does things that Lookup does not (or at least, not yet);
> you can't iterate over the methods of a class via a Lookup, let alone
> interrogate them for their annotations, or query their Signature
> attributes, or any number of other things frameworks like to do.  So it
> is likely that frameworks will be using reflection for quite a while,
> and that's OK.

To add to this,

Lookup objects works really well, when you are have a _single_ module that
has a dependency on a _known_ library. And _you_ are in full control of
initializing the library. For non-trivial applications it quickly gets
a bit muddy.

Let's say you have an application that consists of multiple domain modules.
For example, you might have a "customer-module", an "order-module" and
a "fulfillment-module". You are also using DI framework, a JPA framework,
a JaxRS framework, and some kind of serialization framework. Now you are
in a situation where everyone one of your domain modules needs to provide
a Lookup object to each of the frameworks in order to use them. That is
#domainmodules*#frameworks number of lookup objects that needs to be
exchanged.

- So the problem here is the handoff of the Lookup object from one module
to another. One way to solve it is to create a base module for your
application,
and use a ServiceLoader for each of your domain modules to handoff a Lookup
object to the base module that then initializes each framework with the set
of gathered Lookup objects. But now each framework needs to keep track of a
bunch of Lookup objects. And do a lot of matching for every class it needs to
operate on. This gets further complicated if you are adding/removing module
layers at runtime.

- Split-module classes can also turn out to be an issue. A
split-module class is
basically a concrete class that extends an abstract class from another module.
Each of them having an annotated member that you need to access. This is quite
common, for example, when you work with ORMs where you have some kind of
base entity that every one of you entities across modules extend. You are now in
a situation where you need one Lookup object to access members on the abstract
class and another Lookup object to access the members on the concrete class.
This is mainly a burden on those that implement frameworks. But if you
have APIs
with the need to pass Lookup objects ad-hoc you end up contemplating APIs such
as "public <T> inject(Class<T> type, MethodHandles.Lookup... lookups)".

- Finally, the problem about not knowing which serialization framework until
application assembly time, and in many cases deployment time (think a
generic WAR),
is a general problem. And not only applicable to serialization frameworks
And why I think the module system (as is) is going to be a hard sell to someone
like jakarta.ee. You can't say open this module to "jakarta.ee.cdi"
because that's
an API and not an implementation. So your only choice is to open the
whole module.
Or be specific about using "jakartaee-vendor.cdi" in every one of your modules.

> There's also a danger that the search for more accurate permission
> granularity becomes a rathole; for example, the security manager
> permissions model is quite fine-grained, but in reality people rarely
> use that mechanism to tailor just the right security policy -- it's too
> hard, too fussy, too much work, too hard to keep it in sync with what
> the code actually needs.

Yes, I think OSGI is good example. Here you have to specify your
requirements on the package level. I really think that is too much work.
And I much prefer choosing to specify them at the module level as is done now.
I would even say we could relax opening up a module a bit more. And allowing for
opening a whole module to another module. At the moment you can only
open the module to everyone, or you have to specify each package you want
to open to a specific module. This is a bit cumbersome, for example, if you
have a project that consists of 10 packages that all use the same DI framework.

All in all, I really like working with the module system. But it is
heavily skewed
(as designed) towards static system where you have all information upfront.

/Kasper