Hi,

Karaf 5 is a separate discussion, not related to JDK support.

What we agreed is to keep maintaining and improving Karaf 4.x (OSGi
powered, equivalent to what we have today), including JDK support.

Karaf 4.5, 4.6, 4.7, etc will be released with new JDK support and
improvements. Karaf 5 is dedicated to a deeper refactoring, and still
under discussion.

So, let's focus on Karaf 4.5 with JDK24+ support (and work with
dependencies that need to be improved).

Regards
JB

On Thu, Aug 28, 2025 at 9:06 PM ecki <[email protected]> wrote:
>
> (Ah I just noticed the explanation, yes 5.x based on current Karaf Code base 
> is also fine with me instead of 4.5, as long as it is compatible and 
> available on Short term. And I agree with the Sentiments it would be better 
> SemVer but as I just witnessed its confusing with previous plans :)
>
> Gruß,
> Bernd
> --
> https://bernd.eckenfels.net
> ________________________________
> Von: ecki <[email protected]>
> Gesendet: Donnerstag, August 28, 2025 8:58 PM
> An: [email protected] <[email protected]>
> Betreff: Re: Karaf 4.4.8 and JDK24
>
> Please do t the this to Karaf 5, we want to use 25 at the end of the year but 
> Not Karaf 5. I find JBs idea with 4.5 as the cut-over much better. I mean yes 
> you can also do it in 5.. if that is a thing.
>
> Gruß,
> Bernd
> --
> https://bernd.eckenfels.net
> ________________________________
> Von: Matt Pavlovich <[email protected]>
> Gesendet: Donnerstag, August 28, 2025 7:14 PM
> An: [email protected] <[email protected]>
> Betreff: Re: Karaf 4.4.8 and JDK24
>
> Maybe— but there is a downstream compatibility issue. Anyone implementing a 
> security check needs to use one JAAS API or the other. The combination matrix 
> is too complicated, b/c you can do both API approaches in JDK 21, but not JDK 
> 17 or JDK 25.  It would create a maint/support nightmare for Karaf 
> contributors and provide little to no value to users.
>
> I believe a hard cut and a single path forward is better for users— that is 
> why I am suggesting this change goes into a Karaf v5.0.0 instead of v4.5.0.
>
> Matt Pavlovich
>
> On Aug 28, 2025, at 11:50 AM, Jérémie <[email protected]> wrote:
>
> Thanks for your answer. As it was mentioned in the release note, I thought it 
> was solved.
>
> Can't multi-release jar be used to solve this kind of compatibility issue ?
>
> joi, 28 aug. 2025, 18:32 Matt Pavlovich <[email protected]> a scris:
>
> Hello Jeremie-
>
> You are running into the JDK breaking change of API changes to the JAAS API.
>
> The JDK did not provide compatible back porting of the JAAS API changes, so 
> there will need to be a hard line in Karaf JDK support across releases for 
> the new JAAS API and JDK 24+ support.
>
> see: https://issues.apache.org/jira/browse/KARAF-7977
>
> I have a proposal on karaf dev mailing list discussing about how to move 
> forward.
>
> Currently, discussing the following options:
>
> karaf-4.4.x - JDK 11 to JDK 21
> karaf-4.5.x - JDK 21 to JDK 25
> karaf-5.x - (based on Minho or other next-gen)
>
> - or -
>
> karaf-4.x - JDK 11 to JDK 21
> karaf-5.x - (based on karaf-4.x) JDK 21 to JDK 25
> karaf-6.x - (based on Minho or other next-gen)
>
> Option #2 has better alignment with SEMVER, but doesn’t align with previously 
> discussed roadmap, so nothing is formalized yet.
>
> Thanks,
> Matt Pavlovich
>
> On Aug 28, 2025, at 2:27 AM, Jérémie <[email protected]> wrote:
>
> Hello all,
>
> And thanks a lot for the v4.4.8 release. I upgraded my system to this version 
> and everything worked as expected.
>
> However, I'd like to test the compatibility with JDK24, as I saw in the 
> release note, but my pax-exam integration tests failed because of a JAAS 
> issue in Felix EventAdmin. Is there something wrong with my packaging, or 
> something expected ?
> The stack trace below.
>
> Regards,
> Jérémie
>
> org.apache.karaf.services.eventadmin [Events.Framework] ERROR : 
> FrameworkEvent ERROR
> java.lang.UnsupportedOperationException: getSubject is not supported
> at java.base/javax.security.auth.Subject.getSubject(Subject.java:277)
> at 
> org.apache.felix.eventadmin.impl.handler.EventAdminImpl.prepareEvent(EventAdminImpl.java:146)
> at 
> org.apache.felix.eventadmin.impl.handler.EventAdminImpl.postEvent(EventAdminImpl.java:180)
> at 
> org.apache.felix.eventadmin.impl.adapter.BundleEventAdapter.bundleChanged(BundleEventAdapter.java:121)
> at 
> org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:949)
> at 
> org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:234)
> at 
> org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:151)
> at 
> org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEventPrivileged(EquinoxEventPublisher.java:229)
> at 
> org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:138)
> at 
> org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:130)
> at 
> org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor.publishModuleEvent(EquinoxContainerAdaptor.java:217)
> at org.eclipse.osgi.container.Module.publishEvent(Module.java:499)
> at org.eclipse.osgi.container.Module.doStop(Module.java:658)
> at org.eclipse.osgi.container.Module.stop(Module.java:521)
> at 
> org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.decStartLevel(ModuleContainer.java:1888)
> at 
> org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1763)
> at org.eclipse.osgi.container.SystemModule.stopWorker(SystemModule.java:275)
> at 
> org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle$EquinoxSystemModule.stopWorker(EquinoxBundle.java:208)
> at org.eclipse.osgi.container.Module.doStop(Module.java:660)
> at org.eclipse.osgi.container.Module.stop(Module.java:521)
> at org.eclipse.osgi.container.SystemModule.stop(SystemModule.java:207)
> at 
> org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle$EquinoxSystemModule$1.run(EquinoxBundle.java:226)
> at java.base/java.lang.Thread.run(Thread.java:1447)
>
>
>

Reply via email to