Proposal: #ReflectiveAccessToNonExportedTypes: `exports dynamic`

[Alex Buckley]

Volker,

Please share details of why your application needs to reflect over the 
internals of another module.

Alex

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. [1]
>>
>> Proposal
>> --------
>>
>> 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
>> meanings:
>>
>>    - 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).