關于轉到公開預覽，我們在EG內還沒有達成共識。這只是因為有部分成員仍堅持認為，我們必須實現既沒有在最初提交的JSR中提到又沒有在協商一致的需求中記錄的目標。然而，進入下一階段符合更廣泛的Java生態系統的最佳利益，那樣，我們可以兌現我們實際承諾的目標。因此，盡管沒有達成一致，我還是提交了公開預覽規范。
作為回應，來自IBM的Tim Ellison提供了一些其他的背景信息，說明為什么IBM將投反對票，他用一條非常長的消息概述了自己和其他人的擔憂。
雖然我理解繼續推進這個進程的愿望，但我認為，聽取EG的集體智慧并尊重他們的意見是有價值的。它不應該讓人如此震驚，執行委員會代表向EG成員發表講話，讓他們就規范是否已經準備好進入下一階段支持自己的立場。
有必要讀一下整個評論，下面是他列出的其中一部分技術問題：
隔離不充分——模塊的非導出（私有）程序包應該嚴格實現細節。JPMS默認每個層一個單獨的類加載器，這意味著，當同時加載時，私有程序包可能導致出人意料的沖突。
模塊名稱自動化——模塊的依賴是通過模塊名表示的，因此，提供一個標準API的實現者都必須使用相同的模塊名。然而，模塊名稱自動化的基礎是jar文件名，而它們是實現細節。我們需要確定，模塊名是一組API還是一個具體實現的簡寫。
訪問限制會破壞執行反射的程序庫——模塊必須事先知道是否向反射開放，并且知道反射者的模塊名。這會破壞依賴注入，諸如此類。
對于最后一點，我們和目前處于預覽狀態的CDI 2.0的規范負責人Antoine Sabot-Durand進行了交流。當然，作為RetHat的員工，他當然站在RedHat和IBM的立場上，他表示：
Jigsaw應該僅對CDI規范產生有限的影響，但在具體實現時，影響將是巨大的（反射部分、代理處理、類加載）。按照我的理解，Java 9提供了一個新的Layer API，那可以解決部分類加載和可見性問題，但文檔中缺少示例，切換到Layers可能意味著巨大的工作量，而且沒有絕對的保障。
不過，Spring Framework項目負責人Juergen Hoeller告訴我們，Spring Framework 5.0 RC1或4.3.8依賴于最新的JDK 9 build 167：
開放模塊不必知道反射者的名稱；它們可以只是選擇性地將自己暴露給特定的模塊。應用程序模塊很容易聲明，本身或具體的程序包向其他任何模塊開放。在我看來，這很方便，當然不是Jigsaw的設計缺陷。 即使不公開聲明，導出類型的反射也可以很好地工作；只不過是操作一個非公有的字段，或者調用一個最終會失敗的非公有方法。也就是說，我們可以通過內省找出任何導出類的注解……只要我們在公有構造函數/方法上找到這樣的注解，那么在任何情況下，我們都可以執行依賴注入——即使沒有公開聲明。 為了處理類的“非公有”成員，模塊其實需要將自己或者至少是受影響的程序包聲明為公開。這會影響私有字段注入、到私有字段的數據綁定以及Spring將CGLIB用于@Configuration類和非接口AOP代理……這就是為什么我們建議（但不是必須）使用Spring時公開聲明。總之，將當前的Spring Framework jar文件用作Jigsaw模塊路徑的“自動化模塊”是一種開箱即用的順暢體驗，無需為此自定義命令行標識。應用程序可能會在它們自己的模塊描述符中遵循Jigsaw的自動化模塊命名方法，聲明對“spring.context”等的模塊依賴。只要這種基于jar文件的模塊名目前沒有問題（我非常喜歡它對Spring jar和常見第三方庫的命名），基于Spring的應用程序就已經可以選擇一種不錯的Jigsaw設置體驗了。盡管如此，Hoeller也指出，他希望大多數基于Spring的應用程序留在類路徑上，即使升級到JDK 9時也是如此，這主要是為了更方便地集成類似Hibernate這樣的第三方庫。
在Java社區進程執行委員會的25個成員中，有三分之二采用了新的Java標準。InfoQ和另外一名專家組成員、來自Hazelcast的Christoph Engelbert進行了交流，他表示，Hazelcast也可能投反對票：
我認為情況相當復雜，因為贊成者和反對者雙方可能在不同的點上是正確的。Mark Reinhold提到的其中一個問題是，某些特性起初是不必要的。雖然這很可能是對的，但之所以一定要實現，是因為Java世界的開發者們不想在今后幾年的開發中作出改變。顯然，那也是不正確的。
一般來說，在Hazelcast，我們看到，JSR376專家組（EG）沒有達成一致，規范負責人的處理方式也很值得懷疑。我們還沒有投票，但根據和社區及EG成員的討論，我們可能會投“反對票”。
不要誤會我，我是說，Jigsaw是一個重要的特性，但它需要更多的時間或者換種方式來停止它。使用“大關閉開關（big Kill-Switch）”沒問題，但激活它意味著你會在stdout上看到警告，而這些警告不會出現在Oracle的跟蹤系統中，但會出現在我們的支持團隊那里（至少對于我們的用戶和客戶是如此）。這是我們很可能投反對票的第二個原因。
我們知道這對于發布日期意味著什么，但是我們認為，更高程度的共識很重要，執行委員的部分職責是保證Java生態系統的健康。在當前狀態下，對于許多庫、框架及應用程序而言，Jigsaw可能仍然是一個問題。
可是，InfoQ也了解到，另一個專家組成員Azul Systems可能投贊成票。首席執行官Gil Tene告訴我們：
關于這一點，我們有點糾結。Jigsaw是一個對Java開發人員有幫助的模塊系統，我贊成其中一部分（不是全部）反對意見。在我看來，根據現實世界常見的實際案例，缺少對單個應用程序中同一模塊的多版本支持，限制了它在JDK之外的可用性（應用程序使用了Maven Central程序包A和B，兩者均依賴模塊C，但A需要C.1.1.0 ，而B需要C.1.2.1）。
不過，盡管有反對意見，但我們還是會投贊成票。其中許多都是來自溝通不順暢及過高的期望。雖然有些反對意見是合理的，人們對Jigsaw的期望（Java SE 9的規劃）遠遠超出了它的實際，但我沒有理由拒絕它作為一個主要在JDK內部使用的模塊系統（出于批判Java SE 9的立場，我就是這么看待Jigsaw的）。在我看來，我們將會看到Jigsaw在JDK之外的有限應用，對于公開發布的庫和可重用代碼尤其如此。舉例來說，JDK本身永遠不用處理多版本的問題，所以按照現在的情況，Jigsaw在JDK里可以工作得很好。我期望的是，可以為非JDK開發人員帶來更多好處的“真正的Jigsaw”（Jigsaw 2.0？）會晚一點推出。Java 10?或11?，希望不是永不……但是，in-JDK Jigsaw已經接近完成，隨時可以發布，我沒有理由延誤Java SE 9，我不能因為希望重做它或者解決其中部分重大事項而延誤整個發布序列。
我們接觸過的大多數人都告訴我們，他們尚未達成一致。例如，代表LJC的Martijn Verburg就告訴我們：
對于JSR送審，規范負責人和專家組的分歧如此之大還是很少見。我在執行委員會工作了大約五年，我不記得以前曾經出現過這種情況。
投票即將在5月8日關閉，JCP執行委員會正在討論規范負責人和專家組成員提出的各種觀點，并考慮來自更廣泛Java社區的成員的評論。在投票結束之前的兩天時間里，他們會在一起開會，這將是議程上的一個重要課題。倫敦Java社區當然認為EC頗能代表更廣泛的Java社區，并且認為它非常適合評估Jigsaw以其目前狀態對Java及其生態系統有益還是有害。
模塊化很難，Jigsaw團隊在設計和實現上已經進行了大量的思考，特別是，我們當然不希望看到已經完成的Java模塊化工作本身被延誤。不過，如果更廣泛的生態系統拒絕支持當前的設計/實現，那么它就無法獲得廣泛的應用，那至少會讓生態系統中的許多人失望。
有趣的是，在我們最初報道這一事件的博文的留言板上，來自Red Hat的David Lloyd表示，那可能會稍微導致一些延誤，直至解決問題：
我覺得，延誤幾周，討論、實施、測試讓其達到一個最小可接受狀態所需要的修改，可能對于每個人而言都是最好（和最現實）的。
我們將看下當投票于5月8日關閉時會發生什么。
京公網安備 11010502049343號