ALPN API backport and JDK version

[Gil Tene]

[Adding jdk8u-dev]

> On Mar 3, 2020, at 5:51 AM, Simone Bordet <simone.bordet at gmail.com> wrote:
> 
> Hi,
> 
> as you may know, the Jetty Project created a `alpn-boot` jar with
> modified sun.* classes to support ALPN in Java 8.
> This certainly categorizes as a hack, but it allowed HTTP/2 to be
> widely deployed and tested on Java clients and servers well before
> Java 9 (with official ALPN APIs) and for those that did not upgrade
> past Java 8 yet.
> 
> 8u252 is scheduled to receive the backport of the ALPN API.
> 
> While code-wise it's not a big deal, build tools have a bigger problem.
> 
> AFAIK, build systems do not go beyond 3 digits for versioning Java, so
> it's almost impossible to tell the difference between 1.8.0_242 and
> 1.8.0_252 when building, as they are both seen as 1.8.0.
> My understanding is that this is done for max compatibility, as
> vendors tend to put anything after the 3 digits in a way that is
> impossible to parse and therefore establish an order (1.8.0_242 <
> 1.8.0_252) to be used in version ranges.
> 
> However, 8u242 and 8u252 are quite different with respect to the ALPN API (the
> former requires alpn-boot, the latter does not).
> 
> It would help quite a lot if 1.8.0_252 could be renamed to 1.8.1.
> 
> This would allow build tools like Maven Enforcer to explicitly say
> that a project can be built with only 1.8.0 and not 1.8.1 (to phase it
> out - in our case that would be applied to Jetty 9.2.x and 9.3.x),
> it would allow Maven Profiles to distinguish between the two (right
> now it's not possible), allowing to configure Maven Compiler and Maven
> Surefire (testing) with the extra options required (or not) by ALPN
> (e.g. add bootclasspath or not), etc.
> 
> I imagine this would be quite useful to all projects that somehow
> depend on the alpn-boot jar. By using a Maven profile (or equivalent), they
> will be able to specify a correct command line (including bootclasspath or not)
> and correct dependencies.
> 
> Do you think it will be possible to have a OpenJDK 1.8.1 instead of 1.8.0_252?

IMO such a change to the versioning will likely break a tremendous number of
existing working code. so I would advise against it.

AFAIK, due to the (seemingly necessary up to this point, so no judgement
tones intended) reliance on modified sun.* classes in the Jetty ALPN implementation,
there is already a strong version dependency between the ALPN jar the
specific 8u version. See detailed list at https://www.eclipse.org/jetty/documentation/current/alpn-chapter.html#alpn-versions <https://www.eclipse.org/jetty/documentation/current/alpn-chapter.html#alpn-versions> ,
showing that e.g. Jetty ALPN 8.1.13.v20181017 requires/is-required-for 8u191
and above. A mismatch between the Jetty ALPN version and the specific update
level of an 8u JRE/JDK will already break code using Jetty ALPN (I've personally
seen this in enough places that "check 8u version against to Jettty ALPN version"
is on my checklist for "usual suspects" when a new JDK install causes issues)

IMO the right way for Jetty ALPN to handle the new ALPN capability in 8u is for
the new/latest (and hopefully last) version of Jetty ALPN to target/match the version
of 8u that actually includes working built-in ALPN support (presumably 8u252
at this point), and that Jetty ALPN version would simply not include the sun.* classes
that previous versions had included to override the 8u internal functionality.
Assuming the API behavior remains the same (a big assumption, but one we should
probably check early), that should provide a smooth transition for setups that already
include Jetty ALPN. Yes, they would have the alpn-boot jar on the bootclasspath
"for no good reason", but things will continue to work just as they had before.

> 
> --
> Simone Bordet
> ---
> 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