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
