【51CTO精選譯文】Java 7（嚴格說來是JDK 7）現(xiàn)在已經(jīng)公開了M5版本用于測試，其中有已經(jīng)完成的七大功能，也有開發(fā)者放出一些主要功能的代碼范例供他人參考。JDK的每一次改版都有人抱怨說這令Java平臺更加臃腫，正在步上C++的老路。這次JDK 7是否能夠扭轉這一局面？Sun的員工，JDK核心團隊的工程師Alan Bateman近日在博客上撰文，介紹了JDK 7在模塊化方面做出的努力，從而解決之前那些臃腫的問題。

JDK 7的一個目標就是要給我們提供模塊化的平臺。達到這個目標會比較困難，因為它是一個關系錯綜復雜的代碼基礎，是由API與很多不同領域的實施之間的依賴關系構成的。這些關系已經(jīng)建立起了很多年，而且在很多發(fā)布的版本中都是如此。舉個例子（這種情況來自以前的幾個版本，但是大部分也適用于JDK6）：假設你正在使用Logging API（意味著需要java.util.logging）。Logging需要NIO和JMX，而JMX又需要JavaBeans, JNDI, RMI 以及CORBA (JMX 的遠程 API 要求 RMI 連接器支持JRMP和IIOP)。JNDI又需要java.applet.Applet，而JavaBeans依靠AWT, Swing，以及所有客戶端的東西。如果這些還不夠，意味著JavaBeans會一直跟JDBC以及更多的東西有關系。我還能夠繼續(xù)延伸下去，但是我們應該清楚的是這個看起來似乎很無辜的logging API的使用卻引出了如此眾多的依賴關系，幾乎包括了整個平臺。很明顯，這些只是依賴關系，日志并沒有真正需要實際裝載任何CORBA的1600多個類。想象一下，這種情況更像是兩個人在吃飯，但是她卻雇了輛公共汽車把她的一大家子人和朋友都拉到飯店的外面等著。

[[7589]] 
這種情況更像是兩個人在吃飯，但是她卻雇了輛公共汽車把她的一大家子人和朋友都拉到飯店的外面等著

好消息是以前的幾個版本中在解決這些問題方面已經(jīng)開始有了進步。日志不再需要JMX（這需要一個API變化來收回/重新訪問）。我們從RMI-IIOP中分離出來，所以你不需要CORBA的存在就能夠進行遠程管理。當不使用JavaBeans的時候，JMX會發(fā)揮自己的作用。JNDI不再需要java.applet.Applet，JavaBeans不再需要JDBC，AWT也不再需要RMI，等等。

JDK 7的模塊劃分

那么我們處在哪一階段呢？目前，我們有了一個初步的基本模塊，它本質上就是核心庫（lang/io/net/util/nio/security）。過去，在這個模塊中存在的類對JNDI、部署代碼、AWT、參數(shù)選擇以及l(fā)ogging APIs、JMX的依賴關系都被移除或者轉換了。里面還是有一個對XML分析的依賴，但是這個問題隨著時間的推移也會被解決。

所有這些Swing, AWT, 2D等等都被分組放在一個初步的客戶端模塊中。這個模塊中的API之間的聯(lián)系是錯綜復雜的，所以面臨著一個很大的挑戰(zhàn)。在客戶端還存在幾個跟其他的模塊（比如網(wǎng)絡服務）依賴關系，這也需要做工作，但是最終可以不去管它，比如當部署一臺嵌入式設備的時候。

我們可以對幾個比較小的模塊進行分組，在將來可能進入更大的模塊組里。Logging, RMI, JSSE (SSL), SASL, JDBC, JNDI, LDAP 和其他的 JNDI 提供商, PKCS11和其他的安全提供商將會給它們命名。JSSE就是一個很好的例子，人們把它從平臺的其他地方解脫了出來。有人可能認為他不需要JSSE就可以保證網(wǎng)絡的安全，但是由于SSL能夠使用基于認證的Kerberos作為協(xié)議，它就被綁定在Kerberos/JGSS上。在這種情況下，依賴關系是可選擇的。如果安裝了Kerberos，那么SSL在對安全環(huán)境進行協(xié)商的時候就可以包括Kerberos。當沒有安裝的時候，它不會試圖使用Kerberos進行協(xié)商。

我在上面提到了CORBA，因為它經(jīng)常被當做JDK兼容性問題的替罪羊。人們已經(jīng)提出了一個可能的兼容性模塊，它可以兼容那些不再建議使用的、遺留的、過氣的，以及其他一些代碼。Sean Mullan和Vincent Ryan在這方面做了很好的工作，他們移除了JDK 7 b78中對過時的安全類依賴關系，所以這些類不需要存在于基本的模塊中。另外一個可能需要移除的是遺留的sun.io轉換器。我們在多年以前就應該擺脫這些轉換器的束縛，但是由于還存在JDBC驅動而不能移除對它們的依賴。在sun.misc中也有很多不再使用的類，但是我們不能移除它們，因為有些怪異的應用程序會可能直接使用它們。過時的協(xié)議處理程序和內容處理程序是其他一些需要移除的東西。其實，我敢保證讀者還能想到其他需要移除的內容。

在上面提到的內容中，值得注意的是模塊不一定跟包（package）的邊界對齊了。對于一個模塊來說，在一個或者更多完整的包中包含所有的類非常必要，但是很多情況下這是不可能的。我上面提到的JavaBeans就是一個很明顯的例子，人們必須把屬性事件支持、內部標注與綁定在客戶端區(qū)域的其他類區(qū)分開來。New I/O 以及 Logging的API具有管理接口，把這些管理接口分組加入到跟JMX以及java.lang.management相對應的管理模塊中有更大的意義。我前面也提到過IIOP運輸跟RMI編譯器的分離。Rmic編譯器將生成stub和the javax.management.remote.rmi包的關系，但是我們不想把這些分組到管理模塊，因為它會對CORBA產(chǎn)生依賴。如果有人想對基本模塊進一步分解，那么這將意味著要讓java.util這樣的包能夠包含比API集合更多的東西。

總結

#T#我希望上述內容能夠讓你了解在JDK 7中發(fā)生了什么。一個更加模塊化的JDK讓我們離提高性能的目標越來越近了（包括下載以及開始時間），它能夠讓平臺按比例縮減，而且能夠帶來更多的好處。那些對這方面感興趣、想要深入學習的人們可以從Jigsaw工程頁面以及郵件列表開始入手。Jigsaw工具庫里有一個名叫ClassAnalyzer的工具，我們一直使用它分析各種依賴關系以及指導各種變化。這個工具能分析模塊的定義，并給每個模塊產(chǎn)生幾個文件，包括類的列表，以及它們之間的依賴關系。它能生成各種形式的總結文件，包括DOT文件，這對于那些想用肉眼看到各種依賴關系的人來說非常實用。上面提到的大部分工作可以認為是在移除依賴圖表的優(yōu)勢。Mandy已經(jīng)在著手下一步的工作了，改變版本的功能，讓JDK能夠生成模塊而不是rt.jar。這需要幾個步驟。最初的版本將生成JAR文件，但是最終我們一定能把它轉換到一個更好的容器格式下。

原文：Is the JDK losing its edge(s)? 作者：Alan Bateman