FELIX-6759 - Java 25 LTS support #433
Conversation
- Try-out building framework and HTTP subprojects against java 25 to see what will break
- Use 25-ea (Early access)
- Update mockito-core to a version that has jdk 25 support via byte-buddy
- Update awaitility
- Disable jetty bundle
- Don't rely on snapshot build for jetty
|
can you also do a change in scr to trigger this test |
on detail |
Will do tomorrow 👍 |
- continue-on-error: true to allow building other modules after a failed one - Change SCR to trigger CI
|
might be interesting to du parallel build for matrix like here in osgi repo |
|
Results of the latest run, including SCR: SCR Framework HTTP |
I discussed this at https://www.mail-archive.com/dev%40felix.apache.org/msg57202.html But I didn't have any luck getting feedback on using a common solution between Equinox and Felix (and maybe others). Therefore I only integrated it into Equinox to get rid of the use of Unsafe for the URL singleton management. If someone from Felix would like to adopt the same strategy as I did in Equinox I think it would be good so the two framework's can live in the same JVM without cratering the URL singletons. |
|
Thanks @tjwatson, from my point of view we should indeed consider adopting the same approach as you mentioned in osgi/osgi#226 (comment). |
|
common solution between Equinox and Felix .... And springboot would be really best way to solve. |
I don't disagree but I have my doubts the SpringBoot URL factories will be open to play well with others. Worth a try if you already have a good contribution relationship with the Spring project to bring up the issue. But I first suggest we get Felix and Equinox to play well with each other to prove out the approach. |
|
In addition to the changes of removing the use of sun.misc.Unsafe, all code in Framework using SecurityManager should be removed, since SecurityManager has been completely disabled from Java 24 onwards. |
|
I disagree with your comment in Security manager. In all cases where Security Managemer is uses we check Existense before we use that. So no execution in Versions where Security Manager is remived. |
|
With the SecurityManager removal, it makes it difficult to support wide JDK LTS version ranges. I suggest making two supported branch streams with JDK LTS version alignment. There are two issues with trying to support a wide range of JDK versions:
The approach we are looking at taking in Apache ActiveMQ and Apache Karaf is to have branches with JDK supported ranges:: branch-a: Supported Java: JDK 17 to 21 (Apache Karaf is able to do JDK 11 to JDK 21) It does to appear that it is physically possible to mismatch JAAS API across JDK 11-25 or JDK 17-25 b/c of the JAAS API change. One side sets a ThreadLocal and uses doAs() and the newer API uses ScopedValue and runAs() methods on the Subject class. see: https://docs.oracle.com/en/java/javase/21/docs/api/java.base/javax/security/auth/Subject.html |
Is the class completely gone? I would be surprised because I would have expected loads of class not founds when running Equinox on Java 25, but we don't observe that. |
|
@mattrpav Just wanted to note that JDT has now new support for multi-release jars that maps nicely to what we have in maven. Multi-Release Jars are a perfect fit for such kind of support such JDK dependent changes, then one only need a |
|
@tjwatson I mispoke-- JDK 25 disables the SecurityManager by default and custom SecurityManages cannot be installed. @laeubi MRJ is a good idea, will check that out. Have you solved for how to do JDK-version-specific unit tests in a single Maven module? If so, I'd love to see a sample configuration. |
Let me know if you need any pointer or support, we would need something similar for equinox on the long run. Regarding testing the most useful these days is a matrix build what uses different native JVMs... of course one can write MR-Test cases as well its just a bit more setup. |
I have a distaste for MRJ. If we create a |
Yeah, the how-to-execute-tests is the issue I'm running into. Creating a MR-jar for compiling and packaging test classes seems straight-forward. The hang-up comes in as far as how to instruct the surefire plugin to execute those tests. ASFAIK, would require two separate Maven profiles (kludgy-- as the surefire configurations would need to be kept in sync b/w the two profiles) for listing include/exclude of class test names based on JDK version. Punting to use separate Maven modules by JDK version seems less than ideal. |
Anything specific? I'm looking at using a MRJ for activemq-client to use that for the Virtual Thread classes that need JDK 21+. |
It has been a while since I looked into them seriously. But the first blocker from me was source code debugging and what the source JAR looks like for the release. It was a nightmare to debug. Maybe all that is fixed by now. But it seemed far more simple to just choose the class to load myself in code. |
But this will only work if the API is not gone (or non existent) if you not choose reflection ... what is a nightmare on its own of course.
As said MR support in JDT is quite new and there is obviously a lot to improve, but if anything is missing it could be linked here: so I can only invite everyone to participate there :-)
While this might work in this case (see above) this is simply not manageable for any more complex API as it would require you to use reflection all the time, that has no compile time checking, it has no real debugging support or anything so not really something I would call "more simple".
The source jar?!? Do you mean the final build jar or the source code in the project? |
This is all theoretical since I also would never recommend using a compiler that doesn't understand the release you are targeting where the class still exists that your code wants to use on old Java versions. Even if/when they really remove the class the Since Oracle just extended their Java 8 support way out to 2030 (and other vendors will follow) I don't see that happening any earlier for the new Java versions being released through 2030. I suspect they will continue to support
I mean the source jar, typically published to maven central. As in org.eclipse.osgi-3.23.200-sources.jar Even if that all works out and all IDEs handle it in a useful way. I often am handed an error log and asked to analyze some stack trace with methods and line numbers. At that point it is nice to just know the version I am dealing with to find the code for the class/method/line-number in the stack trace without having to worry about which "version" of the class within the MRJ got loaded. I am doubtful anyone can convince me that MRJs are a perfect solution for me. |
Even for that I would use a separate project that holds the Java 21+ code that uses Virftual Threads and then pull the classes into the project that still targets the old Java release. Then have code that knows what class to load based on Java versions. That is what we do for the Virtual threads. We then created an For example, this component only gets enabled for Java versions < 21: And this one gets enabled for Java versions >= 21 The rest of the system gets injected with the right component implementation without having to worry about what Java version is running. |
That's an elegant solution to the problem indeed. In Felix, we have resorted to reflection to determine java 21 specific features, see for example To get back to the problem of the SecurityManager in Felix, i feel we've only scratched the surface and are not aligned on the approach to take. The options as i see them:
I don't have a strong preference yet, but i do think we should come up with a plan forward, while also respecting the OSGi spec on the security aspects. |
I don't want to convince anyone, just mentioning that its maybe worth to consider and most of what you describe more feels like limitations of the tooling that could probably be better enhanced there. Compared to that your solution seem to add a lot of complexity both on the build time as well as dev time just to emulate a feature the JVM can already offer to you (you then need to make sure to have at least a MR OSGi-Manifest), but again I don't want to convince anyone and there are obviously multiple ways. The problem of multi-release source jars is discussed here so you maybe want to leave a not if you thing its not feasible (even though you not plan to use it) as likely others might still adopt: |
|
I solved for MRJ usage in ActiveMQ for Virtual Thread support without adding additional Maven modules based on JDK version.
ref: apache/activemq#1504 |
|
org.osgi.framework.BundleException: Unable to resolve com.github.ben-manes.caffeine [15](R 15.0): missing requirement [com.github.ben-manes.caffeine [15](R 15.0)] osgi.ee; (osgi.ee=UNKNOWN) Unresolved requirements: [[com.github.ben-manes.caffeine [15](R 15.0)] osgi.ee; (osgi.ee=UNKNOWN)]
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4398)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2308)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1566)
at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:297)
at java.base/java.lang.Thread.run(Thread.java:1474)
Nevermind! The problem is the BND plugin does not yet support JDK-25 and emits an invalid |
7 participants
Try-out building framework and HTTP subprojects against java 25 to see what will break