java 臃肿_JDK核心工程师答疑：模块化令JDK 7不再臃肿

【51CTO精选译文】Java 7(严格说来是JDK 7)现在已经公开了M5版本用于测试，其中有已经完成的七大功能，也有开发者放出一些主要功能的代码范例供他人参考。JDK的每一次改版都有人抱怨说这令Java平台更加臃肿，正在步上C++的老路。这次JDK 7是否能够扭转这一局面？Sun的员工，JDK核心团队的工程师Alan Bateman近日在博客上撰文，介绍了JDK 7在模块化方面做出的努力，从而解决之前那些臃肿的问题。

JDK 7的一个目标就是要给我们提供模块化的平台。达到这个目标会比较困难，因为它是一个关系错综复杂的代码基础，是由API与很多不同领域的实施之间的依赖关系构成的。这些关系已经建立起了很多年，而且在很多发布的版本中都是如此。举个例子(这种情况来自以前的几个版本，但是大部分也适用于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以及更多的东西有关系。我还能够继续延伸下去，但是我们应该清楚的是这个看起来似乎很无辜的logging API的使用却引出了如此众多的依赖关系，几乎包括了整个平台。很明显，这些只是依赖关系，日志并没有真正需要实际装载任何CORBA的1600多个类。想象一下，这种情况更像是两个人在吃饭，但是她却雇了辆公共汽车把她的一大家子人和朋友都拉到饭店的外面等着。

 

这种情况更像是两个人在吃饭，但是她却雇了辆公共汽车把她的一大家子人和朋友都拉到饭店的外面等着

好消息是以前的几个版本中在解决这些问题方面已经开始有了进步。日志不再需要JMX(这需要一个API变化来收回/重新访问)。我们从RMI-IIOP中分离出来，所以你不需要CORBA的存在就能够进行远程管理。当不使用JavaBeans的时候，JMX会发挥自己的作用。JNDI不再需要java.applet.Applet，JavaBeans不再需要JDBC，AWT也不再需要RMI，等等。

JDK 7的模块划分

那么我们处在哪一阶段呢？目前，我们有了一个初步的基本模块，它本质上就是核心库(lang/io/net/util/nio/security)。过去，在这个模块中存在的类对JNDI、部署代码、AWT、参数选择以及logging APIs、JMX的依赖关系都被移除或者转换了。里面还是有一个对XML分析的依赖，但是这个问题随着时间的推移也会被解决。

所有这些Swing, AWT, 2D等等都被分组放在一个初步的客户端模块中。这个模块中的API之间的联系是错综复杂的，所以面临着一个很大的挑战。在客户端还存在几个跟其他的模块(比如网络服务)依赖关系，这也需要做工作，但是最终可以不去管它，比如当部署一台嵌入式设备的时候。

我们可以对几个比较小的模块进行分组，在将来可能进入更大的模块组里。Logging, RMI, JSSE (SSL), SASL, JDBC, JNDI, LDAP 和其他的 JNDI 提供商, PKCS11和其他的安全提供商将会给它们命名。JSSE就是一个很好的例子，人们把它从平台的其他地方解脱了出来。有人可能认为他不需要JSSE就可以保证网络的安全，但是由于SSL能够使用基于认证的Kerberos作为协议，它就被绑定在Kerberos/JGSS上。在这种情况下，依赖关系是可选择的。如果安装了Kerberos，那么SSL在对安全环境进行协商的时候就可以包括Kerberos。当没有安装的时候，它不会试图使用Kerberos进行协商。

我在上面提到了CORBA，因为它经常被当做JDK兼容性问题的替罪羊。人们已经提出了一个可能的兼容性模块，它可以兼容那些不再建议使用的、遗留的、过气的，以及其他一些代码。Sean Mullan和Vincent Ryan在这方面做了很好的工作，他们移除了JDK 7 b78中对过时的安全类依赖关系，所以这些类不需要存在于基本的模块中。另外一个可能需要移除的是遗留的sun.io转换器。我们在多年以前就应该摆脱这些转换器的束缚，但是由于还存在JDBC驱动而不能移除对它们的依赖。在sun.misc中也有很多不再使用的类，但是我们不能移除它们，因为有些怪异的应用程序会可能直接使用它们。过时的协议处理程序和内容处理程序是其他一些需要移除的东西。其实，我敢保证读者还能想到其他需要移除的内容。

在上面提到的内容中，值得注意的是模块不一定跟包(package)的边界对齐了。对于一个模块来说，在一个或者更多完整的包中包含所有的类非常必要，但是很多情况下这是不可能的。我上面提到的JavaBeans就是一个很明显的例子，人们必须把属性事件支持、内部标注与绑定在客户端区域的其他类区分开来。New I/O 以及 Logging的API具有管理接口，把这些管理接口分组加入到跟JMX以及java.lang.management相对应的管理模块中有更大的意义。我前面也提到过IIOP运输跟RMI编译器的分离。Rmic编译器将生成stub和the javax.management.remote.rmi包的关系，但是我们不想把这些分组到管理模块，因为它会对CORBA产生依赖。如果有人想对基本模块进一步分解，那么这将意味着要让java.util这样的包能够包含比API集合更多的东西。

总结

Jigsaw工程页面以及邮件列表开始入手。Jigsaw工具库里有一个名叫ClassAnalyzer的工具，我们一直使用它分析各种依赖关系以及指导各种变化。这个工具能分析模块的定义，并给每个模块产生几个文件，包括类的列表，以及它们之间的依赖关系。它能生成各种形式的总结文件，包括DOT文件，这对于那些想用肉眼看到各种依赖关系的人来说非常实用。上面提到的大部分工作可以认为是在移除依赖图表的优势。Mandy已经在着手下一步的工作了，改变版本的功能，让JDK能够生成模块而不是rt.jar。这需要几个步骤。最初的版本将生成JAR文件，但是最终我们一定能把它转换到一个更好的容器格式下。

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

【责任编辑：杨赛 TEL：(010)68476606】

点赞 0