Discussions

Brian Repko has posted "Caching for JDK 7," a post about the dormant state of JSR-107, the JCache specification. There are a number of programmatic caches out there, he says, but there should be a standard.
He mentions a sort of commons-cache project as a possibility:

I've often longed for a "commons-caching" - a standard client library that could be implemented underneath by the JDK LinkedHashMap, OpenSymphony OSCache, Hibernate ehcache, WhirlyCache and I think there are some others (Turbine's JCS?). This is really not hard (and I've done two of those under a common framework for a client).

One assumes he's not referring to the dormant commons-caching project on Jakarta.
Cameron Purdy, spec lead for JSR-107 (and proponent of his own caching product, Coherence, recently purchased by Oracle), cited a lack of time and need as a reason for the JSR's inactivity (although it does have a draft posted on java.net), and the comments on Brian's blog entry might be a good start toward defining a more current specification. Anyone interested in helping Brian or the java.net project revive the specification?

While Purdy may have experience with caching and therefore qualify as spec lead this sounds pretty strange to me.
He says 'lack [...] of need' is the reason for the dormant state.
On the other hand he spent his time developing Coherence which does the same so why would he do this if there's no need? Apparently Oracle thinks too that there exists some need because they bought Coherence. Why do Ehcache, Treecache, JGroups, OSCache, ... exist if there's no need?
Aren't all clusters of whatever kind in need of caching?
To me it sounds like drowning a possible rival before he can get out of the water so perhaps Purdy isn't the right one to lead this spec!

Sure there's a difference but with a good spec applications could use the specs API and therefore weren't locked in with a certain implementation as long as they don't use some special features of the implementation (e.g. do I use pure JPA or some special TopLink feature).
Following your logic JPA is superfluous because we already had Hibernate, TopLink, ... ;-)
Therefore I think there is need for a good spec because one could switch implementations depending on ones preferences which would be priceless IMHO!

Brandon,
Your conspiracy theories are a bit over the top; the truth is a lot simpler: There are a lot more people who want to be involved with writing a reference implementation (e.g. prototyping with code) than there are people who want to write the specification and the requisite set of tests.
Having sunk a massive amount of my personal time and effort into JSR107, I can tell you that it has been a lot harder than I imagined to produce the end result, particularly with a day job and without consistent help. At the same time, as the spec lead it is my fault and my responsibility, and I do plan to push through to completion.
As you can imagine, I have been a bit consumed these last several months, but I recently started working on the specification again. Greg (ehcache) is also active, and has been working on validating some of the prototyped interfaces (which unfortunately do not correspond directly to the spec). Here's some of his feedback:
http://ehcache.sourceforge.net/documentation/jsr107.html
Regarding the "lack of need" quote, I have no idea where that came from. I have never thought that, and I certainly never claimed it. Also, with a dozen working open source cache solutions in the caching space, the thought of "drowning a rival" is completely laughable.
Peace,
Cameron Purdy
Tangosol Coherence: The Java Data Grid

I hear that Glassfish is coming out with enterprise features, in terms of app fail-over, and I have even heard some employee throw around the term "5 9's" which seemed to me had to include the Clustra functionality, but it doesn't according to this thread:
http://blogs.sun.com/theaquarium/entry/in-memory_replication_in_glassfish_v2
Cameron, I feel like you have a big opportunity here, and instead you are using it as a platform to complain about the JCP process, which actually does more harm than good, in terms of re-igniting the JSR for caching. Why don't you assemble everyone who is on this thread and get them involved, if not already.
We all know you are joining ORCL soon, as long as the deal goes through as planned, so you will have even more capacity to do the JSR.
If anyone can explain to me the caching that Coherence does, vis-a-vis app servers, I would be very appreciative, and may return the favor sometime...

Cameron, I feel like you have a big opportunity here, and instead you are using it as a platform to complain about the JCP process, which actually does more harm than good, in terms of re-igniting the JSR for caching. Why don't you assemble everyone who is on this thread and get them involved, if not already.
We all know you are joining ORCL soon, as long as the deal goes through as planned, so you will have even more capacity to do the JSR.
If anyone can explain to me the caching that Coherence does, vis-a-vis app servers, I would be very appreciative, and may return the favor sometime...

I think it's pretty clear that working on a JSR takes a lot of time and most people with fulltime day jobs have a hard time doing both. A good friend of mine participated in a JSR and it took on average 2 days a week. He was working 70hr/week to make sure his daily responsibilities and JSR responsibilities were met. I've heard plenty of JSR participants say how much time it takes, so I wouldn't consider cameron's comment as complaining.
working on a specification has never been easy, so people should "try" to be more understanding of those who work on specs. my bias 2 bits
peter

Well, from my perspective, there was at least some momentum and meat in the original submission from Oracle. I still remember having conversations with Jerry Bortvet (did i get the name right?) on their Caching service submission. But since Jerry never carried this through, nothing ever happened.
Hey! we even offered help in getting the specification to a state where there it could be the least common denominator - all commercial implementations had significantly increased in scope by then.
But, we never saw any concrete action. Now, with so many divergent implementations, getting such a specification to be a standard through the JCP process will be too difficult and not advisable.
Cheers!
Jags Ramnarayan
GemFire from GemStone Systems - The Enterprise Data fabric
(http://www.gemstone.com/developer)

Which makes me even more think that the crippled API / general uselessness which probably lead to the dormant state are done on purpose because those guys proved they can do better than that.
IMO the spec lead perhaps together with some of the members should be exchanged and the whole thing should be rebuild up from the roots - hopefully faster than this try.
Don't get me wrong, I don't have a problem with Tangosol / Oracle earning a lot of money with Coherence but it's simply a dirty shame to try to protect this by neglecting JSRs one joined voluntarily. Even more if one is the spec lead!
Last but not least the 'there's no need' justification is simply ridiculous! Every ORM solution, cluster, application server, ... is in need of some good caching solution and IMHO it would be priceless to have a good caching JSR / API so one can exchange implementations depending on ones preferences.

Well I for one would not dream of suggesting that Cameron deliberately stalled on the JSR. Any spec lead on this is now in a difficult situation because there are already commercial products & other projects that pupport to support the "JCache" api. Consider the situation if the spec lead, whoever it was, proposed extensions to e.g. allow querying of the cache according to some criteria/mechanism that their technology supported but others didn't/couldn't. What an outcry there would be! Then the other vendors/developers really would cry foul.

I know a few people that have worked on JSR's and it takes a lot of time. This is second hand information, since I've never been on a JSR myself. One of my friends spent 4-10 hours a week when he was actively working on the JSR. That's basically 1-2 days a week. How many people can spare 1-2 days a week for a year to work on a specification?
I know I don't have that kind of free time. If you want to get the spec out sooner, than participate and volunteer to get it things done. I wouldn't want to work on a JSR because it takes far too much time. To get a really good spec, you have to put in a lot of time, so it's far from trivial or easy.
peter

First of all I think that a spec is always positive, because it is easier to change implementations if there is a standard set of interfaces - even if you use some special features of a product.
A caching expert, such as Cameron, as the spec lead is a good choice - who could know better what is needed for a caching standard?
Tangasol has done well without a standard and I see no problems being a spec lead and a product owner.
A spec would mean that we would have a standard implementation available for free and if you need e.g. better performance/more features you could easily switch to a more sophisticated implementation like Coherence or Terracotta. So a Win-Win situation for us and the commercial caching companies...
Mirko Novakovic
http://www.codecentric.de

My prospective:
- There’s no dire need for the spec as few OS and commercial products dominate this market segment
- Distributed caching is very complex proposition and any specs would cover only the basics making the such spec of lesser value to begin with
- Implementations and approaches vary drastically making cohesive spec very hard to produce (see previous point too)
- Leading such spec is a full-time job that spec lead should share with another full-time job of his own which is hard
Nikita Ivanov (JSR-107 member)
GridGain project.

Folks,
We have been struggling with Jboss Cache and trying to get things working in a cluster environment.The steps to validate things are not only cumbersome but requires great deal of understanding how caching works. We the Java users community strongly feel, that caching should be a integral part of JDK, supporting not only standalone but also cluster environments. JBoss Cache compilments Hibernate caching..so why not have something that would work well with Java persistence API.
I have my true faith in Sun and hope they will satiate their humble, honest user community !
Cheers
-Vijay

so why not have something that would work well with Java persistence API.

This is as much a limitation of JPA as of JCache not being pursued fully. The JDO2 specification defined a (limited) level of caching semantics allowing people to have cache-independent code across implementations (so that JDO implementations hide any cache-specifics under their implementation layer), so you should be asking the JPA people (JSR220) why they didn't address that very basic capability.
-Andy
JPOX - Java Persistent Objects

I agree that this should be something that requires work on both sides - but only for this specific use case.
Caching does encompass a lot more than working with Hibernate/JPA. Think about data grids or enabling replication of application session state in a cluster.
I think JSR-107 is hugely important and while Cameron is a hugely capable and knowledgable spec lead, for whatever reason the JSR has stalled and does need some new vigour.
- Manik Surtani, Project Lead, JBoss Cache

Isn't JavaSpaces spec already addresses distributed caching?
Why do we need another competing spec (JSR-107) altogether?
I have posted JavaSpaces spec support on WebSphere XD forum and looks like architecture group might consider to use it in ObjectGrid - at least I got confirmation that "Implementing the javaspaces API on top of ObjectGrid is a low hanging fruit that has important strategic benefits for Websphere."
See full thread: http://www-128.ibm.com/developerworks/forums/dw_thread.jsp?message=13926278&cat=9&thread=151473&treeDisplayType=threadmode1&forum=778#13926278
Can anyone here explain rationale behind creating another JSR-107 for caching? Isn't it repeat fiasco or JDO2 and EJB3.JPA competing JSR specs?
In my opinion, by creating competing JSRs we as a Java community deteriorate JAVA image!

No.
I can only assume that you haven't looked at JavaSpaces if you think it addresses distributed caching. It is as poorly purposed for distributed caching as something like JDBC.
Peace,
Cameron Purdy
Tangosol Coherence: The Java Data Grid

Well, JavaSpaces are in fact serving distributed data sharing needs for enterprise application instances.
The concept is quite(very) similar to distributed cache:
1. obtain instance of JavaSpace
2. Put an object in there
3. The object becomes available to all the "subscribers" in that JavaSpace...also you can do lookup by key as well.
So, the concept is very similar to the Map that is shared across multiple JVMs...
Plus it is transactional and items in JavaSpace can expire.
Not sure why you think JavaSpaces are not good candidate to cache data/objects?

Well, JavaSpaces are in fact serving distributed data sharing needs for enterprise application instances.
The concept is quite(very) similar to distributed cache:
1. obtain instance of JavaSpace
2. Put an object in there
3. The object becomes available to all the "subscribers" in that JavaSpace...also you can do lookup by key as well.
So, the concept is very similar to the Map that is shared across multiple JVMs...
Plus it is transactional and items in JavaSpace can expire.
Not sure why you think JavaSpaces are not good candidate to cache data/objects?

Although they do similar things, I believe there are significant differences. For example, one might want to do the following.
1. preload the cache at startup. AFAIK, stock javaspaces does not define API to do this.
2. some cached objects may have different expiration times. AFAIK, javaspaces currently doesn't support that kind of semantics.
3. objects within a cache may be garbaged and the cache may reload it on demand. Or, the application can retrieve the data again and put it in the cache. I haven't read the javaspaces specification in over a year, but an object that goes into javaspaces stays in there until explicitly removed. According to this link http://www.javaworld.com/jw-11-1999/jw-11-jiniology.html?page=2
it says:

Spaces provide reliable storage for objects. When you store an object in a space, it will remain there indefinitely until it is removed.

This is my bias opinion, but once you get into the details, javaspaces and distributed cache have different goals. Although one can use javaspaces as a distributed cache, it may not be the most appropriate tool. One has to look at the functional requirements and make that judgement on a case-by-case basis.
peter

The concept is quite(very) similar to distributed cache: 1. obtain instance of JavaSpace2. Put an object in there3. The object becomes available to all the "subscribers" in that JavaSpace...also you can do lookup by key as well.

So, the concept is very similar to the Map that is shared across multiple JVMs...

Plus it is transactional and items in JavaSpace can expire.Not sure why you think JavaSpaces are not good candidate to cache data/objects?

Everything you described sounds just like JDBC, except replace "space" with "table". Well, that's almost true: JavaSpaces doesn't actually support "lookup by key". ;-)
When the only tool you have is a hammer, ...
Peace,
Cameron Purdy
Tangosol Coherence: Data Grid for Java and .NET

The concept is quite(very) similar to distributed cache: 1. obtain instance of JavaSpace2. Put an object in there3. The object becomes available to all the "subscribers" in that JavaSpace...also you can do lookup by key as well.

So, the concept is very similar to the Map that is shared across multiple JVMs...

Plus it is transactional and items in JavaSpace can expire.Not sure why you think JavaSpaces are not good candidate to cache data/objects?

Obviously i think that you have a good point here. We should definitely ask ourself that question before were jumping to define yet another spec.
I also agree with other comments on this thread that the current JavaSpaces spec need to be enhanced to support specific caching semantics such as integration with external data sources through loader/store interface, enhanced Query interface etc.
So the bottom line is that both JSR107 which is based on Map interface and JavaSpaces need to be enhanced to support specific caching semantics and therfore the question shouldn't be which one of them is better today but which one of them could be a better fit for setting up the basis for a more specialized Caching specification.
I personally believe that the fact that JavaSpaces was already designed to address data coordination and sharing in a distributed environment, the fact that it already supports distributed transactions, and Query semantics as well as blocking operations, the fact that it was written as a distributed service and can be discovered over the network and manage its lifecycle makes it a better fit then a Map based interface.
By doing so we also address a bigger problem domain which involved distributed and parallel transaction processing not just data-caching.
Even though i'm a bit biased I'm sure that the community will benefit much more if we will marry the two together.
As a side comment were about to launch a new community project - openspaces which is aimed to provide a better stage for those ideas and help moving them forward, stay tuned...
Nati S.
GigaSpaces
Write Once Scale Anywhere

[dreaming]
Let's not stop at JSR107. Let's really push what Nati is suggesting to the limit here. Let's forget about existing APIs and implementations. Let's assume a space-based model is simply "a better fit" for everything we do. Let's give up "tier-based computing" as it's no longer need with SBA.
How much lighter and easier to use would Java be? It would just be a bunch of a few core language APIs and then everything else would be space-based data structures. No more lists, maps, sets or queues. No more threads or daemons! No more logging APIs (they are just an ordered space of messages). No more email APIs (every one has a named space as a mail-box). Perhaps we could even remove some keywords, like synchronized, volatile and serializable? Perhaps the language itself could be simplified? Would we need the Object Oriented paradigm?
This is great. We could shorten University degrees by at least a year! We could produce fewer books, save more trees and help save the environment. That itself is far more important than a big bunch of APIs!
It's obvious we wouldn't need JMS anymore, or JDBC because a "space" can do everything. We also don't need EJB, JPA, Hibernate or Spring for that matter. No need to wire things together when it's all the same.
We certainly don't need databases anymore. It's clear that now we can query a space or use it for messaging, Tibco, Sonic, Oracle, Sybase and MySQL are all going to go out of business.
Thinking about it, I'm sure we could also simplify AJAX. We could use an "embedded javascript space" (c) by Me! or use Space-based Swing and HTML.
At the network, we could get rid of TCP and UDP by implementing a native space-based wire protocol. Good bye Ethernet and Infiniband.
We don't need all those tiers. Imagine if we had a single universal API that has infinite guaranteed transactional performance and scalability characteristics that provides every service in the world, both at a micro and macro level. No more WSDL! That has to be good.
[/dreaming]
Ok... I went a little overboard ;), but it's fun to be creative.
Such "logical architectures" (as they are often described) are nice in theory, but often and unfortunately not always useful in practise.
Even with bias, it's evident in this statement about SBA

...designed to address data coordination and sharing in a distributed environment, the fact that it already supports distributed transactions, and Query semantics as well as blocking operations, the fact that it was written as a distributed service and can be discovered over the network and manage its lifecycle makes a better fit then a Map based interface

that it demonstrates the madness of the entire premise. Or perhaps just a lack of appreciation between an interface and its implementation (why can't a Map be distributed with autodiscovery, using JGroups or anything else etc etc), or for that matter, the real-world requirements developers are faced with on a day to day basis.
Message for Nati: "We don't all have time to reinvent everything as a space-based architecture. We know it's cool, but it's not the solution to everything. We know it's your job to push this as you have to for your company, but we don't wake up in the morning dreaming of making our systems, architectures and networks completely space-based (and doing so would not be a sensible practise).
We mostly just want to get things delivered. We mostly seek solutions, not architectures. Making everything space-based is not a solution, it's an architecture. It's an option and not the only one.
Sometimes we do need new architectures, and spaces / caching / messaging / databases (add your favorite here) are the tools to help, but we are cautious of things that prescribe fundamental organizational change or encourages us to reinvent solutions that already work but with a different API. We're also cautious (or should be) of architectures that claim to be capable of being everything for everyone. It's what a lot of other architectures have attempted to do (there are a few in the Java landscape alone), and most have failed."
This is not just the usual words against Map-based interfaces. Simply replace the word "Map" with any of the other APIs mentioned above (or in Gigaspaces marketing material) and you'll see a pattern forming.
Selling architectures must be one of the hardest jobs in the world. A billion Kudos to Nati for being so persistent. I appreciate his courage, enthusasim and conviction to push the space-based approach as an architecture. It just needs to be tempered with some reality.
At a conference recently I was told that "I could replace all of my infrastructure with Gigaspaces." Considering I had not even mentioned what my line of business or current architecture was, I was a little alarmed.
It's all about using the right tool for the right job. Sometimes that may be spaces, sometimes that may be caching or perhaps something else.
Striving for unification of APIs is one thing, but JSR107 should be about caching, because we have an everyday need for it.
Thanks for reading :)
-- Brian
(PS: These are my own opinions and don't in any way reflect who I work for).

I think there is a need for Cache and this will be magnified with many of the Web 2.0 techniques where saving "conversational" state is becomming an increasing issue. I would like to suggestion that the reason "cache" has not gotten off the ground (JSR) is because it bumps into many different competing interests.
Let's take the terms J2EE or JDK for a second. Does a cache solution for JDK *have* to support failover and clustering? I am certain most would agree that a J2EE solution should but if I am writing a simple tomcat like application I certainly don't care about failover or clustering. When I say bump, these features are typically left to the realm of Web Application (J2EE) servers and thus a cache solution is typically part of that overall solution. Take WebSphere and its DistributedHashMap solution, that is a cache solution based on EJB.
Also note that caching can be provided using other existing technologies. One might argue that Seam's Conversational state, that is based on EJB3 persistence, is a cache model. Finally, the ultimate cache is our old friend/ememy the Web Session.
If you look at JCache its approach is simple, all caching is based on Map. Of course it is the configuration and maintenance of all that goes with it that is the issue at hand. But a cache solution does not have to be complicated to be useful.
For web development, if you subscribe to client side state saving you might be saying whats all the fuss. If you subscribe to server side state saving you will recognize that having a .
For me, EJB solutions are just to heavy-weight. Database solutions tend to be based on the persistence model that is built around long term storage; not what we need.
What the JDK should provide is a simple model, built on Map subscribing to the 80/20 rule having API's associated with the configuration and management of a cache. The bells and whistles can then be fought out in the Web Application (J2EE)space.

Now java.net is back online I can check the Javadoc to refresh my memory. I believe the main thing missing from 107 to make it really useful is the ability to query the cache. As it stands you either have to know the key you are looking for or you have to iterate through the entire entry set. And any mechanism that involves templates, OQL, any kind of pseudo sql does not cut it.

I realize I may be late to the party, but I'm glad to see that the discussion is still going strong.
I had previously evaluated JCS and Tangosol, and looked briefly at other caches as well. All are excellent products, but I noticed a couple of things:
1)There was no common configuration mechanism:
To have a truly "pluggable" caching mechanism, a common configuration mechanism (an API, a config file language, or preferably both) needs to be provided as well. Otherwise, users have to go and figure out the configuration mechanism for each type of cache and it can be a real hassle.
2)There were no standardized benchmarks:
In looking across the internet at various caches, each claimed to be the fastest, which ended up providing me (the end user) a disservice more than anything else. It would have been great to have a benchmark / set of benchmarks that would allow users compare apples to apples easily and quickly.
Is there room in JSR107 to address one or both of these issues? If the spec has room for addendums such as these, I believe it would benefit end users substantially.
Thanks,
Jim Bethancourt

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.