JCache.next (JavaEE alignment)

[Ondrej Mihályi]

Hi,

We had the JCache + Java EE BOF at JavaOne, with Hazelcast, Payara and Tomitribe there, where we discussed what is missing in JCache to align it with Java EE. The discussion suggested that there are three groups of issues:

 - necessary improvements to align with Java EE (we need them to bring JCache into Java EE)
 - optional improvements (CDI cache scope, asynchronous API, injection of Cache and CacheManager) - seems that Payara and Tomitribe already put some effort on their own, and would welcome a standard approach
 - integration with other specs (JPA 2nd level cache, caching JPA queries, facelet cache in JSF, JTA to span transaction over both cache and database, ...) - JCache should provide means to do it, but first JCache needs to be officially included in Java EE scope

At least one of the 3 current spec leads, Greg Luck, is very interested in this effort, we should be hearing from him soon.

Meantime, I wanted to raise a discussion about JCache 1.1, which I suggest would target inclusion in Java EE.
Do we need to form a new EG or can we continue with the same EG as in JSR107?
There are already new subjects interested in joining the EG (https://github.com/Adopt-a-JSR/jcache-javaee/issues/3#issuecomment-248216328).


Ondrej Mihályi,
Payara Services

[Tristan Tarrant]

On Thursday, September 22, 2016 at 5:16:42 PM UTC+2, Ondrej Mihályi wrote:

 - necessary improvements to align with Java EE (we need them to bring JCache into Java EE)

I guess we need to at the very least:
- define where container-created caches/managers are placed in JNDI so that they can be injected in applications. Because these caches could be shared among deployments, we need to think about ClassLoader issues.
- define a way for a deployment to specify the caches it wants created within its lifeycle. For example JPA uses persistence.xml, CDI uses beans.xml. JCache doesn't (yet) specify a standard declarative format.
 

 - optional improvements (CDI cache scope, asynchronous API, injection of Cache and CacheManager) - seems that Payara and Tomitribe already put some effort on their own, and would welcome a standard approach

WildFly also has already implemented this for Infinispan-specific caches.
As for the Async API, we should retarget JCache to Java 8 so that we can use CompletionStage/CompletableFuture instead of coming up with our own non-standard API.
 

 - integration with other specs (JPA 2nd level cache, caching JPA queries, facelet cache in JSF, JTA to span transaction over both cache and database, ...) - JCache should provide means to do it, but first JCache needs to be officially included in Java EE scope

Some of these will require changes on the other specs (JPA already has knowledge of caching, but it needs a standard way to specify the caches to use). Supporting JTA would be a task just for JCache.
 

At least one of the 3 current spec leads, Greg Luck, is very interested in this effort, we should be hearing from him soon.

Meantime, I wanted to raise a discussion about JCache 1.1, which I suggest would target inclusion in Java EE.
Do we need to form a new EG or can we continue with the same EG as in JSR107?
There are already new subjects interested in joining the EG (https://github.com/Adopt-a-JSR/jcache-javaee/issues/3#issuecomment-248216328).

I believe this is a question that should be answered by the JCP committee.

Tristan

[Werner Keil]

Tristan,

I think you summarized this quite well, thanks for that.
The JCP Executive Committee asked Linda (Java EE Spec Lead) about this in the F2F (Hazelcast was represented, not by Greg but his alternate) and you'll see her remarks on that in the minutes soon.

Just very briefly condensed it sounded like "if JCache was fit for Java EE it could be included" but looking at the rather aggressive Java EE 8 timeline, I would not expect that to happen before Java EE 9 IMHO.
JTA support is just one, but certainly an important goal JCache 1.0 missed out on. Better integrating with standardized configuration (as of the new Config JSR) instead of reinventing its own configuration sub-system would be another aspect to tackle, but the Config JSR also aims at that for EE 9 mostly.

Regards,
Werner