Java SSLSocketChannel/SSLSelector?

Alan Bateman Alan.Bateman at oracle.com
Mon Mar 11 07:58:37 UTC 2019


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20190311/81b0ad23/attachment.htm>


More information about the security-dev mailing list