removal of AccessControlException vs javax.jcr

[Julian Reschke]

Am 24.01.2026 um 09:44 schrieb Alan Bateman:
> 
> 
> On 23/01/2026 19:00, Julian Reschke wrote:
>> Am 23.01.2026 um 19:00 schrieb Sean Mullan:
>>> It hasn't been removed yet, but the plan is to eventually remove it. 
>>> Why is it frozen? Depending on a library or project that isn't active 
>>> or cannot be adapted seems a bit concerning.
>>> ...
>>
>> It's a Javax API. The only way to change/revise/update it would be a 
>> new JSR xxx Expert Group, unless I'm missing something.
> 
> I don't know anything about this Content Repository API but I agree with 
> Sean that it is a bit concerning to be dependent on something that might 
> no longer be maintained. I see the last update to the API was 2009 but I 

Well. It mainly wasn't updated because there was no urge.

> can't tell if this is one of these APIs with multiple implementations 
> maintained by different projects. Do you know if anyone has been 

There are two implementations in Apache space. Jackrabbit is the 
reference implementation. Oak is a re-implementation (complete). These 
are used in other Apache projects (like Sling), and in commercial 
projects such as Magnolia or Adobe AEM (used by many Fortune 500 
companies). ((Excuse the marketing spin; I'm an Adobe contractor but 
still mostly developing in Open Source space)). There are also 
*implementations* elsewhere but I don't know whether they are still in use.

It's also used (or was used) in Oracle's DB products; see 
<https://www.orafaq.com/wiki/JCR>. See also 
<https://en.wikipedia.org/wiki/Content_repository_API_for_Java#Available_implementations>.

Note <https://www.linkedin.com/in/eric-sedlar-160752/> was EG member, 
you may want to talk to him.

So the API in itself is not a big success story, but it has a huge 
number of deployments.

> maintaining an implementation has tested it on JDK 7 or newer? As the 

It is maintained and happily compiling and running on JDK 25 
(https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk-java25/ 
- ignore test flakiness),

> API was developed in the JCP then it may be that it needs a maintenance 
> JSR to update. This assumes of course that it is still relevant and 
> intended to work with modern JDK releases.

Starting a new EG is quite an expensive thing when the only issue at 
hand is a deprecated Exception in a method signature.

Best regards, Julian

PS: Sean, you may remember: many years ago you delayed a part of the 
java.security removal to help "us" (Apache) to transition away (again, 
it was an issue of use in method signatures). Thanks for that.