@jeff5 , please review this PR.

@Stewori , please review this PR.

Yes, I took a look. IIRC we discussed the idea somewhere else earlier. I was concerned to simply bypass this safety measure in Java, at least as long as it's just a warning. Given that they announce to block it more strictly it is probably indeed the most future-proof decision to adjust this as you suggest. To keep for Jython the "business as usual". I am certain, Jeff will find time to look at this before release. It won't be forgotten, I just won't merge it right now without a second opinion.

I tagged this to cover the "not forgetting" part of Stefan's promise.

@Stewori We had a similar conversation about access to private members under python.security.respectJavaAccessibility=false, and there we thought we should fix the cause where we could and leave the noise where we couldn't fix the cause, rather than suppress the warning. The threat was that it would stop working altogether sometime, and we didn't want that to be a surprise.

The logic here is different. Here, we seem to have a (permanent) option to enable the behaviour. I would not do that in the JARs we offer as Java dependencies, since it should be up to the consuming application. For the standalone JAR, that feels ok.

A bit of hunting around shows that the cause is our use of a long superseded JLine version. (I've never had the stomach for the changes necessary to update it.) However, if you don't use JLine, it just happens somewhere else.

PS 274-trial> java "-Dpython.console=org.python.core.PlainConsole" -jar .\kit\jython-standalone.jar
WARNING: A restricted method in java.lang.System has been called
WARNING: java.lang.System::load has been called by com.kenai.jffi.internal.StubLoader in an unnamed module (file:/C:/Users/Jeff/Documents/Jython/274-trial/kit/jython-standalone.jar)
...