Proposal: Allow illegal reflective access by default in JDK 9

[Weijun Wang]

I don't like this default value, but I also know some people wanting it.

Is it possible to provide the default value in a file inside the conf 
directory and also make it overwrite-able on the command line? Maybe 
RedHat Linux can make it "permit" out-of-box and other vendors can 
choose different values.

Thanks
Max

On 05/18/2017 10:48 PM, 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
>