Patterns for libraries to access private state of user modules

[Alan Bateman]

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. JAXB is one 
example doing this already and it would be good to exercise it with 
other libraries to ensure that it is feasible.

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

-Alan