Alan Bateman <alan.bate...@oracle.com> wrote on 12/30/2016 12:23:09 AM:
> From: Alan Bateman <alan.bate...@oracle.com> > To: Andrew Guibert/Rochester/IBM@IBMUS, jigsaw-dev <jigsaw- > d...@openjdk.java.net> > Date: 12/30/2016 12:23 AM > Subject: Re: --add-opens for entire module > > 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. 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. > > 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. 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.