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
