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