Proposal: Allow illegal reflective access by default in JDK 9

classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Proposal: Allow illegal reflective access by default in JDK 9

mark.reinhold
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
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Allow illegal reflective access by default in JDK 9

Andrew Haley
On 18/05/17 15:48, [hidden email] wrote:

> - 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.

Mmm.  There are many scripts which parse the output of java,and many
would break.  Might '--illegal-access=permit,quiet' be worth
considering?

Andrew.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Allow illegal reflective access by default in JDK 9

Cédric Champeau
In reply to this post by mark.reinhold
This looks like a very reasonable proposal, +1

2017-05-18 16:48 GMT+02:00 <[hidden email]>:

> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Allow illegal reflective access by default in JDK 9

Uwe Schindler
In reply to this post by mark.reinhold
Hi Mark,

To me this proposal is a Desaster. I'd not do this. Buggy software may use the big kill switch.

Sorry Red Hat guys: that's what you triggered with your "no". Bravo! I am impressed!

Sorry Gradle, the worst design in software about environment variables made the whole world again as unsafe as before. We will again see ongoing security updates in Java just fix fix holes that are opened by default. When I have read the mails yesterday, I thought: do you really want to build your software with such a broken tool and it's ecosystem? Can you not just tell the plug-in authors to fix their shit and fix your API to work correct?

Amazon S3 software dilettantes: Fix your EC2 security software to not undermine the Java security system! I can bring many more: Don't do that in security relevant tools or build systems many people rely on!

Today is the worst day in Java history.

Uwe

Am 18. Mai 2017 16:48:40 MESZ schrieb [hidden email]:

>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
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Allow illegal reflective access by default in JDK 9

Mario Torre-2
2017-05-18 18:08 GMT+02:00 Uwe Schindler <[hidden email]>:

> Hi Mark,
>
> To me this proposal is a Desaster. I'd not do this. Buggy software may use the big kill switch.
>
> Sorry Red Hat guys: that's what you triggered with your "no". Bravo! I am impressed!
>
> Sorry Gradle, the worst design in software about environment variables made the whole world again as unsafe as before. We will again see ongoing security updates in Java just fix fix holes that are opened by default. When I have read the mails yesterday, I thought: do you really want to build your software with such a broken tool and it's ecosystem? Can you not just tell the plug-in authors to fix their shit and fix your API to work correct?
>
> Amazon S3 software dilettantes: Fix your EC2 security software to not undermine the Java security system! I can bring many more: Don't do that in security relevant tools or build systems many people rely on!
>
> Today is the worst day in Java history.

Hello Uwe,

I appreciate your enthusiasm, but please let's try to keep this
discussion focused.

Cheers,
Mario

--
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Allow illegal reflective access by default in JDK 9

Michael Nascimento
In reply to this post by mark.reinhold
Sounds like a well thought compromise, Mark. Real world applications need
this and it's a very welcome move.

Regards,
Michael

On Thu, May 18, 2017 at 11:48 AM, <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Allow illegal reflective access by default in JDK 9

Markus Keller
In reply to this post by mark.reinhold
The command-line argument and the default mode sound good.

`--illegal-access=quiet` could be added for use by clients that cannot
cope with additional warning messages.

The second ingredient for broad compatibility with Java 8 would be an
automatic --add-modules=ALL-SYSTEM.
This could be implemented as an automatic compatibility mode in Java 9
that would only be active as long as there's no --modulepath on the
command line.

An alternative to automatic compatibility would be another sub-option for
--illegal-access, so that affected end users only have one command-line
argument for all accessibility concerns, e.g.:

  `--illegal-access=permit-all`

    Equivalent to `--illegal-access=permit --add-modules=ALL-SYSTEM`


FYI: In the Eclipse launcher for the Oxygen (4.7) release, we've added
forward-compatibility handling for --permit-illegal-access. Our deadline
to revert/adjust that is May 30 ( https://bugs.eclipse.org/516911 ).

Regards,
Markus


"jigsaw-dev" <[hidden email]> wrote on 2017-05-18
16:48:40:

> From: [hidden email]
> To: [hidden email]
> Date: 2017-05-18 16:49
> Subject: Proposal: Allow illegal reflective access by default in JDK 9
> Sent by: "jigsaw-dev" <[hidden email]>
>
> 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
>


Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Allow illegal reflective access by default in JDK 9

Nicolai Parlog
In reply to this post by mark.reinhold
 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, [hidden email] 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
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Allow illegal reflective access by default in JDK 9

Christoph Engelbert
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 <[hidden email]> 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, [hidden email] 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

Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Allow illegal reflective access by default in JDK 9

Weijun Wang
In reply to this post by mark.reinhold
I don't like this default value, but I also know some people wanting it.

Is it possible to provide the default value in a file inside the conf
directory and also make it overwrite-able on the command line? Maybe
RedHat Linux can make it "permit" out-of-box and other vendors can
choose different values.

Thanks
Max

On 05/18/2017 10:48 PM, [hidden email] 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
>
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Allow illegal reflective access by default in JDK 9

Tagir Valeev
In reply to this post by Christoph Engelbert
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 <[hidden email]>
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 <[hidden email]> 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, [hidden email] 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
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Allow illegal reflective access by default in JDK 9

Christoph Engelbert
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 <[hidden email]> 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 <[hidden email] <mailto:[hidden email]>> 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 <[hidden email] <mailto:[hidden email]>> 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, [hidden email] <mailto:[hidden email]> 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>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Allow illegal reflective access by default in JDK 9

Volker Simonis
In reply to this post by mark.reinhold
Hi Mark,

thanks for this proposal. I think it is pragmatic and well balanced.

While I personally agree with the advocates of a clean solution I also
understand the the needs of big (and slow) companies (including the
one I'm working for:) After all, the new default isn't that bad in my
opinion because it only affects applications/libraries on the class
path which is legacy anyway. If you convert your application/libraries
to modules it will still benefit from the full JPMS features and
restrictions. So altogether I think it is a good compromise.

I have some practical comments/suggestions though:

From my understanding, at run-time, "open" implicates "exports" (i.e.
if a module M1 opens a package P for some other module M2 it also,
implicitly exports P to M2). The  "big kill switch" in both, its old
and in the newly proposed form, usually only refers to "enabling
reflective access" but doesn't explicitly mentions that it will also,
implicitly export the respective packages. Also, the usage of the
"kill switch" only produces warnings for reflective accesses which are
enabled by the option itself (and not at the same time, explicitly
allowed by --add-opens directives). But it doesn't warn about the
simple, non-reflective accesses to packages which are implicitly
exported by the kill switch as well.

I think that the "big kill switch" should also print warnings for
these simple, non-reflective accesses to packages which are implicitly
exported by the kill switch. Otherwise, this could lead to a situation
where users claim to be "JPMS-safe" because they did run with
"--illegal-access=warn" and didn't saw any warnings but then, after
the default will change to "--illegal-access=deny", their applications
will break because of simple accesses to non-exported packages.

I'm aware of the initial discussion about "--permit-illegal-access"
and that you decided not to issue warnings for the precise
`--add-opens` and `--add-exports` options [1]. But now, with the new
version of the "--illegal-access" option and the possibility to
enable/disable warnings, I think printing warnings for simple (i.e.
non-reflective) illegal accesses which are implicitly allowed
"--illegal-access" by would be useful.

Regards,
Volker

[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-March/011810.html


On Thu, May 18, 2017 at 4:48 PM,  <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Allow illegal reflective access by default in JDK 9

Peter Levart
In reply to this post by Nicolai Parlog
On 05/19/2017 01:17 AM, Nicolai Parlog wrote:
> 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!

+1

I think that --illegal-access=permit-silently or equivalent is a
reasonable request (in addition to other modes), but please make the
--illegal-access=deny the default!

There was a lot of work put into moving various internal classes into
jdk.internal.* packages (except for some widely used ones), so enabling
illegal access from classpath by default allows careless developers to
start using those new internal APIs (such as jdk.internal.misc.Unsafe)
because they can!!! And we are back to square one when JDK 9 -> JDK 10
transition is to be made. Not only will we be forced to search for
public alternatives to existing private (JDK 8-) APIs, but in addition
to all jdk.internal.* APIs that were newly introduced in JDK 9 too...

Regards, Peter

Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Allow illegal reflective access by default in JDK 9

Peter Levart
In reply to this post by Volker Simonis
Hi Volker,

On 05/19/2017 11:48 AM, Volker Simonis wrote:

>  From my understanding, at run-time, "open" implicates "exports" (i.e.
> if a module M1 opens a package P for some other module M2 it also,
> implicitly exports P to M2). The  "big kill switch" in both, its old
> and in the newly proposed form, usually only refers to "enabling
> reflective access" but doesn't explicitly mentions that it will also,
> implicitly export the respective packages. Also, the usage of the
> "kill switch" only produces warnings for reflective accesses which are
> enabled by the option itself (and not at the same time, explicitly
> allowed by --add-opens directives). But it doesn't warn about the
> simple, non-reflective accesses to packages which are implicitly
> exported by the kill switch as well.

No, you got it wrong. "opens" is just a backdoor for reflection (and
MethodHandles.Lookup). It does not implicitly also mean "exports".
Neither in compile-time nor in run-time. Otherwise everything that is
declared "public" would be accessible to reflection without the need for
.setAccessible(true) - therefore even to code running with
SecurityManager enabled!

Regards, Peter

Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Allow illegal reflective access by default in JDK 9

Nicolai Parlog
 Hi!

I'm too lazy to try right now but I'm pretty sure I repeatedly observed
the behavior Volker describes:

A module depends on an internal type and is compiled successfully
thanks to --add-exports. At run time it would fail without flags and
would work with --add-exports but it also works with --add-opens.

 so long ... Nicolai



On 19.05.2017 12:24, Peter Levart wrote:

> Hi Volker,
>
> On 05/19/2017 11:48 AM, Volker Simonis wrote:
>> From my understanding, at run-time, "open" implicates "exports"
>> (i.e. if a module M1 opens a package P for some other module M2
>> it also, implicitly exports P to M2). The  "big kill switch" in
>> both, its old and in the newly proposed form, usually only refers
>> to "enabling reflective access" but doesn't explicitly mentions
>> that it will also, implicitly export the respective packages.
>> Also, the usage of the "kill switch" only produces warnings for
>> reflective accesses which are enabled by the option itself (and
>> not at the same time, explicitly allowed by --add-opens
>> directives). But it doesn't warn about the simple, non-reflective
>> accesses to packages which are implicitly exported by the kill
>> switch as well.
>
> No, you got it wrong. "opens" is just a backdoor for reflection
> (and MethodHandles.Lookup). It does not implicitly also mean
> "exports". Neither in compile-time nor in run-time. Otherwise
> everything that is declared "public" would be accessible to
> reflection without the need for .setAccessible(true) - therefore
> even to code running with SecurityManager enabled!
>
> Regards, Peter
>

--

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
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Allow illegal reflective access by default in JDK 9

Peter Levart
Hi Nikolai,

On 05/19/2017 12:41 PM, Nicolai Parlog wrote:
>   Hi!
>
> I'm too lazy to try right now

It's easy. Take this example:

public class Test {
     public static void main(String[] args) throws Exception {
         Object theUnsafe = Class.forName("jdk.internal.misc.Unsafe")
                                 .getMethod("getUnsafe")
                                 .invoke(null);
     }
}

Running this on classpath without any additional JVM options produces:

Exception in thread "main" java.lang.IllegalAccessException: class Test
cannot access class jdk.internal.misc.Unsafe (in module java.base)
because module java.base does not export jdk.internal.misc to unnamed
module @63d4e2ba
     at
java.base/jdk.internal.reflect.Reflection.throwIllegalAccessException(Reflection.java:445)
     at
java.base/jdk.internal.reflect.Reflection.throwIllegalAccessException(Reflection.java:436)
     at
java.base/jdk.internal.reflect.Reflection.ensureMemberAccess(Reflection.java:112)
     at
java.base/java.lang.reflect.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:407)
     at
java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:399)
     at java.base/java.lang.reflect.Method.invoke(Method.java:535)
     at Test.main(Test.java:9)

(note that the exception is thrown from Method.invoke)

When run with:

      --add-exports java.base/jdk.internal.misc=ALL-UNNAMED

...the example works (does not throw exception), but when run with:

     --add-opens java.base/jdk.internal.misc=ALL-UNNAMED

...the example still works!!!! OOOPS - this is a bug!!! This is
definitely a bug.


If --illegal-access=permit is an alias for opening all modules to
ALL-UNNAMED, then we definitely have a problem as above example can be
successfully executed even with SecurityManager enabled!!!


Regards, Peter

>   but I'm pretty sure I repeatedly observed
> the behavior Volker describes:
>
> A module depends on an internal type and is compiled successfully
> thanks to --add-exports. At run time it would fail without flags and
> would work with --add-exports but it also works with --add-opens.
>
>   so long ... Nicolai
>
>
>
> On 19.05.2017 12:24, Peter Levart wrote:
>> Hi Volker,
>>
>> On 05/19/2017 11:48 AM, Volker Simonis wrote:
>>>  From my understanding, at run-time, "open" implicates "exports"
>>> (i.e. if a module M1 opens a package P for some other module M2
>>> it also, implicitly exports P to M2). The  "big kill switch" in
>>> both, its old and in the newly proposed form, usually only refers
>>> to "enabling reflective access" but doesn't explicitly mentions
>>> that it will also, implicitly export the respective packages.
>>> Also, the usage of the "kill switch" only produces warnings for
>>> reflective accesses which are enabled by the option itself (and
>>> not at the same time, explicitly allowed by --add-opens
>>> directives). But it doesn't warn about the simple, non-reflective
>>> accesses to packages which are implicitly exported by the kill
>>> switch as well.
>> No, you got it wrong. "opens" is just a backdoor for reflection
>> (and MethodHandles.Lookup). It does not implicitly also mean
>> "exports". Neither in compile-time nor in run-time. Otherwise
>> everything that is declared "public" would be accessible to
>> reflection without the need for .setAccessible(true) - therefore
>> even to code running with SecurityManager enabled!
>>
>> Regards, Peter
>>

Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Allow illegal reflective access by default in JDK 9

Alan Bateman
In reply to this post by Volker Simonis
On 19/05/2017 10:48, Volker Simonis wrote:

> :
>
>  From my understanding, at run-time, "open" implicates "exports" (i.e.
> if a module M1 opens a package P for some other module M2 it also,
> implicitly exports P to M2). The  "big kill switch" in both, its old
> and in the newly proposed form, usually only refers to "enabling
> reflective access" but doesn't explicitly mentions that it will also,
> implicitly export the respective packages. Also, the usage of the
> "kill switch" only produces warnings for reflective accesses which are
> enabled by the option itself (and not at the same time, explicitly
> allowed by --add-opens directives). But it doesn't warn about the
> simple, non-reflective accesses to packages which are implicitly
> exported by the kill switch as well.
You are correct. If the package is opened at run-time:

1. All public members of public types in the package are accessible.
This includes both static and reflective access.

2. All members of all types in the package can be reflected on when
using setAccessible or privateLookupIn.

The reason you don't get warnings with the static references is because
access checking in the VM is very low level and we deliberately decided
to avoid the invasive changes needs to report warnings here. The latest
proposal does not change this, it's just too late in JDK 9 to take on
this surgery.

-Alan
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Allow illegal reflective access by default in JDK 9

Alan Bateman
In reply to this post by Peter Levart
On 19/05/2017 11:58, Peter Levart wrote:

> :
>
> ...the example works (does not throw exception), but when run with:
>
>     --add-opens java.base/jdk.internal.misc=ALL-UNNAMED
>
> ...the example still works!!!! OOOPS - this is a bug!!! This is
> definitely a bug.
No, the behavior is correct as jdk.internal.misc.Unsafe is public and
it's getUnsafe is public. It's different to sun.misc.Unsafe.

However, you do have a point that opening all packages by default means
that the internal Unsafe might need to be looked at again. The long term
plan is to reduce the need for sun.misc.Unsafe but not by having
libraries move to the internal Unsafe.

BTW: For the security manager case then I assume you code fragment would
need to accessClassInPackage.jdk.internal.misc permission.

-Alan
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Allow illegal reflective access by default in JDK 9

Alan Bateman
In reply to this post by Nicolai Parlog
On 19/05/2017 11:41, Nicolai Parlog wrote:

> :
>
> A module depends on an internal type and is compiled successfully
> thanks to --add-exports. At run time it would fail without flags and
> would work with --add-exports but it also works with --add-opens.
>
That is correct, assuming you mean a reference to a public member of a
public type, and the module declares `requires $MODULE` to establish the
readability (this part is ignored when discussing code on the class path
because unnamed modules read all modules).

-Alan
123