ALPN API backport and JDK version

[Simone Bordet]

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?

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