I'm trying to use JCS under JCache API (if it was not clear). I'm removing serializable constraint from signatures (next step will be to enforce it in impl as a validation but a cache forcing cached values/keys to be serializable is just not really usable in more of 80% of cases I met).
I'll try this week more or less to get something decent. If not maybe you are right and we'll do a jcache incubator project starting from last commit without jcs-core as a dep of jcache module. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-05-11 21:02 GMT+02:00 Thomas Vandahl <t...@apache.org>: > Hi Romain, > > On 11.05.14 20:33, Romain Manni-Bucau wrote: >> actually I evaluated JCS and found several issues (why ATM JCache >> doesn't rely on it anymore): > > Well, then what does the project have to do with JCS? The initial idea > was to provide JCache compatibility to JCS, IIRC. > >> 1) about network stuff: listeners are not enough and needs an >> important refactoring for JCache, it is not that test friendly (start >> aone (or more) instance(s) of server and several clients in the same >> JVM) and more important reason to not go further in it is that it >> doesn't seem the default need. So we can skip it for 1st JCache >> compliant release IMHO. > > I don't think so. A JCS core release will have to have at least the > documented features working properly. Do you want to release > commons-jcs-jcache separately? > >> 2) why a ConcurrentHashMap instead of a CompositeCache: I hesitated a >> lot on it but after some benchmarks (get/put mainly) JCS was really >> too slow compared to a concurrenthashmap. Now it is slower but not >> enough to let user think of using a concurrenthashmap in their code >> cause cache would be too slow. > > Again, I'd like to ask you seriously to make yourself familiar with the > concepts behind JCS. If all you need is a ConcurrentHashMap, you simply > should use a ConcurrentHashMap. But if you need fine-grained control > over your caching mechanisms, the map is simply not enough and the lower > speed can be easily traded in for the additional features. > >> I'll try to rework a bit JCSCache to merge both but if I don't manage >> to make it comparable I think we should just get 2 implementations. >> Another really blocking point ATM is the fact JCS mandates key/value >> pairs to be serializable. > > -1 > That would not be commons-jcs-jcache but commons-jcache. Please > reconsider. You will come across a lot of the requirements that JCS can > fulfill today, I promise. And once separated, the two projects will > probably never merge again. > > And yes, serializable keys and values are absolutely necessary to > support disk caches and distributed caches. I cannot imagine any decent > non-trivial cache implementation to work without them. > > Bye, Thomas. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
