Hi all,
below is the proposal for the flag "illegal-access" in Java 9.
TLDR; it controls if the compiler should break the build when making
illegal usage of internal APIs.
With Java 9 its default value will be 'permit' (not as strict as the
original proposal), but its default value WILL change in a future
version.
IMHO from a Maven point of view the result of the compiled code should
always be the same no matter the JDK version. For the same reason we
gave source/target a default value. However, there's a small
difference: in case of a stricter value with a next JDK, there won't be
any result at all so you would notice the difference immediately.
The compiler does display a warning in case it detects illegal-access.
We have a couple of options:
- do nothing
- give illegal-access a default value in case source/target/release >= 9
- introduce failOnIllegalAccess with a default value (true?false?)
- ...
WDYT?
Robert
------- Forwarded message -------
From: mark.reinh...@oracle.com
To: jigsaw-...@openjdk.java.net
Cc:
Subject: Proposal (revised): Allow illegal access to internal APIs by
default in JDK 9
Date: Mon, 05 Jun 2017 20:45:27 +0200
(Thanks for all the feedback on the initial proposal [1]. Here's a
revised version, which incorporates some of the suggestions received
and
includes a bit more advice. An implementation is already available
for
testing in the Jigsaw EA builds [2]. Further comments welcome!)
Over time, as we've gotten closer and closer to the JDK 9 GA date, more
and more developers have begun paying attention to 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 at run time 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-access operations to
internal APIs from code on the class path by default in JDK 9, and to
disallow them in a future release. This will enable smoother
application
migration in the near term, yet still enable and motivate the
maintainers
of libraries and frameworks that use JDK-internal APIs to fix their code
to use proper exported APIs.
New command-line option: `--illegal-access`
-------------------------------------------
The recently-introduced `--permit-illegal-access` option [3] will be
replaced by a more-general option, `--illegal-access`. This option
takes
a single keyword parameter to specify a mode of operation, as follows:
`--illegal-access=permit`
This mode opens each package in each module in the run-time image
to
code in all unnamed modules, i.e., code on the class path, if that
package existed in JDK 8. This enables both static access, i.e.,
by
compiled bytecode, and deep reflective access, via the platform's
various reflection APIs.
The first reflective-access operation to any such package causes a
warning to be issued, but no warnings are issued after that point.
This single warning describes how to enable further warnings.
This mode will be the default for JDK 9. It will be removed in a
future release.
`--illegal-access=warn`
This mode is identical to `permit` except that a warning message is
issued for each illegal reflective-access operation. This is
roughly
equivalent to the current `--permit-illegal-access` option.
`--illegal-access=debug`
This mode is identical to `warn` except both a warning message and
a
stack trace are issued for each illegal reflective-access
operation.
This is roughly equivalent to combining `--permit-illegal-access`
with `-Dsun.reflect.debugModuleAccessChecks`.
`--illegal-access=deny`
This mode disables all illegal-access operations except for those
enabled by other command-line options, e.g., `--add-opens`.
This mode will become the default in a future release.
When `deny` becomes the default mode then `permit` will likely 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.)
How to prepare for the future
-----------------------------
The default mode, `--illegal-access=permit`, is intended to make you
aware when you have code on the class path that reflectively accesses
some JDK-internal API at least once. To learn about all such accesses
you can use the `warn` or `debug` modes. For each library or framework
on the class path that requires illegal access you have two options:
- If the component's maintainers have already released a new,
fixed version that no longer uses JDK-internal APIs then you
can consider upgrading to that version.
- If the component still needs to be fixed then we encourage you
to contact its maintainers and ask them to replace their use
of JDK-internal APIs with proper exported APIs [4].
If you must continue to use a component that requires illegal access
then
you can eliminate the warning messages by using one or more
`--add-opens`
options to open just those internal packages to which access is
required.
To verify that your application is ready for the future, run it with
`--illegal-access=deny` along with any necessary `--add-opens` options.
Any remaining illegal-access errors will most likely be due to static
references from compiled code to JDK-internal APIs. You can identify
those by running the `jdeps` tool with the `--jdk-internals` option.
(JDK 9 does not issue warnings for illegal static-access operations
because that would require deep JVM changes and degrade performance.)
Warning messages
----------------
The warning message issued when an illegal reflective-access operation
is
detected has the following form:
WARNING: Illegal reflective access by $PERPETRATOR to $VICTIM
where:
- $PERPETRATOR is the fully-qualified name of the type containing
the code that invoked the reflective operation in question plus
the code source (i.e., JAR-file path), if available, and
- $VICTIM is a string that describes the member being accessed,
including the fully-qualified name of the enclosing type
In JDK 9's default mode, `--illegal-access=permit`, at most one of these
warning messages will be issued, accompanied by additional instructive
text. Here is an example, from running Jython on the current Jigsaw EA
build [2]:
$ java -jar jython-standalone-2.7.0.jar
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by jnr.posix.JavaLibCHelper
(file:/tmp/jython-standalone-2.7.0.jar) to method
sun.nio.ch.SelChImpl.getFD()
WARNING: Please consider reporting this to the maintainers of
jnr.posix.JavaLibCHelper
WARNING: Use --illegal-access=warn to enable warnings of further
illegal reflective access operations
WARNING: All illegal access operations will be denied in a future
release
Jython 2.7.0 (default:9987c746f838, Apr 29 2015, 02:25:11)
[OpenJDK 64-Bit Server VM (Oracle Corporation)] on java9-internal
Type "help", "copyright", "credits" or "license" for more
information.
>>> ^D
$
If `--illegal-access=warn` is used then only warnings are displayed,
with
no instructive text. The run-time system makes a best-effort attempt to
suppress duplicate warnings for the same $PERPETRATOR and $VICTIM. Here
is an example, again running Jython:
$ java --illegal-access=warn -jar jython-standalone-2.7.0.jar
WARNING: Illegal reflective access by jnr.posix.JavaLibCHelper
(file:/tmp/jython-standalone-2.7.0.jar) to method
sun.nio.ch.SelChImpl.getFD()
WARNING: Illegal reflective access by jnr.posix.JavaLibCHelper
(file:/tmp/jython-standalone-2.7.0.jar) to field
sun.nio.ch.FileChannelImpl.fd
WARNING: Illegal reflective access by jnr.posix.JavaLibCHelper
(file:/tmp/jython-standalone-2.7.0.jar) to field
java.io.FileDescriptor.fd
WARNING: Illegal reflective access by org.python.core.PySystemState
(file:/tmp/jython-standalone-2.7.0.jar) to method
java.io.Console.encoding()
Jython 2.7.0 (default:9987c746f838, Apr 29 2015, 02:25:11)
[OpenJDK 64-Bit Server VM (Oracle Corporation)] on java9-internal
Type "help", "copyright", "credits" or "license" for more
information.
>>> ^D
$
Notes
-----
- There is no `--illegal-access` mode that suppresses all warnings.
This is intentional: It ensures that developers know that all
illegal-access operations will be denied by default in a future
release, at which time code that generates warnings today will
fail.
Warnings can be suppressed completely via one or more `--add-opens`
options.
- The first proposal [1] opened every package in every explicit
module,
rather than just the packages in modules in the run-time image, to
every unnamed module. Peter Levart pointed out [5] that this could
tempt developers to use internal APIs that are new in JDK 9 (e.g.,
`jdk.internal.misc.Unsafe`) and thus make the eventual transition
from JDK 9 no less painful than that from JDK 8. This proposal
thus
only opens internal packages that existed in JDK 8.
- This proposal will require adjustments to JEP 260, "Encapsulate
Most
Internal APIs" [6]. 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.
- 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.
[1]
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012673.html
[2] http://jdk.java.net/jigsaw/
[3]
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-March/011763.html
[4] This will usually but not always be possible, since there are still
a
few critical internal APIs without exported replacements [6].
[5]
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012708.html
[6] http://openjdk.java.net/jeps/260
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
