[3.1] Jetty 12 HTTP/2 support

[senivam]

No description provided.

[jansupol]

java11 folder does not seem necessary. It can be put among the other files in the java folder. That would make the build (pom file) simpler.

[senivam]

I don't think it will work as expected. Because in the case of the JettyHttp2ClientSupplier.java in the separate src folder the resulting jar will look like:

META-INF/versions/<JDK-version>/<package>/JettyHttp2ClientSupplier.java

and for related JDK a proper version will be picked up. However, if the JettyHttp2ClientSupplier.java would be in the main src folder it will be located directly in the compiled classes folder org.glassfish.jersey.jetty.http2.container (without version separation), and JDK probably won't be able to overwrite it by picking another JettyHttp2ClientSupplier.java for a particular JDK version (17+ in our case)

[jansupol]

That's not how it works. The classloader first checks the META-INF versions and the classes afterwards. See for instance core-common in 2.x. It works for JDK 11, there is no META-INF/versions/8.

[senivam]

actually there is:

https://github.com/eclipse-ee4j/jersey/tree/2.x/core-common/src/main/java8/org/glassfish/jersey/internal/jsr166

[senivam]

Yeah, I've got why it shall be here - if we compile 2 similar classes within the same cycle. The compile phase will fail. It is required to exclude from compiling either one or another version of the same class file. It's not possible to compile both files within the same name in a similar compile phase.

[senivam]

In case of JDK 17+ and no version separation we will have 2 similar class names in one compile phase.

[senivam]

actually, the resulting jar jersey-jetty-http2-connector.jar does not have the versions/11 folder as well, only versions/17 but sources structure shall be kept for compilation reasons.

[jansupol]

Can the bom.pom be also updated?

[jansupol]

again java11 folder

[senivam]

see my first comment