Message12147

Stefan: Thanks for the tip concerning gc. That sounds an easy solution. I've dug into the traversal before and although I would like to understand it better, a ready-made answer is welcome.

I'm looking at the PyJavaType case now. I find that it is raised by the meth.setAccessible we do when Options.respectJavaAccessibility is false. IMO there is a case for saying that a disrespectful user should expect a dusty reply from Java 9 (=won't fix). It pops out of test_java_accessibility for that explicit reason. Not sure yet why it does so from test_codecs_jy. 

With regard to jnr.posix, I think they've got it in https://github.com/jnr/jnr-posix/pull/109 and https://github.com/jnr/jnr-posix/issues/110. The first of these is interesting, since the resolution only defers the illegal access until it can't be avoided. If the client asks for the C-level file descriptor that is private to the stream (or for the Windows handle), there is no legal way to provide it.

I've managed to eliminate the offending calls from the Jython startup: as in jnr.posix itself, users don't suffer until they explicitly ask for the forbidden data.