Better tools for adjusting to strong encapsulation

[Keimpe Bronkhorst]

Mark,

How do we (Oracle JDeveloper) turn these illegal reflective-access 
operation warnings off. We don't want or need these warnings when 
running JDeveloper except during specific developer sessions.

BTW, the big kill switch doesn't seem useful, it just hides everything 
that needs work.

Keimpe Bronkhorst


On 3/21/2017 11:57 AM, jigsaw-dev-request at openjdk.java.net wrote:

> Warnings of illegal reflective-access operations
> ------------------------------------------------
>
> When an illegal reflective access operation succeeds due to the use of
> the `--permit-illegal-access` option, or the use of an `--add-opens` or
> `--add-exports` option, then a warning message of the following form is
> written to the error stream:
>
>      WARNING: Illegal access by $PERPETRATOR to $VICTIM (permitted by $OPTION)
>
> where:
>
>    - $PERPETRATOR is the fully-qualified name of the type containing
>      the code that invoked the reflective operation in question plus
>      the code source (i.e., JAR-file path), if available,
>
>    - $VICTIM is a string that describes the member being accessed,
>      including the fully-qualified name of the enclosing type, and
>
>    - $OPTION is the name of the command-line option that enabled this
>      access, when that can be determined, or the first one of those
>      options if more than one option had that effect.
>
> The run-time system attempts to suppress duplicate warnings for the same
> $PERPETRATOR and $VICTIM, but it's not always practical to do so.
>
> For deeper diagnosis you can request a stack trace on each such warning
> by setting the system property `sun.reflect.debugModuleAccessChecks` to
> the value `access`, though this detail might change.  (That property can
> also be helpful to diagnose mysterious failures due to illegal-access
> exceptions that are caught and suppressed.)
>
> In addition to displaying a warning on each illegal access operation, the
> run-time system also shows new initial warning messages at startup time.
> If `--permit-illegal-access` is used then a warning reports the imminent
> demise of that option in the next major release.  If either `--add-opens`
> or `--add-exports` are used then a warning reports a count of each type
> of option used (i.e., opens vs. exports).
>
> Here are some examples of these messages, from running Jython on a very
> recent Jigsaw build:
>
>    $ java --permit-illegal-access -jar jython-standalone-2.7.0.jar
>    WARNING: --permit-illegal-access will be removed in the next major release
>    WARNING: Illegal access by jnr.posix.JavaLibCHelper (file:/tmp/jython-standalone-2.7.0.jar) to method sun.nio.ch.SelChImpl.getFD() (permitted by --permit-illegal-access)
>    WARNING: Illegal access by jnr.posix.JavaLibCHelper (file:/tmp/jython-standalone-2.7.0.jar) to field sun.nio.ch.FileChannelImpl.fd (permitted by --permit-illegal-access)
>    WARNING: Illegal access by jnr.posix.JavaLibCHelper (file:/tmp/jython-standalone-2.7.0.jar) to field java.io.FileDescriptor.fd (permitted by --permit-illegal-access)
>    WARNING: Illegal access by org.python.core.PySystemState (file:/tmp/jython-standalone-2.7.0.jar) to method java.io.Console.encoding() (permitted by --permit-illegal-access)
>    Jython 2.7.0 (default:9987c746f838, Apr 29 2015, 02:25:11)
>    [OpenJDK 64-Bit Server VM (Oracle Corporation)] on java9-internal
>    Type "help", "copyright", "credits" or "license" for more information.
>    >>> ^D
>    $
>
>