Re: Proposal (revised): Allow illegal access to internal APIs by default in JDK 9
On 28 Jun 2017, at 17:31, Alan Bateman wrote: > > On 28/06/2017 14:46, Robert Gibson wrote: >> Sure. >> (It actually doesn't make any difference how the app is started, browser or >> javaws, results are the same in either case.) >> >> > Can you confirm that this is Windows only? Andy tells me that javaws.exe is > the equivalent of javaw.exe rather than java.exe, which is why I'm asking. > > -Alan Sorry, the only Linux environments I have access to are headless and Web Start doesn’t start (no X11 libraries). Robert
Re: Proposal (revised): Allow illegal access to internal APIs by default in JDK 9
On 28/06/2017 14:46, Robert Gibson wrote: Sure. (It actually doesn't make any difference how the app is started, browser or javaws, results are the same in either case.) Can you confirm that this is Windows only? Andy tells me that javaws.exe is the equivalent of javaw.exe rather than java.exe, which is why I'm asking. -Alan
Re: Proposal (revised): Allow illegal access to internal APIs by default in JDK 9
> On 28 Jun 2017, at 10:57, Alan Bateman wrote: > If the illegal access is succeeding then it means Java Web Start has picked > up the option that you added via Control Panel. I can't tell if you are > opened the JNLP in the browser or using the `javaws` CLI but I assume this > issue is about where stderr has been directed. > > -Alan Sure. (It actually doesn't make any difference how the app is started, browser or javaws, results are the same in either case.) Filed as JDK-8183110. Thanks, Robert
Re: Proposal (revised): Allow illegal access to internal APIs by default in JDK 9
On 28/06/2017 08:54, Robert Gibson wrote: : Thanks for the follow-up: the debug option doesn't seem to work, bug report filed as 9049772 - hope it doesn't get targeted to 10 ;) If the illegal access is succeeding then it means Java Web Start has picked up the option that you added via Control Panel. I can't tell if you are opened the JNLP in the browser or using the `javaws` CLI but I assume this issue is about where stderr has been directed. -Alan
Re: Proposal (revised): Allow illegal access to internal APIs by default in JDK 9
> On 27 Jun 2017, at 10:18, Alan Bateman wrote: > > > >> On 27/06/2017 08:46, Robert Gibson wrote: >> : >> Hi Alan, >> Thanks for your quick response. No debug option? >> > Not in the JNLP but you should be able to use the Java Control Panel to add > `--illegal-access=debug`. > > -Alan. Thanks for the follow-up: the debug option doesn't seem to work, bug report filed as 9049772 - hope it doesn't get targeted to 10 ;) Regards, Robert
Re: Proposal (revised): Allow illegal access to internal APIs by default in JDK 9
On 27/06/2017 08:46, Robert Gibson wrote: : Hi Alan, Thanks for your quick response. No debug option? Not in the JNLP but you should be able to use the Java Control Panel to add `--illegal-access=debug`. -Alan.
Re: Proposal (revised): Allow illegal access to internal APIs by default in JDK 9
On 27 Jun 2017, at 09:34, Alan Bateman wrote: > >> On 27/06/2017 08:24, Robert Gibson wrote: >> Hi Mark, >> What is the intended interaction between this proposal and Java Web Start? >> I'm testing with JDK EA build 175 and it looks like a VM launched through >> Web Start is running with --illegal-access=deny, with no possibility of >> changing it - is this by design? (I have filed a few bugs in this area in >> case it is by accident, but they are not showing up in Jira, or they are >> targeted for JDK 10 which is obviously too late, if we are talking about >> unintentional behaviour.) >> > Applets and JNLP applications are intentionally launched with > `--illegal-access=deny`. If JNLP applications need to break into JDK classes > then the finer grained `--add-exports` and `--add-opens` options can be > specified in the JNLP. The Java Control Panel can also be used to specify > `--illegal-access=permit` if needed too. > > -Alan Hi Alan, Thanks for your quick response. No debug option? Robert
Re: Proposal (revised): Allow illegal access to internal APIs by default in JDK 9
On 27/06/2017 08:24, Robert Gibson wrote: Hi Mark, What is the intended interaction between this proposal and Java Web Start? I'm testing with JDK EA build 175 and it looks like a VM launched through Web Start is running with --illegal-access=deny, with no possibility of changing it - is this by design? (I have filed a few bugs in this area in case it is by accident, but they are not showing up in Jira, or they are targeted for JDK 10 which is obviously too late, if we are talking about unintentional behaviour.) Applets and JNLP applications are intentionally launched with `--illegal-access=deny`. If JNLP applications need to break into JDK classes then the finer grained `--add-exports` and `--add-opens` options can be specified in the JNLP. The Java Control Panel can also be used to specify `--illegal-access=permit` if needed too. -Alan
Re: Proposal (revised): Allow illegal access to internal APIs by default in JDK 9
Hi Mark, What is the intended interaction between this proposal and Java Web Start? I'm testing with JDK EA build 175 and it looks like a VM launched through Web Start is running with --illegal-access=deny, with no possibility of changing it - is this by design? (I have filed a few bugs in this area in case it is by accident, but they are not showing up in Jira, or they are targeted for JDK 10 which is obviously too late, if we are talking about unintentional behaviour.) Thanks, Robert
Re: Proposal (revised): Allow illegal access to internal APIs by default in JDK 9
Hi, I think the fine-tuning is right to the point now. Allows most of what was allowed in JDK8, but no more than that. Regards, Peter On 06/05/2017 08:45 PM, mark.reinh...@oracle.com wrote: (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
Re: Proposal (revised): Allow illegal access to internal APIs by default in JDK 9
On 06/06/2017 04:34, Stephen Felts wrote: The new format is missing information that was useful in the earlier -Dsun.reflect.debugModuleAccessChecks=true. It printed something like 'java.base does not "opens java.text" to unnamed module ...' so it was really obvious what option was needed. `-Dsun.reflect.debugModuleAccessChecks=true` can still be used to hunt code that swallows IllegalAccessException or InaccessibleObjectException, particularly useful when running with `--illegal-access=deny`. -Alan
RE: Proposal (revised): Allow illegal access to internal APIs by default in JDK 9
The new format is missing information that was useful in the earlier -Dsun.reflect.debugModuleAccessChecks=true. It printed something like 'java.base does not "opens java.text" to unnamed module ...' so it was really obvious what option was needed. -Original Message- From: jigsaw-dev [mailto:jigsaw-dev-boun...@openjdk.java.net] On Behalf Of mark.reinh...@oracle.com Sent: Monday, June 5, 2017 2:45 PM To: jigsaw-dev@openjdk.java.net Subject: Proposal (revised): Allow illegal access to internal APIs by default in JDK 9 (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 illega
Re: Proposal (revised): Allow illegal access to internal APIs by default in JDK 9
Hi, I'm a new poster to this list. I'm actively working on getting Gradle to work on JDK 9, and I also think this proposal strikes a very good balance between pragmatism (don't just break people today) and getting developers motivated to clean up their code for the future. Thank you, Pepper Lebeck-Jobe On Tue, Jun 6, 2017 at 8:53 AM David Blevins wrote: > I think this is the most pragmatic and reasoned middle ground one could > possibly imagine. > > I agree with the finely-tuned choices, specifically: > > - Not going completely silent. Some asked for the ability to completely > shut off the warnings. This goes a little too far to one extreme. There > has to be some cost or discomfort or there won’t be the right movement. > IMHO, it would have been too far back the other way to go silent. People > will see these messages, they will post them to StackOverflow and get an > education on how to go forward. We need that. > > - Not choosing `--illegal-access=deny` by default for this version. > Some cited this as a setback. There is an argument to be made that it > would have been the bigger setback to go too strict too soon. The danger > would be when developers who don’t know this conversation and the details > behind it learn “use this flag to make problems go away”. At which point > it becomes cargo cult and they’ll be afraid to stop using it because they > never understood it completely in the first place. Worse, we’re now buried > under 3 years of lazy StackOverflow answers effectively telling people how > to go backwards. > > So although it feels less strict, one set of choices creates a > conversation on how to move forward and one creates a conversation on how > to go backward. > > Of course time will tell, but I believe this proposal gets us what we want > the soonest. > > > -David > > > > On Jun 5, 2017, at 11:45 AM, mark.reinh...@oracle.com wrote: > > > > (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
Re: Proposal (revised): Allow illegal access to internal APIs by default in JDK 9
I think this is the most pragmatic and reasoned middle ground one could possibly imagine. I agree with the finely-tuned choices, specifically: - Not going completely silent. Some asked for the ability to completely shut off the warnings. This goes a little too far to one extreme. There has to be some cost or discomfort or there won’t be the right movement. IMHO, it would have been too far back the other way to go silent. People will see these messages, they will post them to StackOverflow and get an education on how to go forward. We need that. - Not choosing `--illegal-access=deny` by default for this version. Some cited this as a setback. There is an argument to be made that it would have been the bigger setback to go too strict too soon. The danger would be when developers who don’t know this conversation and the details behind it learn “use this flag to make problems go away”. At which point it becomes cargo cult and they’ll be afraid to stop using it because they never understood it completely in the first place. Worse, we’re now buried under 3 years of lazy StackOverflow answers effectively telling people how to go backwards. So although it feels less strict, one set of choices creates a conversation on how to move forward and one creates a conversation on how to go backward. Of course time will tell, but I believe this proposal gets us what we want the soonest. -David > On Jun 5, 2017, at 11:45 AM, mark.reinh...@oracle.com wrote: > > (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`
