- The standard is DI friendly (rather than just having a singleton way of getting a CacheManager, which is how a lot of the other JSRs behave, making it difficult to have different implementations in the same VM)
- It's got compare and swap from ConcurrentHashMap built in, which is great
- Support for write-through and write behind
- There's no support for asynchronous gets / puts but that's not too surprising.
- It's not clear how to set a per entry expiry
It'll be interesting to see how this maps onto something like memcached.
The shitty parts, like J2EE, are designed by committee and more than that each committee has an implementation that they're going to sell right out of the gate. It's supposed to be a standard that solves problems, but each player has an incentive to try and lock you in, and is more concerned with selling software than solving problems.
1. Most of them are leaky abstractions
2. If you use them, you should nevertheless shield yourself from them (See Uncle Bob), so you abstract over an abstraction
3. Because of 1, you need to rewrite your app to the semantic of each implementation of the abstraction (Portlet API, Java Content API JCR).
Case in point: You can use Derby for development and MySQL for production and you will get into trouble as although you use JDBC, the SQL over the wire has different syntax. And using ORM doesn't help you either (JPA), it has the same problems just one meta-level up.
