Starting a new thread for Java 17 and the Jakarta Servlet API migration. On Sun, Dec 19, 2021 at 6:12 PM Basil Crow <[email protected]> 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. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjrVLEc5YGv%3D%2Bivzencf%2BGqTsSpHZvYSPikKQYTqfQu4BA%40mail.gmail.com.
