Proposal: Allow illegal reflective access by default in JDK 9
cedric.champeau at gmail.com
Thu May 18 15:22:11 UTC 2017
This looks like a very reasonable proposal, +1
2017-05-18 16:48 GMT+02:00 <mark.reinhold at oracle.com>:
> 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  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:
> 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.
> This causes a warning message to be issued for each illegal
> reflective-access operation. This is equivalent to the current
> `--permit-illegal-access` option.
> 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
> 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.
> - 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" . 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.
> - Mark
>  http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-
>  http://openjdk.java.net/jeps/260
More information about the jigsaw-dev