You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Korbinian Bachl <ko...@whiskyworld.de> on 2026/01/16 10:21:25 UTC
[Question] JCR API compatibility with Java 24 (JEP 486) - Removal of AccessControlException in Session interface
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
Re: [Question] JCR API compatibility with Java 24 (JEP 486) - Removal of AccessControlException in Session interface
Posted by Julian Reschke <ju...@gmx.de>.
...and I only saw Konrad's reply just now.
So yes, it's deprecated (for removal) but not removed yet.
What we can try to do is prevent removal - so we'll need to engage with
the JDK development team.
Best regards, Julian
Re: [Question] JCR API compatibility with Java 24 (JEP 486) - Removal of AccessControlException in Session interface
Posted by Julian Reschke <ju...@gmx.de>.
...and I only saw Konrad's reply just now.
So yes, it's deprecated (for removal) but not removed yet.
What we can try to do is prevent removal - so we'll need to engage with
the JDK development team.
Best regards, Julian
Re: [Question] JCR API compatibility with Java 24 (JEP 486) - Removal of AccessControlException in Session interface
Posted by Julian Reschke <ju...@gmx.de>.
Am 16.01.2026 um 11:21 schrieb Korbinian Bachl:
> 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.
> ...
Thanks for checking! Do you have an Apache JIRA account so we can move
this into a ticket?
> 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?
> ...
Both options are bad.
1. We can't touch the JCR API, as javax.jcr is owned by Oracle. Only a
new Expert Group can revise it.
2. javax.jcr is not part of the APIs that *can* move to Jakarta (as not
in EE)
In theory we could (?) fork javax.jcr; but that would imply a new
package name as well. This is the somewhat "nuclear" option as any code
that uses javax.jcr would need to be updated.
> How should projects currently relying on Jackrabbit and the standard JCR API proceed if they want to support Java 24+?
No idea. For now we need to document this issue.
> Thanks for your help!
>
> Best,
>
> Korbinian
Best regards, Julian
Re: [Question] JCR API compatibility with Java 24 (JEP 486) - Removal of AccessControlException in Session interface
Posted by Korbinian Bachl <ko...@whiskyworld.de>.
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" <us...@jackrabbit.apache.org>
> 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
Re: [Question] JCR API compatibility with Java 24 (JEP 486) - Removal of AccessControlException in Session interface
Posted by Konrad Windszus <kw...@apache.org>.
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 <ko...@whiskyworld.de> 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
>
Re: [Question] JCR API compatibility with Java 24 (JEP 486) - Removal of AccessControlException in Session interface
Posted by Julian Reschke <ju...@gmx.de>.
Am 16.01.2026 um 11:21 schrieb Korbinian Bachl:
> 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.
> ...
Thanks for checking! Do you have an Apache JIRA account so we can move
this into a ticket?
> 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?
> ...
Both options are bad.
1. We can't touch the JCR API, as javax.jcr is owned by Oracle. Only a
new Expert Group can revise it.
2. javax.jcr is not part of the APIs that *can* move to Jakarta (as not
in EE)
In theory we could (?) fork javax.jcr; but that would imply a new
package name as well. This is the somewhat "nuclear" option as any code
that uses javax.jcr would need to be updated.
> How should projects currently relying on Jackrabbit and the standard JCR API proceed if they want to support Java 24+?
No idea. For now we need to document this issue.
> Thanks for your help!
>
> Best,
>
> Korbinian
Best regards, Julian