Repository navigation
FELIX-6807 - Java 25 LTS support - #433
paulrutter wants to merge 54 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. |
main is changed by this branch, its dependency on the framework moves to
8.0.0-SNAPSHOT, and it embeds the framework, yet nothing verified it: there was no
main path filter and no build step, so a break would only have surfaced at release
time.
Building it locally first showed it does not build on a modern JDK at all, for the
same reason as the modules in the split-out build repair change: it declares
felix-parent 6, which does not match the local pom, so Maven resolves the released
parent from Central. That parent brings in ianal-maven-plugin 1.0-alpha-1, which
reflects into java.io and is blocked from Java 16 on:
Unable to make private java.io.File(java.lang.String,java.io.File) accessible:
module java.base does not "opens java.io" to unnamed module
Moving to felix-parent 9 removes ianal but pins maven-antrun-plugin 3.1.0, which
rejects the legacy tasks element:
You are using 'tasks' which has been removed from the maven-antrun-plugin
Both antrun executions now use target instead.
main has no code change, so its version stays at 7.1.0-SNAPSHOT. The step runs after
the framework step, which installs the framework it embeds.
Verified on JDK 25: main builds, the jar embeds the framework, and launching it
starts the framework and keeps running, with no Security Manager error. The only
output is the known sun.misc.Unsafe warning from URLHandlers.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…uild output main bundles the framework, so shipping main 7.1.0 containing framework 8.0.0 would be misleading. Its version moves to 8.0.0-SNAPSHOT alongside the framework. main.distribution is unaffected: it pins framework.version to the released 7.0.5 and consumes published artifacts rather than this build. Also removes six jars totalling 1.7 MB that were committed by mistake in the previous commit. main/bundle is populated by the build, is not tracked on master, and was not ignored, so a plain add picked it up. main/bundle, main/bin and main/conf are now in .gitignore, all three being build output of this module. Verified on JDK 25: main builds at 8.0.0-SNAPSHOT and the build no longer leaves untracked artifacts behind. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
main.distribution copies bundles into its basedir the same way main does, so building it leaves untracked jars behind in bundle/ and bin/. Both are now ignored. main.distribution/conf is tracked and is deliberately not ignored. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…modern-jdk # Conflicts: # .github/workflows/maven-ci.yml
|
@apache/felix-committers please take a look at #433 (comment) and let me know your thoughts on this. I would like to move this JDK 25 thing forward, given it's released for a while now. I does bring the baseline for framework to JDK 9, but given we can still maintain a JDK 8 branch if required, i would think that's acceptable. |
…stances Util.loadDefaultProperties returned the shared static DEFAULTS instance, and its callers write per framework values into the result: initializeJPMSEE stores felix.detect.java.version, and ExtensionManager stores the resolved system package lists with that version baked into each entry. So the first framework created in a JVM stamped its own Java version onto every framework created after it. Two frameworks in one JVM configured with different java.specification.version values would share the first one's system packages. This showed up as ExtensionManagerTest.systemBundleHeaders failing on some JDKs and not others: MultiReleaseVersionTest creates a framework with java.specification.version 9, and when it ran first the later test saw java.lang exported as 0.0.0.JavaSE_009 rather than the running JDK's version. Test order varies between JVMs, which is why it failed on 21 and 23 while passing on 17 and 25. loadDefaultProperties now returns a copy, so each framework computes its own values. Verified on JDK 21 and 25: 121 tests with no errors, and systemBundleHeaders passes when run together with MultiReleaseVersionTest in one JVM. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
JDK 11 as lower bound would be an option too - it will receive updates till next year at least. The libs might be able to use a few new APIs and it might be easier to test, given that running CI against EOL JDK 9 is always a bit awkward. Projects stuck on EOL JDKs typically don't care about dependency updates, otherwise they wouldn't be there in the first place. So the scenario that someone is running JDK 9 && wants to update felix to the latest version is quite unlikely IMO. (I am no committer) |
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. |
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