On 28/12/2016 07:30, Andrew Guibert wrote:


In the currently accepted proposal for #ReflectiveAccessToNonExportedTypes
[1], it is described that an entire module can be opened with the following
example:

open module foo.bar {
     exports com.foo.bar;
     requires hibernate.core;
     requires hibernate.entitymanager;
}

The current syntax for --add-opens option is:

   --add-opens <module>/<package>=<target-module>(,<target-module>)*

Namely, the --add-opens option can only be used to open specific packages
from a module, whilst in a module-info.java it is possible to open an
entire module with a single directive. Therefore, I would like to propose
altering the --add-opens option to more closely match what is achievable in
a module-info file, such as:

   --add-opens <module>[/<package>]=<target-module>(,<target-module>)*

So if a <package> is not specified, the entire module would be open for
deep reflection at run time.

Being able to open an entire module with a single JVM option will ease the
migration of existing java programs to the new modular JDK.
As Nicolai notes, the `--add-opens` option can't be used to open a package unconditionally, it is instead the equivalent of the reflective addOpens to open a package to specific modules (or "all unnamed modules" via a special token). There has been suggestions along the way for a option that forces a module to open all its packages but that has been avoided to date, mostly because it would be an attractive nuisance.

Have you looked at the @-file support? If you need a large number of `--add-opens` options then it might be easier to put them in a file and specify them to the java launcher as an @-file.

-Alan




Reply via email to