Hi, On Wed, Jun 15, 2016 at 10:15 AM, Andrew Haley <a...@redhat.com> wrote: > The problem I have with reading posts about JDK9 problems is that I > can't tell the *severity* of the problems. I don't know if something > is a total blocker or an inconvenience. When someone uses an internal > sun.* class they may be doing something which must be done in order to > get access which would be impossible otherwise.
I don't understand this comment. The main issue of this thread is the current impossibility to have a clean and precise ALPN implementation with minimal code. Sure we can fallback to less optimal solutions that won't work in all cases. Sure we can duplicate the JDK logic and keep it up-to-date, invoke SNI twice, etc. But I don't see the point of settling for a less than optimal solution when there is room to make it better, and the effort is minimal. Is this issue a blocker ? Surely not, it is possible to rewrite from scratch a JSSE provider. Would I do that ? No, thanks. I am proposing 3 simple changes to be done: 1) Introduce a TLSProtocolNames class that can convert from TLS protocol bytes to TLS protocol names. 2) Introduce a TLSCipherSuiteNames class that can convert from TLS cipher suite bytes to TLS cipher suite names. 3) Delay handshaker.started=true so that it would simpler and more precise for an application to handle ALPN. I think these changes will benefit all the people involved in network servers having to play with ALPN. We *are* still in time, according to Mark Reinhold. The changes are simple. We have not heard from Oracle yet, but I can prepare a webrev if that helps. -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz
