JSR-107（JCache）正在制定当中，将成为Java EE 7的一部分
分布式缓存在提升性能和可伸缩性时举足轻重，但Java目前还没有任何完整、标准的缓存机制。JSR-107（JCache API）正在紧锣密鼓的制定当中，以后会成为Java EE 7的一部分。JSR-107这些年有些声名狼藉，因为它是一个很老的规范，但到现在还没有完成，不过随着对缓存的需求越来越多，JSR-107最终是要问世的。
Greg Luck是JSR-107规范的共同牵头人，长期参与领先的开源Java缓存实现Ehcache的开发和维护。InfoQ有幸对Greg进行了采访。
InfoQ：JCache真的会成为Java EE 7的一部分么？
是的，Java EE 7（JSR-342）已经把JCache（JSR-107）引入为候选者了。 JSR-342规范的领导者已经对JSR-107展开了评测。JSR-107规范有一个强制的功能集和两个可选功能：注解和JTA。我们想让Java EE 7引入的正是这个完整版本。同时，我们还和Java EE 7规范的领导者Linda DeMichiel，以及Oracle的Java EE 7团队进行着密切的协调合作。
InfoQ：缓存对Java EE和Java来说，似乎是一个重要却缺失的功能，你觉得JCache为什么会花这么长时间呢？
JSR-107的规范号比较小，从这可以看出来，这个规范十年前就被想到了。它最初由Oracle开始做，但后来被搁置了好几年。过去三年里我一直参与其中，Terracotta和Oracle在去年加强了对JSR-107的投入。
缓存向来都不是规划在架构里，而是企业应用在生产环境里出问题之后才添加到企业应用里的。有一个例外是ORM，因为它本身的方法就需要一个缓存。
Greg接着说，Java EE 7是针对云的，规范领导者也看到了缓存的价值。可以推断一下：一旦开发人员开始用缓存解决性能问题，他们就能看到缓存的价值。然后，认为缓存很不错的开发人员在新项目和解决方案一开始就会引入缓存，而不是等到出现性能问题的时候才加以引入。
这已经让缓存成为架构里公认的一部分，而不仅仅是性能补丁。Greg对NoSQL和Ehcache等缓存解决方案进行了对比，Ehcache这些缓存解决方案在很多方面都试图解决同样的伸缩性问题，只是采用了不同的方式。Ehcahe和Java里的memcached，以及整个行业内的缓存，两者的应用都急剧增长。比如说，Memcached是个容错的分布式缓存，从消费者的注意力份额（Mindshare）来讲，2007年它还相对默默无闻，现在则超越了位列第一的商业分布式缓存Oracle Coherence（Coherence自身也在增长），这表明缓存的市场有很大潜力。
Greg就职的Terracotta已经开始在Ehcache里实现规范，其中包括BigMemory、Cache资源预留等功能，同时会支持独立模式和分布式模式。Ehcache是众所周知的开源Java缓存，尤其被使用过Hibernate的用户所熟知。
和大多数Java缓存实现一样，Ehcache有一个本地内存复制模式，这种模式和纯粹的分布式版本相比具有显著的性能优势。虽然Memcached激发了大家对缓存解决方案的兴趣和需求，但更快、符合标准的实现也会有一席之地。有了标准API，供应商就可以有自己的实现，开源实现也能在性能、易用性、对弹性云的支持、可伸缩性等更多方面和供应商的产品展开竞争。
缓存现在似乎愈发成为企业和云解决方案的特定组件，因此很多供应商目前都正在实现或是打算实现JCache，包括Terracotta、Oracle、JBoss、Caucho、IBM、Google App Engine等。
针对JSR-107和几个月前才推出的JSR-347（数据网格JSR），大家似乎有一些争议。
InfoQ：如果JSR-107和JSP-347有重叠的内容怎么办？JSR-107和JSR-347的范围是怎样划定的？
JSR-347定义为JSR-107的超集，它对JSR-107有一个依赖，额外增加了数据网格功能。JSR-107进行了精心设计，同时支持独立缓存和分布式缓存，与分布式缓存实现的拓扑结构没有关系。JSR-107已接近尾声，我们希望这对JSR-347的定义有所帮助。
JSR-347定义了回收、复制、分发和事务的行为。JSR-347花费了更多的精力去定义一套健壮的异步非阻塞API，这对数据网格来说是很重要的。JSR-347会增加更多的API，也会同时支持JSR-107的API。
InfoQ：JSR-107是不是只关注Java EE？对Java SE有关注么？
JCache是针对Java EE的，但并不妨碍Java SE使用它。Ehcache等实现在Java SE、Java EE和Spring上都能运行。
API分成两部分：没有依赖的基本Profile，这在Java SE上就可以使用；添加了JTA和缓存方法注解的完整Profile。完整版本是针对Java EE 6、Spring和其他企业环境的，在现有的企业环境里都能工作。被纳入Java EE 7之后，Java开发人员就会意识到可以使用它。我们希望 JSR 166组能为JDK 8构建一个简单的进程内缓存。
InfoQ：JCache的进展、过程和设计有哪些主要的变化和改进？
我们已经构建了API、RI（参考实现）和TCK（技术兼容性套件），正在把它们发布到oss.sonatype.org上。所有的源代码都放在GitHub上。GitHub上的Readme给出了完整的介绍和链接。整个过程和规范都是开放的，源代码和社区也都是开放的。
从设计的角度看，基本组成部分有一个CacheManager，用来持有、控制缓存集合。缓存有一些条目。我们还有一个类似API的映射，可以和以下附加功能进行交互：
- 原子操作
- 通过缓存读取
- 通过缓存写入
- 缓存事件监听器
- 统计
- 事务
- 注解
缓存很多地方都用了泛型。我们不限制分布式缓存的拓扑结构，处理分布式缓存时也比较谨慎。Terracotta和Oracle都出售分布式缓存产品，我们打算让这套API有助于这些产品的应用。
开发人员会发现这套API简单而强大，并且涵盖了大多数情况。
JSR-107公开了它的邮件列表，把规范也发布为公开的Google文件，对JSR如何公开来说，这已经达到一定高的标准了。和过去的一些JSR相比，JSR-107的做法是一个里程碑。
JSR-107姗姗来迟，但最终会问世。分布式缓存在提升性能和可伸缩性时举足轻重，好在Java将有用于缓存的标准API。Java世界里，分布式缓存的需求有非常大的潜力，JSR-107最有可能为Java的前景锦上添花。
查看英文原文：JSR-107, JCache: Alive and Going to be Part of Java EE 7