Message11953

From Java 9 on, we can no longer ignore Java accessibility rules wholesale in response to the system property python.security.respectJavaAccessibility=false. The result now is ugly warning messages (or ugly extra options on the command line), with the threat that overriding accessibility will become impossible later.

We are gradually working off a list of cases where we do this selectively for our own convenience (#2656), but this issue is about the option we offer users to do it globally. The problem is that when asked, we make this override *everywhere*.

We do not generally run the regression tests with this option. In a small number of tests we specify it to a sub-process (test_codecs_jy and test_java_visibility). These produce the warnings about java.lang.Object.finalize() seen in #2656. However, the effect is easily reproduced simply by launching Jython as:

PS jython-jvm9> dist\bin\jython "-J-Dpython.security.respectJavaAccessibility=false"
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.python.core.PyJavaType (file:...jython-dev.jar) to method java.lang.Object.finalize()
WARNING: Please consider reporting this to the maintainers of org.python.core.PyJavaType
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
Jython 2.7.2a1+ (default:6bdc6cb2401f+, May 7 2018, 12:09:34)
...

Java is only recording the first offence in this mode. The command:
   dist\bin\jython -J--illegal-access=warn  "-J-Dpython.security.respectJavaAccessibility=false" 
will document the full charge sheet.

In the course of working on #2656 (see spin-off #2662 and #msg11943) I observed that the way we deal with private classes was a late addition to PyJavaType.init that (to me) didn't quite fit smoothly. I suggested we should not have exceptional processing for private classes up front, but that the main-line of init should take accessibility into account in its fine-grain logic. 

I propose that we re-work that logic of PyJavaType to treat private classes and members as inaccessible, irrespective of the user request (or Options.respectJavaVisibility as it appears here) wherever the modular platform specifies it.

respectJavaAccessibility=false has a use only where the module system allows Jython reflective access (without complaining). This would include modules opened by the user with --add-opens (JVM option). Jython would no longer open up the whole of the JVM internals in response to respectJavaAccessibility=false, only classes and members in the unnamed package and packages brought into scope explicitly.

Although respectJavaAccessibility=false is unusable on Java 9 at present (without warnings) I have not counted this a blocker for 2.7.2 (but I'm open to arguments).