This looks like a very reasonable proposal, +1 2017-05-18 16:48 GMT+02:00 <mark.reinh...@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 [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 >
