Repository navigation
FELIX-6807 - Java 25 LTS support - #433
paulrutter wants to merge 57 commits into
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. |
That's a fair point, but given what i know from other PRs where the baseline was proposed to be lifted, we got some pushback on it. I agree that consumers on older JDK versions can remain to use the 7.x line, while 8.x should lift the baseline. |
I think it will depend on how the lower bound changes though. If its in the next major version while the last major version is still maintained - i can't see how this would cause pushback. My main point was that bumping the lower bound from LTS 8 to EOL 9 (on the next major version) is not much different to bumping it from LTS 8 to LTS 11 - since it isn't 8 anymore in both cases ;) |
paulrutter
changed the title
FELIX-6759 Follow-up: Make the remaining module builds work on modern JDKs
FELIX-6759 Follow-up: Replace Thread.stop() with interrupt() in configadmin UpdateThread
…Java-25-LTS # Conflicts: # .github/workflows/maven-ci.yml # utils/pom.xml
StackWalker, which replaces SecurityManager.getClassContext(), is the only thing that forced the baseline above 8, and it arrived in 9. Nothing in the framework uses anything from 10 or 11, so the choice of floor is free. 9 and 10 are non-LTS and long EOL, so landing on 11 drops no supported JVM while giving a maintained LTS floor. This is already a major version, so the baseline move is paid for once either way. The bundle now requires osgi.ee JavaSE 11 instead of 9. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The pom comment and the framework README still described 9 as the floor and the declared execution environment. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Agreed, and done — the framework baseline is now 11 rather than 9. Your framing is the right one: the cost is in leaving 8, and that's paid either way. The bundle now declares One thing I left alone: adding 11 to the CI matrix. That matrix is the build JDK, not the baseline — |
|
by the way in PDE (and likely soon in Equinox as well) we are using multi-release jars to support possibly degraded support for lower JVM versions - might be an option for felix as well. JDT+m2e got recently improved to better support MR development in the IDE as well but feedback is always appreciated. |
There is quite some discussion on this in this PR, see #433 (comment). What i'm proposing after all of this is that we maintain two branches instead of using MRJ's. |
|
Thanks for the update Paul. I am wondering if there is an associated timeline for having a released version of Apache Felix supporting JDK 25? A very rough non-binding ETA if you prefer. |
I would love to answer that, but this PR hasn't gotten a lot of traction from the community yet. Ideally i would get some more feedback before we merge it. If that doesn't happen, i will merge this it at some point (let's say end of october this year) and send out a release vote so we can force movement either way. |
|
Fully agree! I just wanted to give some feedback here (since the comments are spanning a long time here) that it is at least when using in dedicated focused parts not that bad at all. |
UpdateThread.terminate() no longer calls Thread.stop(), which has thrown UnsupportedOperationException since Java 20, and interrupts the worker instead. The class is in the non-exported org.apache.felix.cm.impl, so no exported API changes, but the shutdown behaviour does: what used to throw now interrupts. The same change moves the module to felix-parent 9 and excludes ConfigAdminSecurityTest above JDK 17, since it sets org.osgi.framework.security and so needs -Djava.security.manager=allow, which is itself a fatal startup error from Java 24 on (JEP 486). That leaves a shipped capability the build can no longer verify above 17. Together that is more than a patch, so 1.9.27-SNAPSHOT becomes 1.10.0-SNAPSHOT. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Artifacts that would need releasingIf this PR and #552 both land, these are the modules with production code changes. All versions are bumped in the branch.
Changed but deliberately not released
On plurl#552 vendors the plurl sources under |
Missed when the baseline moved from 9 to 11. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
I have noticed too. I cannot give any feedback personnally since I am not using Felix. It's another team which does and they are extremely busy right now. We have some dependencies on them, so I am eager to see them move to JDK 25 so they unblock us 😄 Hence why I am monitoring this PR. Many thanks for all your efforts ! |
Btw, we're already running JDK 25 in production with the current Felix framework 7.0.5. As long as you don't use the security manager, you'll only see a few deprecation warnings, but it still runs and works ok. Might be good to keep in mind. |
They are using |
IMO: "support" is an overloaded term. Some use it for "it appears to be working", others rise the bar a little higher. I personally try to use "support" only when CI of that project tests on those JDK versions (at the bare minimum). E.g NetBeans 32 is using felix atm too (supports running on JDK 21, 25 and 27) but it would fail if something uses certain features (even by accident). - java: [17,21,23]
+ java: [17,21,23,25]speaking of versions: I would consider adding |
Drops 23 and adds 27, so the matrix only covers releases that still receive updates: 23 was superseded by 24 in March 2025 and its last Temurin build is 23.0.2 from January 2025. 26 is left out for the same reason: 27 superseded it in September 2026, so 26.0.2.1 is its final update. It was tried on the plurl branch and the framework and the OSGi Core R8 TCK passed there, so nothing is lost by not keeping it in the matrix. That leaves the two LTS releases in use plus the current non-LTS. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Agreed on both counts, and on the definition — "tested in CI" is a much more useful bar than "seems to work", and it is exactly the gap here: 7.0.5 predates the framework having a CI job at all (FELIX-6765 added it for 7.1.0), so nobody could say what it was tested against. Matrix is now Applying your own rule, 26 comes out too: 27 superseded it in September 2026, so
The framework itself is fine on 26 and 27 — both green including the OSGi Core R8 TCK, checked on the plurl branch (run), where the path filters build only Noting NetBeans 32 runs on 21, 25 and 27 — 27 is the one we cannot cover yet, for the reason above. |
Drops 23, which was superseded by 24 in March 2025 and whose last Temurin
build is 23.0.2 from January 2025.
27 was added and is taken out again: it fails, but not in anything this change
touches. Aries SpiFly 1.3.7 bundles ASM 9.6, which rejects class file major
version 71, so its weaving hook throws for every class it sees and Jetty never
finishes starting:
java.lang.ClassFormatError: Weaving hook failed.
Caused by: java.lang.IllegalArgumentException: Unsupported class file major version 71
That leaves JettySniHostCheckIT waiting 30 seconds for an HttpService that
never registers. SpiFly 1.3.8 carries ASM 9.10.1, which does know version 71,
but it is not a drop-in replacement: its imports changed and the test container
then has unresolved bundles. Tracked separately rather than carried here as a
red job or an exclusion.
That leaves the two LTS releases in use. The framework itself passes on 26 and
27, checked on the plurl branch where only the framework and the TCK build.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Matrix is 27 does fail, but not in anything this PR touches. Aries SpiFly 1.3.7 bundles ASM 9.6, which rejects class file major version 71, so its weaving hook throws for every class it sees and Jetty never finishes starting:
SpiFly 1.3.8 carries ASM 9.10.1, which does declare While digging I also found that the Felix HTTP ITs pin Both are filed as FELIX-6869. Once the first part lands, 27 can go back in the matrix. For the record, the framework itself is fine on 26 and 27 — both green including the OSGi Core R8 TCK, checked on the plurl branch where the path filters build only |
…Java-25-LTS # Conflicts: # .github/workflows/maven-ci.yml # framework.tck/tck.bndrun # http/jetty/src/test/java/org/apache/felix/http/jetty/it/AbstractJettyTestSupport.java # http/jetty12/src/test/java/org/apache/felix/http/jetty/it/AbstractJettyTestSupport.java
Indeed, I got things mixed up. Thanks again for your comment and work! |
9 participants
Try-out building framework and HTTP subprojects against java 25 to see what will break
https://issues.apache.org/jira/browse/FELIX-6807