Java 17 / Jakarta Servlet migration

[Basil Crow]

Starting a new thread for Java 17 and the Jakarta Servlet API migration.

On Sun, Dec 19, 2021 at 6:12 PM Basil Crow <m...@basilcrow.com> wrote:
>
> When loading plugins […] in a Jakarta EE 9
> environment, we will probably need to apply some special compatibility
> transformations, exempli gratia, transforming the binaries after
> exploding the plugin or loading the plugin in a special class loader
> that transforms the classes as they are loaded. I have prototyped the
> former; the latter seems more challenging.

I implemented the latter today with Eclipse Transformer and updated
jenkinsci/jenkins#6085. As far as I can tell, the result is fully
functional when built with Java 17 and executed with `java --add-opens
java.base/java.lang=ALL-UNNAMED --add-opens
java.base/java.io=ALL-UNNAMED --add-opens
java.base/java.util=ALL-UNNAMED --add-opens
java.base/java.util.concurrent=ALL-UNNAMED -jar war/target/jenkins.war
--enable-future-java`. Others should be able to reproduce my results.

As mentioned in the PR, the resulting design is much like the old
Bytecode Compatibility Transformer that I got rid of a while back. :-)
You can see the code in JakartaCompatibilityTransformer,
JenkinsClassLoader, AntClassLoader, and URLClassLoader2. Tests still
don't work, because they don't go through the same class loader
hierarchy as production code does. I haven't yet thought about how we
can apply the compatibility transformation in test context.