Sun公司的首席工程師——Mark Reinhold一直主張將Sun JDK模塊化。他舉例說明了復雜性如何損害這個平臺，以及JDK 6 update 10版的Java Kernel和Quickstarter的功能只是解決了JDK長期關聯(lián)成長導致的表面詬病。
Mark首先解釋了JDK為何會成為現在這樣龐大的狀態(tài)：
JDK非常大，但還沒有像宇宙這么大。
JDK很大是因為在過去13年里，Java SE平臺已經從一個最初打算用于嵌入式設備的小系統(tǒng)發(fā)展成為橫跨廣闊領域、服務于廣大需求的一套豐富的庫集合。擁有這樣一個龐大且功能強大的瑞士軍刀真是難以置信的方便，不過尺寸卻不合適。
他接著解釋了由此導致的缺點：
JDK很大——同時也是緊密關聯(lián)的。它作為一個整體的軟件系統(tǒng)構建。在這種開發(fā)模式下，當編寫新代碼或者改進老代碼的時候，很自然地會利用平臺的其他部分，依靠Java虛擬機的靈活鏈接機制保證運行時一切都正常工作。
但是多年來，這種開發(fā)形式導致了API之間的意想不到的關聯(lián)——和API的實現之間——這又增加了啟動時間和內存占用。例如，一個簡單的命令行“Hello, world!”程序，現在加載和初始化超過300個單獨的類，盡管做出了更優(yōu)秀的工程優(yōu)化（比如類共享），但是在最新的桌面系統(tǒng)上仍然需要100毫秒。當然，對于更大的應用來說，情況會更糟糕。
Mark似乎認為JDK 6 update 10版中的Java Kernel和Quickstarter功能是不夠的：
JDK 6 update 10版的Java Kernel和Quickstarter功能的確改善了下載時間和（冷）啟動時間，至少對Windows用戶來說是這樣。這些技術也確實解決了長期關聯(lián)成長的表面詬病，但是，沒有解決根本問題。
模塊化JDK——最有希望改進下載時間、啟動時間和內存占用這些關鍵值的方法是正面解決根本問題：把JDK劃分為一系列定義良好的、單獨的、但是互相依賴的模塊。
他又談論了模塊化對平臺的好處：
把JDK分解為模塊的過程會強迫所有意想不到的關聯(lián)公開化，然后經過分析，多數會被隱藏或者消除。這反過來，會減少加載類的總數，從而改善啟動時間和內存占用。
如果我們有一個模塊化的JDK，在下載時，我們就會提供啟動特定應用所需的那些模塊，而不是整個JRE。Java Kernel是這種解決方案的第一步，使用定義良好的模塊的進一步好處是下載流可以根據當前應用的特定需要提前定制。
Weijun對最初的帖子發(fā)表了意見，認為JDK的整體特性是由于Java沒有管理依賴的合適方式導致的：
JDK很大是因為Java從來沒有指定任何管理軟件依賴的工業(yè)級方法。
因此，可靠部署java棧的辦法就是把它打包成一個巨大的怪物。
順便說一句，只有SUN和其JDK是這樣的。這種缺少依賴性管理的最壞結果不是導致JDK臃腫，而是所有帶有硬編碼類路徑和大量分支的無法管理的應用（因為如果你無法獨立的管理和更新依賴，你可能會分支出一個被迫綁定到應用的私有拷貝）。
你應該很容易理解為什么Java只存在于J2EE服務器中（服務器提供了基礎java平臺所缺少的管理功能）
GeekyCoder認為模塊化的JDK對大多數開發(fā)人員來說可能不是最急需的：
雖然這很“酷”，但我懷疑這對大多數開發(fā)人員來說是否是最急需的。
我有一種不好的感覺，就是你可能會被少數對你博客的積極回應所影響，而不論他們是否代表了整個Java開發(fā)社區(qū)。
即使只是修復一個票數最多的bug也比僅僅搞“酷”要好得多。
我認為“傾聽你的客戶”只是一個過時的、封閉的、已經被徹底拋棄的想法，但是，看一看好的方面...你現在擁有兩名聲稱樂于助人的開發(fā)人員。祝你好遠。
Similarly Michael B似乎認為企業(yè)用戶不關心模塊化JDK：
模塊化的JDK（或更確切地說JRE）對企業(yè)用戶完全無關。我認為，企業(yè)用戶喜歡JDK它現在的樣子，因為模塊意味著依賴，這聽起來像“DLL地獄” ?，F在JDK很容易分發(fā)和打補丁，這很重要。另外，Java具有良好的向上兼容性：不僅“編寫一次，到處運行” ，而且還“編寫一次，永遠運行” ，這意味著巨大的投資回報率（ ROI ）。這是人們更喜歡Java而不是.NET的原因之一 。MS的戰(zhàn)略一直是： “這是添加了最新功能的新版本，請修改和兼容你的所有應用。 ”MS技術太*了。 Java平臺目前已經模塊化：模塊是我的應用所需要的第三方庫。我喜歡SUN的模式——只有這些庫足夠成熟了才會變成平臺的一部分。 健壯性和可靠性是Java成功的關鍵。所以，請回去繼續(xù)解決那些剩余的bug吧。我真的很喜歡JDK 6 update 10版的這方面功能。
Mark首先解釋了JDK為何會成為現在這樣龐大的狀態(tài)：
JDK非常大，但還沒有像宇宙這么大。
JDK很大是因為在過去13年里，Java SE平臺已經從一個最初打算用于嵌入式設備的小系統(tǒng)發(fā)展成為橫跨廣闊領域、服務于廣大需求的一套豐富的庫集合。擁有這樣一個龐大且功能強大的瑞士軍刀真是難以置信的方便，不過尺寸卻不合適。
他接著解釋了由此導致的缺點：
JDK很大——同時也是緊密關聯(lián)的。它作為一個整體的軟件系統(tǒng)構建。在這種開發(fā)模式下，當編寫新代碼或者改進老代碼的時候，很自然地會利用平臺的其他部分，依靠Java虛擬機的靈活鏈接機制保證運行時一切都正常工作。
但是多年來，這種開發(fā)形式導致了API之間的意想不到的關聯(lián)——和API的實現之間——這又增加了啟動時間和內存占用。例如，一個簡單的命令行“Hello, world!”程序，現在加載和初始化超過300個單獨的類，盡管做出了更優(yōu)秀的工程優(yōu)化（比如類共享），但是在最新的桌面系統(tǒng)上仍然需要100毫秒。當然，對于更大的應用來說，情況會更糟糕。
Mark似乎認為JDK 6 update 10版中的Java Kernel和Quickstarter功能是不夠的：
JDK 6 update 10版的Java Kernel和Quickstarter功能的確改善了下載時間和（冷）啟動時間，至少對Windows用戶來說是這樣。這些技術也確實解決了長期關聯(lián)成長的表面詬病，但是，沒有解決根本問題。
模塊化JDK——最有希望改進下載時間、啟動時間和內存占用這些關鍵值的方法是正面解決根本問題：把JDK劃分為一系列定義良好的、單獨的、但是互相依賴的模塊。
他又談論了模塊化對平臺的好處：
把JDK分解為模塊的過程會強迫所有意想不到的關聯(lián)公開化，然后經過分析，多數會被隱藏或者消除。這反過來，會減少加載類的總數，從而改善啟動時間和內存占用。
如果我們有一個模塊化的JDK，在下載時，我們就會提供啟動特定應用所需的那些模塊，而不是整個JRE。Java Kernel是這種解決方案的第一步，使用定義良好的模塊的進一步好處是下載流可以根據當前應用的特定需要提前定制。
Weijun對最初的帖子發(fā)表了意見，認為JDK的整體特性是由于Java沒有管理依賴的合適方式導致的：
JDK很大是因為Java從來沒有指定任何管理軟件依賴的工業(yè)級方法。
因此，可靠部署java棧的辦法就是把它打包成一個巨大的怪物。
順便說一句，只有SUN和其JDK是這樣的。這種缺少依賴性管理的最壞結果不是導致JDK臃腫，而是所有帶有硬編碼類路徑和大量分支的無法管理的應用（因為如果你無法獨立的管理和更新依賴，你可能會分支出一個被迫綁定到應用的私有拷貝）。
你應該很容易理解為什么Java只存在于J2EE服務器中（服務器提供了基礎java平臺所缺少的管理功能）
GeekyCoder認為模塊化的JDK對大多數開發(fā)人員來說可能不是最急需的：
雖然這很“酷”，但我懷疑這對大多數開發(fā)人員來說是否是最急需的。
我有一種不好的感覺，就是你可能會被少數對你博客的積極回應所影響，而不論他們是否代表了整個Java開發(fā)社區(qū)。
即使只是修復一個票數最多的bug也比僅僅搞“酷”要好得多。
我認為“傾聽你的客戶”只是一個過時的、封閉的、已經被徹底拋棄的想法，但是，看一看好的方面...你現在擁有兩名聲稱樂于助人的開發(fā)人員。祝你好遠。
Similarly Michael B似乎認為企業(yè)用戶不關心模塊化JDK：
模塊化的JDK（或更確切地說JRE）對企業(yè)用戶完全無關。我認為，企業(yè)用戶喜歡JDK它現在的樣子，因為模塊意味著依賴，這聽起來像“DLL地獄” ?，F在JDK很容易分發(fā)和打補丁，這很重要。另外，Java具有良好的向上兼容性：不僅“編寫一次，到處運行” ，而且還“編寫一次，永遠運行” ，這意味著巨大的投資回報率（ ROI ）。這是人們更喜歡Java而不是.NET的原因之一 。MS的戰(zhàn)略一直是： “這是添加了最新功能的新版本，請修改和兼容你的所有應用。 ”MS技術太*了。 Java平臺目前已經模塊化：模塊是我的應用所需要的第三方庫。我喜歡SUN的模式——只有這些庫足夠成熟了才會變成平臺的一部分。 健壯性和可靠性是Java成功的關鍵。所以，請回去繼續(xù)解決那些剩余的bug吧。我真的很喜歡JDK 6 update 10版的這方面功能。