On 21.03.2017 15:48, mark.reinh...@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
