Better tools for adjusting to strong encapsulation

Jochen Theodorou blackdrag at gmx.org
Tue Mar 21 20:36:24 UTC 2017


On 21.03.2017 15:48, mark.reinhold at oracle.com wrote:
[...]
> 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.

that means we will get a lot of users asking us, why our runtime does 
this, even though it is the "fault" of the code using the runtime and 
not really ours. Because "type that invoked the reflective operation" is 
very likely again something caller sensitive, right? Well, that will 
point to our runtime, not to the real perpetrator. I think there is an 
annotation that could be used to exclude our methods from getting the 
caller information, but if memory serves me right this is no public api.

What will be the performance penalty of this?

bye Jochen


More information about the jigsaw-dev mailing list