As I haven't seen it mentioned yet: JDK 9 introduces a new
JDK_JAVA_OPTIONS environment variable. So I'd propose to:
* have `--illegal-access=deny` be the default
* add a `quiet` possibility
* not resolve the java.se.ee module by default
* add a note to the compatibility guide for JDK 9: if you want maximum
compatibility, set `JDK_JAVA_OPTIONS=--illegal-access=quiet
--add-modules=java.se.ee`, but be aware that these options will
dissapear in a future JDK
This way:
* there's no need to to add command-line parameters or manifest entries
anywhere (and since JDK_JAVA_OPTIONS is new in JDK 9, there's no
compatibility impact)
* the defaults are already what they ought to be
I believe the proposed default is a step backwards, and good arguments
have been given against doing this (a.o. by Peter Levart [1]). So the
above seems like a good middle ground to me: the defaults are what they
should be, and legacy behavior is simply a matter of setting an
environment variable.
[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012739.html
Kind regards,
Anthony
On 18/05/2017 16:48, mark.reinh...@oracle.com wrote:
Over time, as we've gotten closer and closer to the JDK 9 GA date, more
and more developers have begun paying attention the actual changes in
this release. The strong encapsulation of JDK-internal APIs has, in
particular, triggered many worried expressions of concern that code that
works on JDK 8 today will not work on JDK 9 tomorrow, yet no advance
warning of this change was given in JDK 8.
To help the entire ecosystem migrate to the modular Java platform at a
more relaxed pace I hereby propose to allow illegal reflective access
from code on the class path by default in JDK 9, and to disallow it in
a future release.
In short, the existing "big kill switch" of the `--permit-illegal-access`
option [1] will become the default behavior of the JDK 9 run-time system,
though without as many warnings. The current behavior of JDK 9, in which
illegal reflective-access operations from code on the class path are not
permitted, will become the default in a future release. Nothing will
change at compile time.
In detail, the recently-introduced `--permit-illegal-access` option will
be replaced by a more-general option, `--illegal-access`. This option
will take a single keyword parameter, as follows:
`--illegal-access=permit`
This will be the default mode for JDK 9. It opens every package in
every explicit module to code in all unnamed modules, i.e., code on
the class path, just as `--permit-illegal-access` does today.
The first illegal reflective-access operation causes a warning to be
issued, as with `--permit-illegal-access`, but no warnings are issued
after that point. This single warning will describe how to enable
further warnings.
`--illegal-access=warn`
This causes a warning message to be issued for each illegal
reflective-access operation. This is equivalent to the current
`--permit-illegal-access` option.
`--illegal-access=debug`
This causes both a warning message and a stack trace to be shown
for each illegal reflective-access operation. This is equivalent
to combining today's `--permit-illegal-access` option with
`-Dsun.reflect.debugModuleAccessChecks`.
`--illegal-access=deny`
This disables all illegal reflective-access operations except for
those enabled by other command-line options, such as `--add-opens`.
This will become the default mode in a future release.
Notes:
- The proposed default mode enables the run-time system to issue a
warning message, possibly at some time long after startup, without
having been explicitly requested to do so. This may be a surprise
in production environments, since it's extremely unusual for the
run-time system to issue any warning messages at all. If the default
mode permits illegal reflective access, however, then it's essential
to make that known so that people aren't surprised when this is no
longer the default mode in a future release.
- Warning messages in any mode can be avoided, as before, by the
judicious use of the `--add-exports` and `--add-opens` options.
- This proposal will, if adopted, require adjustments to JEP 260,
"Encapsulate Most Internal APIs" [2]. APIs that are internal to the
JDK will still be strongly encapsulated from the standpoint of code
in modules, whether those modules are automatic or explicit, but they
will not appear to be encapsulated at run time from the standpoint of
code on the class path.
- When `deny` becomes the default mode then I expect `permit` to remain
supported for at least one release, so that developers can continue
to migrate their code. The `permit`, `warn`, and `debug` modes will,
over time, be removed, as will the `--illegal-access` option itself.
(For launch-script compatibility the unsupported modes will most
likely just be ignored, after issuing a warning to that effect.)
- This change will not magically solve every JDK 9 adoption problem.
The concrete types of the built-in class loaders are still different,
`rt.jar` is still gone, the layout of a system image is still not the
same, and the version string still has a new format.
Comments?
- Mark
[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-March/011763.html
[2] http://openjdk.java.net/jeps/260
