Skip to content

Conversation

@mattrpav
Copy link
Contributor

@mattrpav mattrpav commented Sep 2, 2025

No description provided.

@mattrpav mattrpav changed the title [#8005] Update minimum release/source/target to JDK 21 WIP: [#8005] Update minimum release/source/target to JDK 21 Sep 2, 2025
Copy link
Member

@jbonofre jbonofre left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should update the CI in .githuh/workflows/build.yaml.

@jbonofre
Copy link
Member

jbonofre commented Sep 2, 2025

NB: instead of using WIP in the title, we can use draft PR.

@mattrpav
Copy link
Contributor Author

mattrpav commented Sep 2, 2025

@jbonofre Heads up-- there is a build break in karaf-maven-plugin holding up a clean compile. I'm not familiar with the build process for that plugin.

@jbonofre
Copy link
Member

jbonofre commented Sep 2, 2025

It's simply because we have dependency not JDK21+ compatible, so we have to update:

java.lang.IllegalArgumentException: Unsupported class file major version 65

The culprit is ASM :)

@mattrpav
Copy link
Contributor Author

mattrpav commented Sep 2, 2025

The culprit is ASM :)

asm is latest v9.8?

karaf-maven-plugin % mvn dependency:tree | grep asm
[INFO] |  \- org.apache.xbean:xbean-asm9-shaded:jar:4.27:compile
[INFO]    +- org.ow2.asm:asm:jar:9.8:test

Update: mvn -X debug output confirms the issue is with asm

Caused by: java.lang.IllegalArgumentException: Unsupported class file major version 65
    at org.objectweb.asm.ClassReader.<init> (ClassReader.java:184)
    at org.objectweb.asm.ClassReader.<init> (ClassReader.java:166)
    at org.objectweb.asm.ClassReader.<init> (ClassReader.java:152)
    at org.objectweb.asm.ClassReader.<init> (ClassReader.java:273)
    at org.apache.maven.tools.plugin.extractor.annotations.scanner.DefaultMojoAnnotationsScanner.analyzeClassStream (DefaultMojoAnnotationsScanner.java:207)

Update 2: Looks like older plugins are pulling it in. I'm running it down now

Update 3 (2025/09/02): Currently, a couple tests are failing b/c the jre.properties and config.properties files (with eecap) need to be centralized to a single folder and referenced/copied around for consistency.

@mattrpav mattrpav force-pushed the karaf-8005 branch 2 times, most recently from 93dcbf5 to 3deadbb Compare September 2, 2025 18:11
@mattrpav
Copy link
Contributor Author

mattrpav commented Sep 18, 2025

Files containing 'eecap'

% find . -type f -exec grep -il eecap {} \;                           
./RELEASE-NOTES.md
./itests/test/src/test/filtered-resources/etc/config.properties
./util/src/main/java/org/apache/karaf/util/config/PropertiesLoader.java
./features/core/src/main/java/org/apache/karaf/features/internal/region/SubsystemResolver.java
./assemblies/features/base/src/main/filtered-resources/resources/etc/config.properties
./instance/src/main/resources/org/apache/karaf/instance/resources/etc/config.properties
./main/src/test/resources/test-karaf-home/etc/config.properties

Property file candidates for consolidation or move to etc/appended-resources to be shared across projects

./tooling/karaf-maven-plugin/src/test/offline.properties
./tooling/karaf-maven-plugin/src/it/test-check-dependencies-failure/dependencies-features/invoker.properties
./tooling/karaf-maven-plugin/src/it/test-check-dependencies-failure/invoker.properties
./tooling/karaf-maven-plugin/src/main/resources/config.properties
./itests/test/src/test/filtered-resources/etc/config.properties
./util/src/main/filtered-resources/org/apache/karaf/util/versions.properties
./assemblies/features/static/src/main/resources/resources/etc/system.properties
./assemblies/features/base/src/main/filtered-resources/resources/etc/jre.properties
./assemblies/features/base/src/main/filtered-resources/resources/etc/config.properties
./assemblies/features/base/src/main/filtered-resources/resources/etc/custom.properties
./assemblies/features/base/src/main/resources/resources/etc/system.properties
./system/src/test/resources/etc/system.properties
./instance/src/test/resources/etc/startup.properties
./instance/src/main/resources/org/apache/karaf/instance/resources/etc/system.properties
./instance/src/main/resources/org/apache/karaf/instance/resources/etc/config.properties
./jaas/modules/src/test/resources/org/apache/karaf/jaas/modules/properties/test.properties
./main/src/test/resources/test-karaf-home/etc/jre.properties
./main/src/test/resources/test-karaf-home/etc/config.properties
./main/src/test/resources/test-karaf-home/etc/startup.properties
./client/src/test/resources/etc1/custom.properties
./client/src/test/resources/etc2/custom.properties

@holgerfriedrich
Copy link
Contributor

@mattrpav There are some <javase> tags left in pom files, pointing to older java versions. After replacing those, the compilation/feature verification seems to pass. (I also rebased to the current main, just in case it does not compile yet with this change).

@jbonofre
Copy link
Member

I will fix the karaf-maven-pluginn and finalize this one with @mattrpav and @holgerfriedrich

@mattrpav
Copy link
Contributor Author

mattrpav commented Sep 27, 2025

javase

Thank you!

edit: I updated and the build completes! A couple new commits added to the branch.

@holgerfriedrich
Copy link
Contributor

Great. I need that included to change the Jaas stuff which does no longer run on JDK25.
(btw: I tried to push, but that is only allowed for collaborators on your repo).

Your commit regarding the javase changes matches the changes I made on my system. 👍

@jbonofre
Copy link
Member

I merged deps for karaf maven plugin. Rebasing should help too.

@jbonofre
Copy link
Member

jbonofre commented Sep 28, 2025

The XATest is running forever, stuck on checking Artemis broker status using log:display. I'm adding a timeout on this test and also improve the broker check mechanism, and version to be JDK21 "compliant".

@jbonofre
Copy link
Member

Just pushed a quick improvement to see if it helps :)

@mattrpav
Copy link
Contributor Author

itest/test/../JavaSecurityTest hanging on pax-exam init

[INFO] Running org.apache.karaf.itests.JavaSecurityTest
2025-09-28 07:55:58,183 | INFO  | j.pax.exam.spi.DefaultExamSystem  127 | Pax Exam System (Version: 4.14.0) created.
2025-09-28 07:55:58,200 | INFO  | .pax.exam.junit.impl.ProbeRunner   74 | creating PaxExam runner for class org.apache.karaf.itests.JavaSecurityTest
2025-09-28 07:55:58,314 | INFO  | .pax.exam.junit.impl.ProbeRunner   94 | running test class org.apache.karaf.itests.JavaSecurityTest
2025-09-28 07:55:58,316 | INFO  | iner.internal.KarafTestContainer  161 | Creating RMI registry server on 127.0.0.1:59334
2025-09-28 07:55:58,668 | INFO  | iner.internal.KarafTestContainer  255 | Found 0 options when requesting OverrideJUnitBundlesOption.class
2025-09-28 07:55:58,672 | WARN  | iner.internal.KarafTestContainer  442 | you're trying to add an additional value to a config file; you're current value will be replaced.
2025-09-28 07:55:58,672 | WARN  | iner.internal.KarafTestContainer  442 | you're trying to add an additional value to a config file; you're current value will be replaced.
2025-09-28 07:55:58,679 | INFO  | iner.internal.KarafTestContainer  308 | Wait for test container to finish its initialization [ RelativeTimeout value = 3600000 ]
2025-09-28 07:55:58,681 | INFO  | rn.RemoteBundleContextClientImpl  241 | Waiting for remote bundle context.. on 59334 name: 675d92e8-4418-4d05-9459-d8dbc8d04e8a timout: [ RelativeTimeout value = 3600000 ]
The Security Manager is deprecated and will be removed in a future release

@holgerfriedrich
Copy link
Contributor

Do you think this is related to the SecurityManager?
In JDK21, it is disabled by default. In the end, we need to get rid of it anyway.
Could it help for now to add a VMOption to enable it -Djava.security.manager=allow?

I have the feeling updating the remaining packages will be easier once we get the CI lifted to JDK21.

@mattrpav
Copy link
Contributor Author

mattrpav commented Sep 28, 2025

@holgerfriedrich I tried adding it to the surefire plugin in both places in the pom.xml and the maven cli, but no luck. I believe it must be added at JVM startup to work, and placing it in a static code block would not be early enough in the startup sequence.

cli:

mvn test -Dtest=JavaSecurityTest -Djava.security.manager=allow

pom.xml

...
  <java.security.manager>allow</java.security.manager>
</systemPropertyVariables>

edit:

Neither of these worked:

JavaSecurityTest:

    systemProperty("java.security.manager").value("allow");
...

    editConfigurationFilePut("etc/system.properties", "java.security.manager", "allow"),

@holgerfriedrich
Copy link
Contributor

I have not yet checked how the itests are launched.
Just FYI: I have seen JVM options in KarafTestSupport.java, KarafMinimalMonitoredTestSupport.java, and InstanceServiceImpl.java.
But not sure if the missing SecurityManager is the root cause for the test to fail.

@mattrpav
Copy link
Contributor Author

Updated the root pom.xml and was able to get the system property on the command line, verified with maven in debug mode.

[DEBUG] Forking command line: /bin/sh -c cd '/karaf/itests/test' && '/Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home/bin/java' '--add-opens' 'java.base/java.security=ALL-UNNAMED' '--add-opens' 'java.base/java.net=ALL-UNNAMED' '--add-opens' 'java.base/java.lang=ALL-UNNAMED' '--add-opens' 'java.base/java.util=ALL-UNNAMED' '--add-opens' 'java.naming/javax.naming.spi=ALL-UNNAMED' '--add-opens' 'java.rmi/sun.rmi.transport.tcp=ALL-UNNAMED' '-Djava.security.manager=allow' '-jar' '/karaf/itests/test/target/surefire/surefirebooter-20250928114059171_3.jar' '/karaf/itests/test/target/surefire' '2025-09-28T11-40-59_111-jvmRun1' 'surefire-20250928114059171_1tmp' 'surefire_0-20250928114059171_2tmp'
[DEBUG] Fork Channel [1] connected to the client.
[INFO] Running org.apache.karaf.itests.JavaSecurityTest
2025-09-28 11:40:59,416 | INFO  | j.pax.exam.spi.DefaultExamSystem  127 | Pax Exam System (Version: 4.14.0) created.
2025-09-28 11:40:59,434 | INFO  | .pax.exam.junit.impl.ProbeRunner   74 | creating PaxExam runner for class org.apache.karaf.itests.JavaSecurityTest
2025-09-28 11:40:59,735 | INFO  | .pax.exam.junit.impl.ProbeRunner   94 | running test class org.apache.karaf.itests.JavaSecurityTest
2025-09-28 11:40:59,737 | INFO  | iner.internal.KarafTestContainer  161 | Creating RMI registry server on 127.0.0.1:51866
2025-09-28 11:41:00,105 | INFO  | iner.internal.KarafTestContainer  255 | Found 0 options when requesting OverrideJUnitBundlesOption.class
2025-09-28 11:41:00,108 | WARN  | iner.internal.KarafTestContainer  442 | you're trying to add an additional value to a config file; you're current value will be replaced.
2025-09-28 11:41:00,108 | WARN  | iner.internal.KarafTestContainer  442 | you're trying to add an additional value to a config file; you're current value will be replaced.
2025-09-28 11:41:00,115 | INFO  | iner.internal.KarafTestContainer  308 | Wait for test container to finish its initialization [ RelativeTimeout value = 3600000 ]
2025-09-28 11:41:00,116 | INFO  | rn.RemoteBundleContextClientImpl  241 | Waiting for remote bundle context.. on 51866 name: e3e7a2d1-62c3-47d7-b5cf-c963244f3925 timout: [ RelativeTimeout value = 3600000 ]
The Security Manager is deprecated and will be removed in a future release

@mattrpav
Copy link
Contributor Author

w00t! I set the JavaSecurityTest to @ignore and everything else passed! If we can solve for the JavaSecurityTest the change set is ready for merge.

@mattrpav mattrpav self-assigned this Sep 29, 2025
@holgerfriedrich
Copy link
Contributor

Commenting out the 2 tollowing lines in JavaSecurityTest.java will make it pass:

editConfigurationFilePut("etc/system.properties", "org.osgi.framework.security", "osgi"), and
assertNotNull("Karaf should run under a security manager", System.getSecurityManager());

If not removed, the first line prevents the startup of the container. Looking at the spec for the property show above, it refers to the SecurityManager again.

I am not sure if removing those two lines renders the whole test case useless.
Fact is that SecurityManager is scheduled for removal.

@jbonofre any recommendation?

@mattrpav
Copy link
Contributor Author

mattrpav commented Sep 30, 2025

@holgerfriedrich that is a good point. We may need to make a ticket to re-enable some sort of security test and also check in w Apache Felix on what the plans are for OSGi security now that the SecurityManager is going away.

I’m suggesting this plan:

  1. Keep this test ignored
  2. Make a ticket to track a new security test pending Felix notes
  3. Merge this PR in 4.5.x
  4. Finish JAAS API conversion

@jbonofre you good with this plan?

@jbonofre
Copy link
Member

jbonofre commented Oct 1, 2025

It sounds reasonable to me. I would just suggest to create the ticket now and add link to the ticket in the @ignore message.

@holgerfriedrich
Copy link
Contributor

holgerfriedrich commented Oct 1, 2025

@jbonofre @mattrpav I created a draft of the ticket #2082, please feel free to update the text.

@jbonofre
Copy link
Member

jbonofre commented Oct 1, 2025

@mattrpav we can use @ignore("here my comment with github issue")

@mattrpav
Copy link
Contributor Author

mattrpav commented Oct 1, 2025

@mattrpav we can use @ignore("here my comment with github issue")

@jbonofre Yes =) Your comment was faster than my push ;-)

see JavaSecurityTest.java

@mattrpav
Copy link
Contributor Author

mattrpav commented Oct 1, 2025

Ok.. so one idea is to use MRJ and have a separate JaasHelper class that is JDK 21+. The catch would be that we'd have to convert a bunch of classes to use JaasHelper everywhere as the facade to JAAS API.

If this works, we may be able to preserve JDK 17 compatibility with Karaf 4.5.0

Specifically these would need to be updated: https://github.com/search?q=repo%3Aapache%2Fkaraf%20AccessController&type=code

edit: I think this might be more work that it is worth and confusing for ppl that write custom adapters that use the JAAS API. I don't know of any frameworks that are baseline JDK 17, but have a problem with JDK 21. I think base lining Karaf v4.5.0 to JDK 21 should be ok.

If everyone is good, we should merge this PR and then I can start on the JAAS API changes -- or do we want the JAAS API changes on the same PR (separate commits)?

@holgerfriedrich
Copy link
Contributor

Merging this PR would be highly appreciated.
This gives a clean baseline to implement the Jaas changes on top of the new API available only in Java 21.

@holgerfriedrich
Copy link
Contributor

Hi, is there already a decision how to proceed?
I would appreciate a lot if I could get Karaf to work with JDK25.
Is there something I could help with?

@jbonofre
Copy link
Member

@holgerfriedrich changes have been made already on the main branch (for instance main has been already updated to JDK17, whereas karaf-4.4.x is still JDK11).

The purpose is to have JDK21+ min for Karaf 4.5.x (4.4.x stays as it is). Karaf 4.4.9 is coming (I'm finalizing the prep). 4.5.0 will follow.

I will rebase/resume this PR (and others).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants