Better tools for adjusting to strong encapsulation
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)
> - $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?
More information about the jigsaw-dev