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.
