Re: maven-compiler-plugin + default-value for illegal-access

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
Report Content as Inappropriate

Re: maven-compiler-plugin + default-value for illegal-access

Wouldn't illegal-access be a run-time 'java' flag only, and not a
compile-time 'javac' one?

Le 10/06/2017 à 19:46, Robert Scholte a écrit :

> 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?)
> - ...
> Robert
> ------- Forwarded message -------
> From: [hidden email]
> To: [hidden email]
> 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
>      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
>      WARNING: Illegal reflective access by jnr.posix.JavaLibCHelper
> (file:/tmp/jython-standalone-2.7.0.jar) to field
>      WARNING: Illegal reflective access by jnr.posix.JavaLibCHelper
> (file:/tmp/jython-standalone-2.7.0.jar) to field
>      WARNING: Illegal reflective access by org.python.core.PySystemState
> (file:/tmp/jython-standalone-2.7.0.jar) to method
>      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]
> [2]
> [3]
> [4] This will usually but not always be possible, since there are still a
>      few critical internal APIs without exported replacements [6].
> [5]
> [6]
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.

To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]