Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] Discussion on moving the JSR107 specification (JCache) to JakartaEE


You're right and while the rebirth of the much smaller Dependency Injection JSR in Jakarta EE showed, it could be migrated to Jakarta EE even if the original Spec Leads are not interested or willing to help, there are multiple stakeholders including Oracle, Greg Luck and Hazelcast as well as a few others that do not exist under those names anymore.

If you really wanted something Enterprise and Cloud-worthy then you'd have to take the few bits and pieces or general ideas behind JSR 347:, even that filed over 10 years ago, and not the "archeological" 107 that was filed another decade earlier.


On Thu, Jan 20, 2022 at 2:55 PM Ondrej Mihályi <ondrej.mihalyi@xxxxxxxxxxx> wrote:
I'd also like to see JCache in Jakarta EE. Payara provides JCache out of the box and we at Payara are strongly in favor of adding it to Jakarta EE. But, after all those years of discussions, my opinion is that it's better and probably also easier to create a new Jakarta Cache specification inspired by the existing JCache specification, for the following reasons:
  • Oracle would need to agree and transfer the IP to Eclipse Foundation, which might be a very lengthy process with uncertain results
  • JCache wasn't created with Java EE in mind. It doesn't make it clear how some things should work in containers, when the API is provided by the container but consumed by deployed applications, especially in a distributed system. In Payara, we had some issues with that and had to introduce some classloader enhancements to fix those issues.
  • All those things Reza mentioned are not addressed: CDI integration, transactions, asynchronous API (not necessarily reactive)
  • It's a very old specification (1.0 version was released in 2014, the work on JCache started even much earlier, in 2001). The API doesn't meet today's standards in many cases and could be simplified.
  • even if JCache is donated to Jakarta EE, it would have to use the jakarta.* package prefix, which is a breaking change. This gives us a unique opportunity to introduce other breaking changes. Applications that already depend on JCache 1.0 can continue using that API because it wouln't conflict with the new API with the jakarta.* prefix.
One of the reasons why JCache hasn't been added to Java EE was that it just wasn't ready for Java EE, it was created only with Java SE in mind. Although section 1.5 mentions "The Java Caching API is designed to be suitable for use by applications using the Standard and Enterprise Editions, versions 6 or newer." it also mentions that "[JCache implementations] may support its use by applications using Java EE, however this specification does not specify any standard for how that may be done."

Of course, the effort to create a new specification is much greater than to just copy the existing specification. It all depends on whether there's somebody to lead the effort. But even if Oracle donates JCache, I doubt they would be interested in leading the specification, so we would need somebody else to lead it anyway.

Kind regards,

Ondrej Mihályi

Senior Payara Service Engineer
Payara - Supported Enterprise Software for Jakarta EE and MicroProfile Applications
US: +1 415 523 0175 | UK: +44 207 754 0481


Payara is a proud recipient of the prestigious Queen's Award for Enterprise: International Trade 2021

Payara-Tech LDA, Registered Office: Rua Nova de São Pedro no. 54, 2nd floor, room “D”, 9000 048 Funchal, Ilha da Madeira, Portugal

VAT: PT 515158674 | | info@xxxxxxxxxxx | @Payara_Fish

From: <> on behalf of Reza Rahman <reza_rahman@xxxxxxxxx>
Sent: 20 January 2022 01:51
To: Jakarta EE community discussions <>
Subject: Re: [] Discussion on moving the JSR107 specification (JCache) to JakartaEE


I think there is important context to be added here. Including JCache into Java/Jakarta EE is a discussion that has been active for a very long time. This is so much so, that it wound up as a key question in the Java EE 8 survey: A consistently large number of Java/Jakarta EE developers have expressed interest in this (almost 70% of developers in the survey - see attached). I think we all know the reasons why it didn't happen in Java EE 8 despite these results.

The primary drivers to include JCache I think remain relevant even today:

* A large number of enterprise applications use the technology to boost performance in mission critical applications.

* The application state cache (HTTP sessions, etc) can be offloaded to JCache implementations in the way runtimes like Open Liberty do today:

* The JPA second level cache can be offloaded to JCache implementations.

* Yes, it's all relevant for microservices and the cloud to reduce network latency in a highly distributed system. This is why we have things Azure Redis Cache:

In addition I think there are the following drivers:

* Bette JCache integration with CDI.

* Bette JCache integration with JTA/JCA.

* Evolving JCache to incorporate reactive concepts (though I would think about standardizing this after seeing how Loom plays out).

Other than the IP and code transfer, I think this is an easy win for Jakarta EE that does not really involve heavy investment. Most of the work I think is basically already done here and there such as by the Payara folks: and the Data Grid JSR.


Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

On 1/19/2022 11:05 AM, 泠 恒谦 wrote:
Hi friends of the community.

In the original github repository for JSR107, , which is related to the javax namespace, the issue  ( )discusses whether The JSR107 (JCache) specification should be migrated to Jakarta EE, I noticed that there doesn't seem to be such a discussion on our mailing list, so I opened this thread.

In the same timeline, in the discussion of possible candidates for the Jakarta EE 10 specification, the relevant link is , there is also a migration discussion for JCache.

I hope some friends will pay attention to this topic, maybe the migration problem is related to Oracle’s legal approval

Finally, I would like to thank Tanja Obradovic for the invitation.

_______________________________________________ mailing list
To unsubscribe from this list, visit
_______________________________________________ mailing list
To unsubscribe from this list, visit

Back to the top