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.
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:
https://javaee.github.io/javaee-spec/download/JavaEE8_Community_Survey_Results.pdf. 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:
https://docs.payara.fish/enterprise/docs/documentation/payara-server/jcache/jcache.html and the Data Grid JSR.
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.
JSR107 (JCache) About. JCache is the Java caching API. It was defined by JSR107. It defines a standard Java Caching API for use by developers and a standard SPI ("Service Provider Interface") for use by implementers.
The mandatory requirement is of course that it must first migrate to the new namespace. Whether they want to do that or not depends entirely on the Maintenance Leads @gregrluck and Oracle. After its MR2 I guess May 2019
there has been absolutely no activity, so between JCrete (also 2019) when Greg and I briefly spoke about it and now there was no activity not even fixing any bugs or merging PRs.
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.
jakarta.ee-community mailing list
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community