Feedback on proposal for #ReflectiveAccessToNonExportedTypes

[Xavi Miró Guerrero]

Hi,

    in my opinion, the problem here is that there are two types of use 
cases that need a different "default" behavior with respect to exporting 
packages in runtime and if we decide to use the current behavior, the 
use cases that need to export everything by default in runtime can lead 
to cumbersome configuration, because the packages must be exported one 
by one. If we had a way to specify that we export in runtime all the 
packages (with "ALL" or "*"), then in one single line we would be able 
to express what we want to do. For instance:

..
exports dynamic ALL to java.ee;
exports dynamic ALL to org.springframework.core;
..

or if it's necessary:

..
exports dynamic ALL;
..

   Although my projects' use cases wouldn't need to export in runtime 
many packages, I can imagine an application with dependency injection, 
where the majority of classes have DI annotations (like "@Inject") that 
must be read in runtime by the DI framework. As the application is built 
by assembling a lot of classes annotated with this framework's 
annotation types, the packages needed to be exported could be a lot. 
Thus, exporting all of the packages in runtime can be cumbersome and 
having a one line export statement can be useful.

   The suggestion of Simon to reverse the runtime export behavior is 
interesting, but I'm not sure that this must be the default. I 
personally prefer that the packages are unexported (even in runtime) by 
default and specify what to export (and to whom, if possible, with the 
qualified version of it). For the use cases where all the packages must 
be exported in runtime, or when there are too many to be specified 
manually, a "ALL" or "*" wildcard would help.

   Best regards,

        Xavi

On 09.07.2016 23:07, Simon Nash wrote:
> Paul Benedict wrote:
>> For those who are still supporters of preventing non-exported types from
>> being reflected, I think a compromise can still be found, but it's 
>> not in
>> this proposal. Here are two other alternatives I hope the EG will 
>> consider:
>>
>> 1) Introduce a new permission type to allow non-exported types to be
>> reflected. I don't find it acceptable the module gets to dictate what 
>> can't
>> be reflected. I believe this should be controlled and configured 
>> externally
>> -- certainly not the module itself.
>>
>> 2) Allow layers to control if non-exported types can be reflected. 
>> Perhaps
>> the JDK sets its own layers to "false", but Containers and what they 
>> deploy
>> can be separately configured, each. For example, maybe WebLogic won't 
>> allow
>> itself to have its non-exported types reflected, but if each EAR gets 
>> its
>> own layers, I could configure WebLogic to allow me to reflect everything
>> within the EAR.
>>
>> PS: I don't see #1 and #2 to be mutually exclusive.
>>
>> Cheers,
>> Paul
>>
> I would like to propose another possible compromise that might satisfy 
> both
> of the following requirements that have been expressed on this thread:
>
> 1) My module should completely encapsulate some internal classes and make
>    them invisible to the outside world
>
> 2) My module or library needs reflective access to internal classes in
>    other modules in order to function correctly
>
> At present, a module can mark its packages as:
>  exported at compile time and runtime
>  exported only at runtime via reflection
>  never exported (the default)
>
> Instead, these options could change to:
>  exported at compile time and runtime
>  exported at runtime only via reflection (the default)
>  never exported (hidden)
>
> This would allow modules to mark certain packages as "hidden" if these
> packages contain internal methods or fields that should be never be
> accessible externally under any circumstances.  The default would be
> to allow reflection by other modules or libraries that need such access.
>
>  Simon
>