There was a bug report which is closed, but that was, obviously, before the changed proposal. I think it would be subject to reconsider: https://bugs.openjdk.java.net/browse/JDK-8177916 <https://bugs.openjdk.java.net/browse/JDK-8177916>
Chris > On 19. May 2017, at 07:18, Tagir Valeev <amae...@gmail.com> wrote: > > Regarding proposed "quiet" option: there's existing non-standard > -XX:-PrintWarnings JVM option. I wonder whether it will work to suppress the > illegal access warning as well. If yes, then no additional "quite" mode is > necessary. > > With best regards, > Tagir Valeev. > > On Fri, May 19, 2017 at 11:42 AM, Christoph Engelbert <ch...@hazelcast.com > <mailto:ch...@hazelcast.com>> wrote: > Hey, > > I also think the new styled parameter is great and I would appreciate a fully > “quiet” mode for our customers. I don’t mandate it to be the default but I > think > to make it the default for (and only for) Java 9 sounds meaningful. > > The reason is simple: It is not just us (a few people, a few vendors) to set > this parameter but it will be tons of customers or users, running the actual > production workloads, to add it to their command line. I guess most of us > know the burden of making a change to the command line at some bigger > companies, such as banks. > > On the other side, as a dev I want it to print as much warnings as possible, > when I’m working on fixing the actual “misbehaving” code fragment. > > In general I’m ok with making users add it to their command line but would > like to see something like quiet as the default for Java 9. > > PS: the `—illegal-access=permit` as default works for me though :) > > Thanks for the revised proposal, good stuff! > > Cheers, > Chris > > > > On 19. May 2017, at 01:17, Nicolai Parlog <n...@codefx.org > > <mailto:n...@codefx.org>> wrote: > > > > Hi! > > > > I like the flag per se and think a "quiet" argument would be helpful. I > > also understand that there is pressure to improve the spec and that many > > observers will see this change as progress[1]. > > > > But I think making the lenient option the default is a bad decision, > > needlessly prolonging a proper clean-up of the ecosystem without any > > practical benefit! > > > > Java's stewards have been warning against using internal APIs for 20 > > years. Jigsaw announced to make them inaccessible for nigh two years > > now. Java 8 will be supported until at least July 2018 and even after > > that all that is needed to get around this specific Java 9 compatibility > > problem is to add `--permit-illegal-access`. > > > > All that is not enough, though? Even adding that single flag is too > > hard? If spending an hour or two reading up on JPMS and then adding that > > flag is too much to ask, then how can one expect the same people to > > clean up their code? > > > > With illegal access being permitted by default much fewer developers > > will be aware of the problem and much less pressure will be put on > > library and framework maintainers as well as on project management to > > invest into paying back this particular form of technical debt. So we > > get much less momentum to make the necessary changes in exchange for... > > not having to add a flag? That's ridiculous, an Armutszeugnis[2] for the > > Java community! > > > > so long ... Nicolai > > > > > > [1](where in fact it only creates the appearance thereof) > > [2] > > https://krautblog-ulrich.blogspot.de/2012/07/word-of-month-armutszeugnis.html > > > > <https://krautblog-ulrich.blogspot.de/2012/07/word-of-month-armutszeugnis.html> > > > > > > > > On 18.05.2017 16:48, mark.reinh...@oracle.com > > <mailto:mark.reinh...@oracle.com> wrote: > >> 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 > >> <http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-March/011763.html> > >> [2] http://openjdk.java.net/jeps/260 <http://openjdk.java.net/jeps/260> > >> > > > > -- > > > > PGP Key: > > http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509 > > <http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509> > > > > Web: > > http://codefx.org <http://codefx.org/> > > a blog about software development > > https://www.sitepoint.com/java <https://www.sitepoint.com/java> > > high-quality Java/JVM content > > http://do-foss.de <http://do-foss.de/> > > Free and Open Source Software for the City of Dortmund > > > > Twitter: > > https://twitter.com/nipafx <https://twitter.com/nipafx> > >
