自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項目的背景之後，接下來該看看它包含哪些特性了。