Proposal: Allow illegal reflective access by default in JDK 9

Fri May 19 05:41:07 UTC 2017

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 <amaembo at 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 <chris at hazelcast.com <mailto:chris at 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 <nipa at codefx.org <mailto:nipa at 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.reinhold at oracle.com <mailto:mark.reinhold at 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>
> 
> 