Proposal: Allow illegal reflective access by default in JDK 9

[Anthony Vanelverdinghe]

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.reinhold at 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