Proposal: #ReflectiveAccessToNonExportedTypes: `exports dynamic`

[Volker Berlin]

Alex,

The adaption to JDK 9 was very simple to adapt the changes of the 
classloader. Because we have our own module system (plugins) since 
years. The only difficult is to make the JDK self available some dynamic 
jar files.

Can be that there other, simpler options if we switch to Java 9 as 
minimum version. Then we can define our own modules. But we need to 
support for many years Java 8 and Java 9.

Volker

Am 05.07.2016 um 22:09 schrieb 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).
>>>
>>
>