JCache + JavaEE / JCache 2.0 BOF at Java One

[Jens Wilke]

Hello Everyone,

Steve Millidge posted this in the JavaEE slack:

> I'm submitting a proposal for a JCache JavaEE BOF for JavaOne. I think I have a co-speaker
> from Hazelcast. I'm interested in adding to the proposal likely panel members. Reply if you
> are interested and are planning to attend J1

I replied:

> Good idea! I thought a little about it the last couple of days. Suggestion: Change the
> title/scope to "JCache 2.0 + JavaEE BOF". For two reasons: Most of the things needed for
> the smooth JavaEE integration, affect the general APIs and concepts. Secondly, Java 8 alignment
> is to be done and non-EE consumers need that also.

> In short: I am very sure that a "JCache + JavaEE" JSR will actually end up to be something
> like JCache 2.0.

Any thoughts?

Cheers,

Jens

--
"Everything superfluous is wrong!"

// Jens Wilke - headissue GmbH - Germany
\// https://headissue.com

[Jens Wilke]

On Wednesday 11 May 2016 13:01:10 Jens Wilke wrote:
> Hello Everyone,
>
> Steve Millidge posted this in the JavaEE slack:
>
> > I'm submitting a proposal for a JCache JavaEE BOF for JavaOne. I think I have a co-speaker
> > from Hazelcast. I'm interested in adding to the proposal likely panel members. Reply if you
> > are interested and are planning to attend J1
>
> I replied:
>
> > Good idea! I thought a little about it the last couple of days. Suggestion: Change the
> > title/scope to "JCache 2.0 + JavaEE BOF". For two reasons: Most of the things needed for
> > the smooth JavaEE integration, affect the general APIs and concepts. Secondly, Java 8 alignment
> > is to be done and non-EE consumers need that also.
>
> > In short: I am very sure that a "JCache + JavaEE" JSR will actually end up to be something
> > like JCache 2.0.
>
> Any thoughts?

The feedback in Slack was so far:

smillidge [1:23 PM]
> I thought the consensus was around a JavaEE JCache bridge spec as JCache 2 there was not much appetite for?

johan [1:24 PM]
> It seems already more than enough work to get the Java EE JCache bridge, so my opinion is to wait working on JCache 2 until at least the EE bridge is done.

smillidge [1:25 PM]
> My feeling is that many of the core JCache vendors aren't too interested in JavaEE so it is easier to do a bridge
> JCache is a SE spec with some CDI annotations, among other DI framework integrations

reza_rahman [1:35 PM]
> I agree there is very little possibility the current JCache leads would be interested in any significant EE integration. I would ask just one more time out of courtesy and then move forward independently.

jeans [1:40 PM]
> Thanks for the response! My line of thinking: It depends what the scope of 2.0 should be. 2.0 could have lots of new stuff, or it can correct the issues we have with 1.0, which we cannot correct in a compatible way inside a MR. As soon as you do things for Java 8, it is logically a 2.0, isn't it? (edited)

smillidge [2:29 PM]
> I'm not saying there shouldn't be a JCache 2.0 just that there should be a separate JSR to get JCache into JavaEE 8.

jeans [3:26 PM]
> Separate JSRs make sense in general! Don't make the scope to broad and move faster. What I am trying to say is, that there can be a separate JSR, but it cannot specify things different then JSR107 and it should not specify general things that every JCache should have. I looked into all the details what was done so far for the EE integration and the majority of things that popped up need to be fixed in a JSR107 MR, if that is possible, or, they are of relevance outside EE as well and don't depend on the EE infrastructure (for example the configuration in the prototype).

smillidge [3:48 PM]
> possibly, it probably needs discussing at JavaOne hence the BOF submission. I don't know if there is another submission for a JCache 2.0 BOF. I can update the title since the CFP has been extended