Hello Volunteers,
>>>>> On Fri, 9 Dec 2016 10:01:34 -0800, Edward Burns <edward.burns_at_oracle.com> said:
EB> Here's the latest on the ALPN issue. As we discussed at the 2016-11-01
EB> meeting, work will proceed on two fronts, the Java SE 9 front and the
EB> JDK 8 front.
Sigh.
EB> I'd like to extend a special thanks to Vinnie to spearheading this
EB> vitally important work. It goes a long way to help the Java community,
EB> and especially the community of Servlet 4 implementers.
I'm still thanks to Vinnie for his help.
EB> Java SE 9
EB> =========
EB> Just yesterday Vinnie sent this to security-dev:
EB>
http://mail.openjdk.java.net/pipermail/security-dev/2016-December/015266.html
EB> I'll pass along his appeal here:
Work is proceeding apace here. Thanks to everyone who helped on it.
EB> JDK 8
EB> =====
[...]
EB> We cannot give any commitment on delivery dates for this in JDK 8, but
EB> it will certainly depend on the JDK 8 Update schedule and security team
EB> priorities.
EB> Thanks for your patience.
Unfortunately, I don't have good news here. Those priorities are
outside of our control and a definitive decision has been taken to not
pursue the backport to JDK 8 as we discussed late last year and early
this year. As a consolation, we are making available the JDK 1.8.0_121
specific solution we are using for the Grizzly based GlassFish 5.0 RI,
as detailed in this message from Java EE Architect Bill Shannon:
>>>>> On Mon, 17 Apr 2017 13:51:45 -0700, Bill Shannon said:
B> The Servlet 4.0 specification intended for Java EE 8 includes support
B> for the HTTP/2 standard, which requires an implementation of ALPN.
B> ALPN support is included in the SSL/TLS implementation in JDK 9. Given
B> that Java EE 8 should be supported on JDK 8, we understand that it will
B> be beneficial for Java EE licensees to have ALPN available in JDK 8.
B> Oracle is focused on JDK 9 and JDK 10 at this time and has no plans to
B> backport new major features in critical patch updates.
B> We understand that some of the Java EE licensees have already created
B> workarounds to have HTTP 2.0 work with JDK 8. A typical workaround is
B> to modify some classes from JDK 8 to support ALPN, and then to use them
B> to effectively "patch" JDK 8 with these new APIs and implementation.
B> Since the Oracle Binary Code License prevents replacing or overriding
B> arbitrary classes in the Oracle JDK, Oracle intends to make changes for
B> the upcoming JDK 8 critical patch update to allow overriding these
B> SSL/TLS implementation classes.
B> Oracle will also provide a replacement SSL/TLS implementation as a
B> "patch" that can be applied to this version of JDK 8 that will provide
B> the required ALPN support needed by the Servlet reference
B> implementation. This patch will be provided as a part of the Java EE
B> reference implementation and can be used by licensees and end users.
B> This patch would be applied using something like -Xbootclasspath or
B> some equivalent OSGi mechanism so that these classes override the
B> classes included in the JDK without modifying the JDK itself. Licensees
B> may need to create their own patch or modify the reference implementation
B> patch to meet the needs of their product.
B> Given that the JDK 9 release is imminent, we expect that the workaround
B> will suffice for the lifespan of JDK 8 deployments. We expect most
B> Java EE implementations to move to JDK 9 quickly, and some may never
B> need to support JDK 8. We do understand you might be worried about
B> the additional risk you are taking on by use of copied/non-public
B> APIs and we will do our best to communicate to Java EE licensees any
B> significant changes to these SSL/TLS implementation classes in future
B> JDK updates.
Bottom line, in spite of our best efforts, ALPN support remains an
implementation detail for Servlet 4.0 implementations.
Sincerely,
Ed and Shing-wai Chan
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| 4 business days until planned start of Servlet 4.0 Public Review