JDK16 SelectableJavaSocket illegal reflective access about one-nio HOT 2 CLOSED

It's true that one-nio uses JDK private APIs (not only in getPollMethodHandle), but that's on purpose.
Well, if standard Java provided high performance networking, efficient serialization, and convenient off-heap memory management, I would of course prefer those. Moreover, the entire one-nio library would be unnecessary :)

It's a shame to use reflection hacks etc. Unfortunately, the "standard" way is often less efficient, or uglier, or both. It's 2021 outside, JDK version has increased from 6 to 16 since the appearance of one-nio, but there is still no official Java API for managing ByteBuffers more than 2GB and releasing them on demand, no straightforward way to create a fast custom serialization mechanism, and blocking SocketChannels still do not support timeouts and other OS-specific options 🤦

Back to SelectableJavaSocket...
Normally, JavaSocket should never appear in a production environment. It was designed as a simple fallback for a development environment, where NativeSocket is not supported. It was never meant to be a fully-featured implementation, it's only purpose is to allow development on macOS or Windows workstation.

Considering that JavaSocket is not for production use, and having a straghtforward workaround by way of --add-exports/--add-opens, I think it's not worth investing in a fix.

BTW, antimodule agent automatically exports and opens everything, so that applications using private APIs work on JDK 16 even without a warning.

from one-nio.

I think it is awesome how one-nio is designed and implemented. You are preaching to the choir.

I am just rolling my eyes with some of the changes like making deny the default. Cost/benefit, in my view this creates more problems than it solves.

Thank you for the explanations and mentioning/creating anitmodule. Makes perfect sense to keep things the way they are and "workaround" with JVM settings.

from one-nio.