自2009年1月起，Coin便是Java 7（和Java 8）中一个开源的子项目。本节，我们会以Coin项目中包含的小变化为例，解释一下Java语言如何演进以及那些特性是如何被选中的。
为Coin项目命名
创建Coin项目是为了反映Java语言中的微小变动。项目的名字是个双关语——像硬币一样小的变化（small change comes as coins），而“套用一句老话”（to coin a phrase）指的是给Java语言添一个新的表述方式。
在技术圈子里，这种文字游戏、奇思妙想和躲不掉的恐怖双关语随处可见。你可能已经对此习以为常了。
我们觉得解释语言“为什么要变”和“变成了什么”同样重要。在开发Java 7的过程中，人们对新语言特性产生了很多兴趣，但Java社区有时并不明白要按时实现这些特性需要多大工作量。希望我们在“为什么要变”这一问题上能够对你有所启示，也希望能借此消除一些荒诞的说法。如果你对Java如何发展进化不感兴趣，可以直接阅读1.3节，看看Java语言发生了哪些变化。
关于修改Java语言有一个工作量曲线，某些实现方式可能要比其他方式需要的工作量少。如图1-2所示，我们尽量把不同的修改方式及其所需的工作量呈现出来，以展现不同复杂度及相关工作量的增长。
图 1-2 用不同方式提供新功能所需工作量的比较
一般来说，工作量越少越好。也就是说，如果能用类库实现新特性，那就应该用类库。但有些特性用类库或增加IDE功能实现起来有难度，甚至根本不可能，那就必须在平台的更深层中实现。
下面是一些特性（大部分是Java 7中的），它们符合我们为语言新特性定义的复杂度。
- 语法糖——数字中的下划线（Java 7）；
- 新的语言小特性——try-with-resources（Java 7）；
- 类文件格式的变化——注解（Java 5）；
- JVM的新特性——动态调用（Java 7）。
语法糖“语法糖”是描述一种语言特性的短语。它表示这是冗余的语法——在语言中已经存在一种表示形式了——但语法糖用起来更便捷。
一般来说，程序的语法糖在编译处理早期会从编译结果中移除，变为相同特性的基础表示形式，这称为“去糖化”。
因此，语法糖是比较容易实现的修改。它们通常不需要做太多工作，只需要修改编译器（对于Java来说就是javac）。
Coin项目中（以及本章余下的内容）都是关于从Java语法糖到小的新特性这个范围之内的变化。
Coin项目的最初建议阶段从2009年2月持续到3月，coin-dev的邮件列表上收到了大约70个提议，囊括了各种可能的改进。甚至有人开玩笑说要增加lolcat风格的多行字符串（把标题叠加在好笑或生气的猫咪图片上，看你怎么想了——http://icanhascheezburger.com/）。
Coin项目提案的评判规则很简单。贡献者要完成三项任务：
- 提交一份详细的提案来描述修改（本质上应该是对Java语言的修改，而不是针对虚拟机的）；
- 在邮件列表上针对提案进行开放式讨论，能够接受其他参与者建设性的批评和建议；
- 随时可以提供一组能够实现变化的补丁原型。
Coin项目很好地示范了语言和平台在未来如何演进，所有的修改都会公开讨论，提供特性的早期原型，并且呼吁公众参与。
“什么是对规范的小修改？”现在也许就是提出这个问题的最好时机。我们马上要讨论在JLS的第14.11节中增加的一个单词——/"String/"。你可能再也找不出比这个更小的修改了，可即便是这样一个修改都会涉及规范中其他几个地方。
Java 7是以开源方式开发后发布的第一个版本
Java一开始并不是开源语言，但在2006年的JavaOne大会上其自身的源码以GPLv2许可发布（去掉了一些Sun不具有版权的源码）。当时正值Java 6发布前后， 所以Java 7是Java在开源软件（OSS）许可下发布的第一版。开源的Java平台开发主要集中在项目OpenJDK上。
邮件列表coin-dev、lambda-dev和mlvm-dev等是讨论未来各种可能特性的主要场所，来自五湖四海的开发人员都可以借此参与到创造Java 7的过程中来。实际上，我们参与领导了“Adopt OpenJDK”计划，为新加入OpenJDK的开发人员提供指导，帮助改进Java。如果你想加入我们，请访问http://java.net/projects/jugs/pages/AdoptOpenJDK。
任何修改都会产生影响，我们必须从Java语言的整体设计上来追踪这些影响。
任何修改都应该严格执行下面这些操作（或至少调研一下）：
- 更新JLS；
- 在源码编译器中实现一个原型；
- 为修改增加必要的类库支持；
- 编写测试和示例；
- 更新文档。
除此之外，如果修改触及VM或者平台，应该：
- 更新VMSpec；
- 实现VM的修改；
- 在类文件和VM工具中增加支持；
- 考虑对反射的影响；
- 考虑对序列化的影响；
- 想一想对本地代码组件的影响，比如Java本地接口（JNI）。
考虑到这些修改对整体语言规范产生的影响，这可不是一星半点儿的工作。
如果你要修改类型系统，简直就是自寻死路，类型系统可是个不折不扣的雷区。这不是因为Java的类型系统不好，而是因为对于拥有多种静态类型系统的语言来说，这些类型系统之间有可能会产生很多交叉点。修改它们很容易出现意想不到的状况。
Coin项目选的路线非常明智，它建议贡献者们在修改提案中远离类型系统。因为对这种修改而言，即使最小的变化都需要做大量的工作，所以这种做法也是比较务实的。
在简单介绍了Coin项目的背景之后，接下来该看看它包含哪些特性了。