Proposal: Allow illegal reflective access by default in JDK 9

[Markus Keller]

The command-line argument and the default mode sound good.

`--illegal-access=quiet` could be added for use by clients that cannot 
cope with additional warning messages.

The second ingredient for broad compatibility with Java 8 would be an 
automatic --add-modules=ALL-SYSTEM.
This could be implemented as an automatic compatibility mode in Java 9 
that would only be active as long as there's no --modulepath on the 
command line.

An alternative to automatic compatibility would be another sub-option for 
--illegal-access, so that affected end users only have one command-line 
argument for all accessibility concerns, e.g.:

  `--illegal-access=permit-all`

    Equivalent to `--illegal-access=permit --add-modules=ALL-SYSTEM`


FYI: In the Eclipse launcher for the Oxygen (4.7) release, we've added 
forward-compatibility handling for --permit-illegal-access. Our deadline 
to revert/adjust that is May 30 ( https://bugs.eclipse.org/516911 ).

Regards,
Markus


"jigsaw-dev" <jigsaw-dev-bounces at openjdk.java.net> wrote on 2017-05-18 
16:48:40:

> From: mark.reinhold at oracle.com
> To: jigsaw-dev at openjdk.java.net
> Date: 2017-05-18 16:49
> Subject: Proposal: Allow illegal reflective access by default in JDK 9
> Sent by: "jigsaw-dev" <jigsaw-dev-bounces at openjdk.java.net>
> 
> 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
>