I would highly suggest implementing your own for a much better understanding.
I did implement something like what you want and in so doing realized I like their decision. ie. See the heirarchy here https://github.com/deanhiller/webpieces/tree/master/core/core-channelmanager2/src/main/java/org/webpieces/nio/api/channels The TCPChannel could be SSL or not SSL as there are two implementations. If you do want an implementation that does what you want though, this library does exactly that https://github.com/deanhiller/webpieces/tree/master/core/core-channelmanager2 which is used in the webpieces webserver https://github.com/deanhiller/webpieces That nio library is standalone even though it is in the webpieces repo. I mean, every component in webpieces is another stand-alone piece. The downside is the library owns a thread which typical java libraries avoid. ie. it has to have a thread to poll the selector and read from all the sockets to be fed to the thread pools, etc. I think that is the main reason they decided not to have this type of library. They prefer not to be running threads(which I agree, the jdk shouldn't). later, Dean On Tue, Feb 12, 2019 at 7:54 PM Sean Mullan <sean.mul...@oracle.com> wrote: > Hi Andi, > > TLS/JSSE topics are best discussed on the security-dev alias, so I am > copying that list for more discussion and -bcc-ing core-libs-dev. > > --Sean > > On 2/11/19 3:29 PM, Andi Mullaraj wrote: > > Hi java-core community, > > > > I have been directed to this channel to discuss matters related to Java > > performant ssl communications. Maybe this is a topic that has been > > discussed in the past, in which case I would appreciate if someone > pointed > > me to that particular topic. > > > > Back in 2002 I personally applauded the java.nio.channels (jdk1.4) > package, > > realizing that there was no way to port this to the secure > communications, > > due to lack of a comparable implementation for SSL. But I thought it was > > going to just be matter of time. A couple of years ago I had to go back > > search for it, and was kind of surprised to find the following in > > > http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#SSLENG > > : > > > > --- begin quote --- > > Newcomers to the API may wonder "Why not just have an SSLSocketChannel > > which extends java.nio.channels.SocketChannel?" There are two main > reasons: > > > > 1. There were a lot of very difficult questions about what a > > SSLSocketChannel should be, including its class hierarchy and how it > should > > interoperate with Selectors and other types of SocketChannels. Each > > proposal brought up more questions than answers. It was noted that any > new > > API abstraction extended to work with SSL/TLS would require the same > > significant analysis and could result in large and complex APIs. > > 2. Any JSSE implementation of a new API would be free to choose the > "best" > > I/O & compute strategy, but hiding any of these details is inappropriate > > for those applications needing full control. Any specific implementation > > would be inappropriate for some application segment. > > --- end quote --- > > > > It has been a while since this was stated, and I would really like to > > revisit it. I personally believe that the question #1 has a quite > natural > > answer, while #2 should not really be a concern if we adhere to the spi > > model where users can bring their own implementation if needed. I know > > because I have also implemented it (but would like to discuss that in a > > later stage, if it comes to it). > > > > The benefit of such implementation would be immense. Imagine many Java > > services written with nio and which struggle to move to SSL due to the > > great complexity of using SSLEngine (zookeeper service to name one), > while > > all they would need to do (if SSLSocketChannels were available) is to > > instantiate an instance of SSLSocketChannel/SSLSelector when the security > > is required and the rest would stay the same (as in case of plain > > communication using SocketChannel/Selector). Another important use case > is > > the advent of IOT, where millions of devices, with relatively low > > throughput would want to protect their communication via SSL. > > > > The ways I have seen the community deal with this are mainly: > > > > 1. Go through the pain of learning SSLEngine (and hope to get it right) > > 2. Build their services around tested libraries (like Jetty, which handle > > the SSL offload but don't resurface it in SocketChannel/Selector > paradigm, > > that also come with their huge set of dependencies, bringing in > unavoidable > > version collisions) > > 3. Use proxies (nginx, ha) to deal with the high number of SSL > connections > > and divide the load by scaling horizontally in the back end (making for a > > harder deployment model) > > > > We can make this a lot easier! > > > > Any feedback is greatly appreciated, > > Best, > > > > Andi Mullaraj > > >
