On 09/03/2019 09:35, Andi Mullaraj wrote:

In light of the previous point, I couldn't disagree more. As it is painfully clear, the proposed approach stays within the confines of nio, and no duplication is needed (I also hate duplication).

This is a topic that was explored, and ruled out, in JSR-51 but lead to SSLEngine. Yes, SSLEngine has pain points and performance issues and I think it would be better to focus on those issues and see how SSLEngine could be improved. This would be more beneficial for the eco system today as most developers don't use SocketChannels or Selectors directly (those APIs tend to be hidden by libraries and frameworks so most developers don't see them).

Also as a reminder is that we are exploring, in Project Loom, ways to make it easy to develop simple blocking code that scales as well as code forced to asynchronous frameworks today. If we get that right then it should eliminate many of the reasons to create further asynchronous or non-blocking APIs.

-Alan

Reply via email to