apologies for beeing too strict on it - yes, one can still compile it with jdk 25 but is will be removed not long in future; I already had some strict compile rules set, forgot to mention this.
I've also seen that the jcr api can't be changed easily it seems - and since it also has parts and bits that OAK doesnt relly allow yet (e.g.: workspace management / multiple ones) I wonder what the future direction of this will be then? ----- Ursprüngliche Mail ----- > Von: "Konrad Windszus" > An: "users" <[email protected]> > Gesendet: Freitag, 16. Januar 2026 20:15:42 > Betreff: Re: [Question] JCR API compatibility with Java 24 (JEP 486) - > Removal of AccessControlException in Session > interface > Hi Korbinian, > What makes you think that > >> AccessControlException no longer exists in the JDK starting with version 24, >> code compiling against the standard javax.jcr dependency fails. > > I still see > https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/security/AccessControlException.html, > so it is deprecated but still there even in Java 25. > Same for Java 26: > https://download.java.net/java/early_access/jdk26/docs/api/java.base/java/security/AccessControlException.html. > > Konrad > >> On 16. Jan 2026, at 11:21, Korbinian Bachl >> wrote: >> >> Hi everyone, >> >> I am currently looking into building/running our application with the >> upcoming >> Java 24 (and later Java 25), and I encountered a compatibility issue >> regarding >> the JCR API (javax.jcr). >> >> The Issue: With JEP 486 (Permanently Disable the Security Manager), Java 24 >> has >> removed several security-related classes, including >> java.security.AccessControlException. >> >> However, the javax.jcr.Session interface declares this exception in its >> method >> signatures, for example: >> Java >> >> public void checkPermission(String absPath, String actions) throws >> AccessControlException, RepositoryException; >> >> Since AccessControlException no longer exists in the JDK starting with >> version >> 24, code compiling against the standard javax.jcr dependency fails. >> >> My Question: Are there any plans to release an updated version of the JCR API >> (perhaps a Jakarta or revised javax artifact) that removes this exception >> from >> the method signatures or replaces it with java.lang.SecurityException? >> >> How should projects currently relying on Jackrabbit and the standard JCR API >> proceed if they want to support Java 24+? >> >> Thanks for your help! >> >> Best, >> >> Korbinian
