JavaOne JCache BOF Discussion Seeding

[Chris Dennis]

Hi All,

As many of you may recall, in order to help bootstrap and guide the
initial work on JCache 2.0, I proposed (and was accepted for) a BOF
session at JavaOne entitled "JCache 2.0: Where Do We Go From Here?”.
Given that this is a BOF session, I don’t want to overly structure the
discussion but I do want to set the stage a little. What I’d like to do
is informally gather peoples thoughts/ideas on what Jcache 2.0 could be so
that we have the raw materials from which a lively discussion can be built.

As I see it there are three different kinds of change that we could make
in JCache 2.0. Firstly, and most obviously there are the broken parts of
JSR-107 that require backwards compatibility breaking changes to fix them.
This set may be empty, or may not, but it is something that needs to be
determined before we make plans for additional changes (imho). The two
further kinds of changes are to some extent mutually exclusive, we have
two choices regarding how JCache 2.0 proceed, and those choices depend
largely on how one perceives JSR-107:

Thematic Expansion: Here we consider the existing JSR-107 API to be a
completed task, and then expand it’s scope to form a greater API that
encompasses additional use-cases that were out of scope for the original
spec.

Functional Completion: Here we consider the existing JSR-107 API to be an
incomplete portion of some larger API that we strive to reach in JCache
2.0.

I assume the list of perceived broken aspects of JSR-107 is captured in
the Github issues. We can draw from there for that discussion (obviously
file additional issues if you think further things are broken). What I’m
more interested in at the moment are peoples opinions on what direction
JCache 2.0 should be moving in. What usecases are not supported by
JSR-107 that should be supported in a future JCache JSR, and what features
would be required to support those usecases? I’d also like people to hold
discussion of any proposals for the session itself if at all possible.
Discussion will obviously continue beyond the session on the mailing list
and elsewhere, but I’d like to keep the barrier to entry as low as
possible for newcomers by avoiding having too much discussion in advance.

Thanks,

Chris Dennis

[Steve Millidge]

One obvious thing is JCache integration and alignment with JavaEE 8. It is down to be included but in its current form it needs some additional work on the api which would be ideal for JCache 2.0.

For example in Payara Server we incorporate JCache both api and CDI. However we have added our own custom extensions for injecting a named Cache and injecting a CacheManager as well as the ability to bind a cache into JNDI etc. etc.

If I remember rightly JTA integration was not fully specced (could be wrong).

I also have a bunch of minor api expansions and gripes having used it in anger.

--
You received this message because you are subscribed to the Google Groups "jsr107" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jsr107+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Chris Dennis]

Thanks Steve,

Yes, JavaEE 8 integration definitely should be right near the top of the
list of priorities for 2.0. There will obviously be technical and
logistical challenges with that given the fact that we would have two JSRs
both with fluid timelines, but I hope it’s something that we could all
uniformly agree on at least being desirable. Depending on the scope of
the changes required it may even make sense as the only goal of 2.0. I’ll
stop now before I break my own rules on pre-BOF discussion though.

My memory of the transactions story is that it was initially partially
specified, then became optional, and then was dropped for expediency.
It’s definitely a feature that could be re-discussed, especially in light
of how close it came to making it in to 107.


Chris

On 9/30/15, 6:46 AM, "Steve Millidge" <jsr...@googlegroups.com on behalf

[Noctarius]

Hey guys,

From talking with people over the last months:

- JavaEE 8 integration (not as much requested as you might think,
still requested)
- Transaction support
- Asnyc operations
- SLA support, (in conjunction with sync/async) give max timeout to
get operations and if timeout is reached either return default value
or fire up a fallover operation (like second cluster or something)

Not sure though the last one makes sense with that little explanation :)

Cheers,
Chris

[Chris Dennis]

I would add to that list:

- Capacity Control (at least simplistic)
- Configuration Via External Resource (e.g. XML, YAML, JSON, etc...)

One observation I would make is that the vast majority of caching users
out there are using standalone in-memory (usually in-heap) caches. The
lack of capacity control for even simple in-heap caches, and the lack of
an implementation independent way to express configuration in an external
resource seems like a big handicap to these people.

Chris

On 9/30/15, 9:52 AM, "'Noctarius' via jsr107" <jsr...@googlegroups.com>
wrote: