ALPN API backport and JDK version

[Gil Tene]

> On Mar 3, 2020, at 8:22 AM, Simone Bordet <simone.bordet at gmail.com> wrote:
> 
> Gil,
> 
> thanks for your insights, more inline.
> 
> On Tue, Mar 3, 2020 at 4:33 PM Gil Tene <gil at azul.com> wrote:
>> IMO such a change to the versioning will likely break a tremendous number of
>> existing working code. so I would advise against it.
> 
> Fair, the idea was to start a discussion and see where it was going.
> 
>> 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.
> 
> Just to clarify that the smooth transition for runtime behavior is
> already the case.
> 
> The ALPN boot jar in the bootclasspath for no good reason is ok, but
> eventually (given that JDK 8 is supported by vendors until 2030) at a
> certain point one would like to get rid of it.
> And that is where the difficult part comes, convincing the build tools
> (I know Maven has, but I suspect others will have similar problems).
> 
> I mean, it's solvable (people will just start to write custom Maven
> plugins that can handle the "_xyz" part), and everyone will write
> their own solution.
> Having 1.8.1 will be much easier and require no "creative"
> customization of the build tool in use.
> 
> Do you have examples of 1.8.1 breaking existing code? Just curious.

E.g. Code that parses the "java.version" property, translates it to a double,
and then assumes Java 8 is == 1.8 (and that >1.8 is not Java 8) is common
case, and seems to be copied across many applications. Here is an example:

https://github.com/Col-E/Recaf/blob/257783d54713d9cd352c19ad93a11cb79a5670ba/src/main/java/me/coley/recaf/util/Dependencies.java#L34 <https://github.com/Col-E/Recaf/blob/257783d54713d9cd352c19ad93a11cb79a5670ba/src/main/java/me/coley/recaf/util/Dependencies.java#L34>

Some JDK installation tools out there assume "8" or "1.8" or 8uXYZ
for version names in either or in their internal configuration files, and do not
currently have support for saying something like 1.8.1uX.

E.g. Jabba tracks Java 8 versions in its internal json files with 1.8.u
(so assuming nothing between 1.8 and the u):
https://github.com/shyiko/jabba/blob/master/index.json <https://github.com/shyiko/jabba/blob/master/index.json>

And that's just off the top of my head.

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