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