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> 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> 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 > > > > > > > > On 18.05.2017 16:48, 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 > >> [2] http://openjdk.java.net/jeps/260 > >> > > > > -- > > > > PGP Key: > > http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509 > > > > Web: > > http://codefx.org > > a blog about software development > > https://www.sitepoint.com/java > > high-quality Java/JVM content > > http://do-foss.de > > Free and Open Source Software for the City of Dortmund > > > > Twitter: > > https://twitter.com/nipafx > >
