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.
