Proposal: #ReflectiveAccessToNonExportedTypes: `exports dynamic`

[Volker Berlin]

Alex,

It is to compensate bugs or handle bad design of JDK components. Mostly 
this are classloader problems. The impossible to make the JDK classes 
via dynamic URLClassLoader available.

For example:

  * register dynamically a JDBC  that is not in the appclassloader to
    all our plugins.
  * register a URL protocol with a protocol handler that is not in the
    appclassloader

Many hacks are needed for test environments. For example:

  * the simulation that there is no console (javaw)
  * inverse classloder hierarchy. In the appclassloader there is a class
    which implements/extends  a class in a dynamic loaded library. The
    current tested classes and the JUnit tests are typical in the
    appclassloader

This are only some points. There can be more. We have used.

Volker Berlin
i-net software


Am 30.06.2016 um 23:02 schrieb 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).
>