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
