You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Guillaume Boué <gb...@apache.org> on 2017/06/10 21:54:32 UTC
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?)
> - ...
>
> WDYT?
>
> Robert
>
> ------- Forwarded message -------
> From: mark.reinhold@oracle.com
> To: jigsaw-dev@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-compiler-plugin + default-value for illegal-access
Posted by Robert Scholte <rf...@apache.org>.
Interesting, based on the output of "java -X" and "javac -X" you're right.
Kind of a surprise to me, but in that case this is not an issue for the
maven-compiler-plugin
Robert
On Sat, 10 Jun 2017 23:54:32 +0200, Guillaume Boué <gb...@apache.org>
wrote:
> 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?)
>> - ...
>>
>> WDYT?
>>
>> Robert
>>
>> ------- Forwarded message -------
>> From: mark.reinhold@oracle.com
>> To: jigsaw-dev@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---
> L'absence de virus dans ce courrier électronique a été vérifiée par le
> logiciel antivirus Avast.
> https://www.avast.com/antivirus
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org