Thank you Alan, I am in awe! If Loom delivers on its promises I see no point continuing this (or any blocking/async/io) discussion. I think I will open source my implementation.
Thanks to all for the feedback, Best, --Andi On Mon, Mar 11, 2019 at 12:58 AM Alan Bateman <alan.bate...@oracle.com> wrote: > 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 >
