Proposal: #ReflectiveAccessToNonExportedTypes: `exports dynamic`
alex.buckley at oracle.com
Thu Jun 30 21:02:34 UTC 2016
Please share details of why your application needs to reflect over the
internals of another module.
On 6/30/2016 1:09 PM, Volker Berlin wrote:
> Reflection should be enabled by default. My current launcher for Java 9
> check if the needed refection is possible. If not possible then it
> restart the application with a very long list of -XaddExports switches.
> I think this is not what we want.
> Volker Berlin
> i-net software
> Am 28.06.2016 um 23:18 schrieb Mark Reinhold:
>> Issue summary
>> #ReflectiveAccessToNonExportedTypes --- Some kinds of framework
>> libraries require reflective access to members of the non-exported
>> types of other modules; examples include dependency injection (Guice),
>> persistence (JPA), debugging tools, code-automation tools, and
>> serialization (XStream). In some cases the particular library to be
>> used is not known until run time (e.g., Hibernate and EclipseLink both
>> implement JPA). This capability is also sometimes used to work around
>> bugs in unchangeable code. Access to non-exported packages can, at
>> present, only be done via command-line flags, which is extremely
>> awkward. Provide an easier way for reflective code to access such
>> non-exported types. 
>> Extend the language of module declarations so that a package can be
>> declared to be exported at run time but not at compile time. This is,
>> roughly, the dual of the `requires static` construct proposed for
>> #CompileTimeDependences, hence we propose to introduce a new modifier,
>> `dynamic`, for use on the `exports` directive. It has the following
>> - At compile time, `exports dynamic P` does not cause the package `P`
>> to be exported, though it does require `P` to be a package defined
>> in the module.
>> - In phases after compile time, `exports dynamic P` behaves in exactly
>> the same way as `exports P`. It therefore takes part fully in
>> resolution and configuration, and is subject to the same consistency
>> constraints as normally-exported packages (e.g., no split packages).
More information about the jpms-spec-observers