@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)
...

I think we should also add this switch to the regression tests; definitely where it causes a failure (as it might be in subprocess tests); possibly also in the runner so the noise does not obscure hard failures.

I wasn't sure we ought to do this to all our JARs, but AIUI the effect is only when the JAR itself is executed with java -jar .... The slim JAR should probably not have it, because it is intended only ever to be a dependency, but it's my fault you can run it (it names a main class) so let's leave it for now.

If our JAR is on the classpath, as a dependency, you have to give the equivalent option to the java command (e.g. via the launcher). There are places in the tests where this has to happen and #424 offers to make it automatic in the launcher. So I'll merge this partial solution, then #424.