My 2 cts would be to split anyway even if bnd can handle it: * mjar can imply some classloading overhead (java.util.jar.JarFile#getEntry) and keep the issue to have in a j17 jar > 17 bytecode (scanner not multirelease friendly will likely fail even if tomcat shouldnt be scanned it stays scanned quite often) * preview features are not that welcomed in default bundle IMHO - mainly embed case
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mar. 11 juin 2024 à 16:16, Rémy Maucherat <r...@apache.org> a écrit : > Hi, > > To fix the issue with having Java 22 classes in tomcat-coyote (and > embedded), I was looking at multi release JARs. I think it would work > fine *if* we were building the JARs ourselves (jarIt task), but then > the jars are actually rebuilt with bnd. > > Supposedly bnd 7.0.0 (which we just upgraded to) supports multi > release jars. After looking at their testsuite, it seems adding > "Multi-release: true" to the bnd and having the classes in the right > spot (META-INF/versions/22) would be enough [see: > https://github.com/bndtools/bnd/pull/5581/files ]. Unfortunately, this > keeps doing nothing for me. If anyone can get it to work, let me know. > > Anyway, instead of doing something too complex, I would instead be > back to producing a small tomcat-coyote-ffm jar. Then embedded users > can still use that small jar, even though it's a bit annoying to not > have it included in the big embed jar ... The naming of the jar will > be "stable" since even if adding quic/h3 to it somehow, the jar name > remains appropriate. > > Obviously all the mess comes from the combination of these two items: > - FFM missing the Java 21 cruise ship > - EE 11 downgrading to Java 17 > > :( > > So is it ok if I add a new tomcat-coyote-ffm.jar in lib ? > > Rémy > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
