Patterns for libraries to access private state of user modules

[Gunnar Morling]

2017-11-13 20:18 GMT+01:00 Alan Bateman <Alan.Bateman at oracle.com>:

> On 13/11/2017 16:54, David Lloyd wrote:
>
>> :
>> My understanding is that you should be using
>> MethodHandlers.privateLookupIn(userClazz, lookup()); and that the user
>> module should be "open" to you (i.e. they have to opt in to granting
>> reflection access).  Part of this was tied up in the discussion around
>> the need for standardized module names for spec modules, so a user can
>> choose the right module name:
>>
>>    opens com.mycompany.dao to java.spec.jpa;
>>
>> Then you only need a Lookup from the "java.spec.jpa" module to create
>> the private lookup in the user class.
>>
>> Yes, this is one approach. The application module will require the JPA
> module and at the same time open the packages with classes that have
> annotations on private members to the JPA module. If JPA is pluggable
> (which I think it is) then the code doing the deep reflection may be in an
> JPA implementation module, in which case the JPA API module may have to
> open the packages to the JPA implementation module.


How would that look like like exactly? I.e. how could the JPA API module
"pass on" the open packages of the user's module to the JPA implementation
module?

I can see how it'd work if the user's module would be an entirely open
module. But it seems desirable to limit it to open up only specific
packages to specific modules (the JPA provider). The user could open to a
specific implementation module of course, but that'd come at the cost of
reduced portability.

JAXB is one example doing this already and it would be good to exercise it
> with other libraries to ensure that it is feasible.
>

Is this happening in the JAXB reference implementation? Would you perhaps
have any pointers to specifics so I could take a look?

>
> The other approach is to have the application module provide the Lookup as
> a capability. For some libraries, Guice for example, there is explicit
> initialization which could be the place to provide the Lookup object.


Yes, what I like about it is that it makes the need for private access more
apparent to the user, if e.g. the library bootstrap is designed in a way
that a Lookup object is mandatory (as opposed to the requirement for
opening up the user's module/packages, which essentially can only be
documented or things will fail at runtime). Although in reality it'd likely
have to be multiple Lookup objects, one for each module of the user
containing entities or similar. It'll be interesting how to collect those
Lookups so they can be passed to the library without making them available
to other modules, too.

But in respect to my initial question you seem to suggest indeed that the
user would have to pass a literal Lookup object which they'd have obtained
themselves. So indeed the user code would have to deal with the specifics
of Lookup objects.


> If you there is no explicit initialization then coercion may be an option,
> maybe at build time or run-time. Coercion is of course much easier if there
> is an app server or container using module layers as it can open any
> package in any module in the layer to other modules.


Right, I think containers have different ways for making this work, be it
via modification of module descriptors, injection of some helper code into
the user's module etc. My original question here was primarily focused on
usage under plain SE and envisioned patterns there.

-Alan
>