ALPN API backport and JDK version

Simone Bordet simone.bordet at gmail.com
Tue Mar 3 16:22:28 UTC 2020


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.

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


More information about the jdk-updates-dev mailing list