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: https://jcp.org/en/jsr/detail?id=347, even that filed over 10 years ago, and not the "archeological" 107 that was filed another decade earlier.
Werner
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
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 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:
https://azure.microsoft.com/en-us/services/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).
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,
https://github.com/jsr107/jsr107spec , which is related to the javax namespace, the issue (
https://github.com/jsr107/jsr107spec/issues/415 )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.
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.