Proposal: #ReflectiveAccessToNonExportedTypes: `exports dynamic`

[Alex Buckley]

Volker,

Even if reflection was enabled by default, you could be sure that JDK 
modules would choose to disable reflection on their internal APIs. 
-XaddExports would still be needed to make your code run.

Also, it seems like your code is sensitive to the application class 
loader whose implementation has changed in JDK 9. Please see JEP 260 and 
the "Class loaders" section of JEP 261.

Alex

On 7/2/2016 3:09 PM, Volker Berlin wrote:
> 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).
>>
>