--add-opens for entire module

[Andrew Guibert]

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. Specifically,
it will allow developers to get our programs up and running in "toleration"
mode more quickly, and then tackle a fine-grained set of open packages on a
per-module basis.

[1]
http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-October/000430.html

[Nicolai Parlog]

Hi Andrew,

I think this is a great idea but would like to point out that the
syntax proposal is inconsistent. It looks like it would allow a module
to be opened to specific target modules:

--add-opens some.module=other.module

This is something that the module description does not allow - a
module is either open or not. Maybe you meant this?

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

so long ... Nicolai

Post by Andrew Guibert
In the currently accepted proposal for
#ReflectiveAccessToNonExportedTypes [1], it is described that an
open module foo.bar { exports com.foo.bar; requires
hibernate.core; requires hibernate.entitymanager; }
--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
--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. Specifically, it will allow developers to get our programs up
and running in "toleration" mode more quickly, and then tackle a
fine-grained set of open packages on a per-module basis.
[1]
http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-October/

000430.html
- --

PGP Key:
http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509

Web:
http://codefx.org
a blog about software development
https://www.sitepoint.com/java
high-quality Java/JVM content
http://do-foss.de
Free and Open Source Software for the City of Dortmund

Twitter:
https://twitter.com/nipafx

[Alan Bateman]

Post by Andrew Guibert
In the currently accepted proposal for #ReflectiveAccessToNonExportedTypes
[1], it is described that an entire module can be opened with the following
open module foo.bar {
exports com.foo.bar;
requires hibernate.core;
requires hibernate.entitymanager;
}
--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
--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

[Andrew Guibert]

Date: 12/30/2016 12:23 AM
Subject: Re: --add-opens for entire module

Post by Andrew Guibert
In the currently accepted proposal for

#ReflectiveAccessToNonExportedTypes

Post by Andrew Guibert
[1], it is described that an entire module can be opened with the following
open module foo.bar {
exports com.foo.bar;
requires hibernate.core;
requires hibernate.entitymanager;
}
--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
--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.

I'm not proposing to alter `--add-opens` so that it opens every package to
every module -- I agree that would be bad. Instead, I am proposing that we
remove the package as a required option and, if omitted, all packages would
be opened.

So instead of this:
--add-opens foo.bar/foo.pkg1=my.module
--add-opens foo.bar/foo.pkg2=my.module
--add-opens foo.bar/foo.pkg3=my.module

We can simply do:
--add-opens foo.bar=my.module

As a java program maintainer, I do not see this as an attractive nuisance,
but rather a convenience, by lowering the barrier to entry on java 9. Yes
it does encourage developers to take broader strokes while migrating to
java 9 for the first time, but between reads/exports/opens needing to be
sorted out there is already a lot of work that will need to be done by
maintainers. In my opinion, being able to take broader strokes initially
and then work through the options later on at a more fine-grained level
later will make the transition to java 9 much more fluid.

`--add-opens` options then it might be easier to put them in a file and

I had not seen this option before, and I'm glad there is a way to move
these options to a separate file (since my JVM options list is getting
quite large). However, my main goal with this suggestion was to ease the
burden of sorting out jvm options before being able to run an existing
program on java 9, not that my java command was getting too large.