After 15 years of Java and a proponent of Java APIs I'm no longer sure this standard APIs are a good idea.<p>1. Most of them are leaky abstractions<p>2. If you use them, you should nevertheless shield yourself from them (See Uncle Bob), so you abstract over an abstraction<p>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).<p>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.
This is great. This is a pretty old, no brainer JSR that seemed to have got stuck in committee for ages. A few highlights:<p>- 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)<p>- It's got compare and swap from ConcurrentHashMap built in, which is great<p>- Support for write-through and write behind<p>- There's no support for asynchronous gets / puts but that's not too surprising.<p>- It's not clear how to set a per entry expiry<p>It'll be interesting to see how this maps onto something like memcached.