Message12066

I did not invent this API, just trying to get a tight support now that we are working on this part.

Indeed Java 9+ will make this more complicated. However that concerns FileIO.__int__ itself, not an accompanied use counter. FileIO.__int__ is already present - I did not invent it, we're just using it. What would you suggest to do with it in Java 9?
Remove it? Does actually something depend on it? In JyNI it is already confirmed that matplotlib needs it, but for JyNI it's enough to expose the FileDescriptor. We can move the black magic to JyNI then, it's already so packed with such magic that this won't be of much notice :)

So far access by JNI to private stuff is not restricted AFAICT. I was not aware it does not work on Windows. I assumed the field would then just contain the Windows file handle. A quick search lead to http://www.docjar.com/docs/api/sun/nio/ch/IOUtil.html IOUtil.fdVal. It's still not nice but gives the hope to work on Windows. https://www.linkedin.com/pulse/getting-unix-file-descriptor-java-greg-banks also mentions sun.misc.sharedSecrets, which is still present in Java 9 in jdc.internal.misc. This will require --add-exports java.base/jdk.internal.misc=your.module according to https://stackoverflow.com/questions/46612648/javalangaccess-and-sharedsecrets-in-java-9.

This might be a viable way to make FileIO.__int__ a bit more Java 9 proof. I hope --add-exports is a bit more sustainable than --illegal-access.

> Would it really affect C extensions if these were no-ops?

That's no dead functionality in CPython, so in theory yes. In fact I don't know. We can implement the functions to do nothing except raising warnings. Then revisit if a C extension shows up that really triggers these warnings. On the other hand I thought adding the use counter is not a big deal and then we would be save. The concept would also be more complete in Jython. Indeed in Jython the main issue is to support FileIO.__int__, not an accompanied use counter. The counter is a trivial enhancement compared to that.

Python 3 is a different story, that will require extensive change anyway.