庞大、整体化的JDK应该模块化


Sun公司的首席工程师——Mark Reinhold一直主张将Sun JDK模块化。他举例说明了复杂性如何损害这个平台，以及JDK 6 update 10版的Java Kernel和Quickstarter的功能只是解决了JDK长期关联成长导致的表面诟病。

Mark首先解释了JDK为何会成为现在这样庞大的状态：

JDK非常大，但还没有像宇宙这么大。

JDK很大是因为在过去13年里，Java SE平台已经从一个最初打算用于嵌入式设备的小系统发展成为横跨广阔领域、服务于广大需求的一套丰富的库集合。拥有这样一个庞大且功能强大的瑞士军刀真是难以置信的方便，不过尺寸却不合适。

他接着解释了由此导致的缺点：

JDK很大——同时也是紧密关联的。它作为一个整体的软件系统构建。在这种开发模式下，当编写新代码或者改进老代码的时候，很自然地会利用平台的其他部分，依靠Java虚拟机的灵活链接机制保证运行时一切都正常工作。

但是多年来，这种开发形式导致了API之间的意想不到的关联——和API的实现之间——这又增加了启动时间和内存占用。例如，一个简单的命令行“Hello, world!”程序，现在加载和初始化超过300个单独的类，尽管做出了更优秀的工程优化（比如类共享），但是在最新的桌面系统上仍然需要100毫秒。当然，对于更大的应用来说，情况会更糟糕。

Mark似乎认为JDK 6 update 10版中的Java Kernel和Quickstarter功能是不够的：

JDK 6 update 10版的Java Kernel和Quickstarter功能的确改善了下载时间和（冷）启动时间，至少对Windows用户来说是这样。这些技术也确实解决了长期关联成长的表面诟病，但是，没有解决根本问题。

模块化JDK——最有希望改进下载时间、启动时间和内存占用这些关键值的方法是正面解决根本问题：把JDK划分为一系列定义良好的、单独的、但是互相依赖的模块。

他又谈论了模块化对平台的好处：

把JDK分解为模块的过程会强迫所有意想不到的关联公开化，然后经过分析，多数会被隐藏或者消除。这反过来，会减少加载类的总数，从而改善启动时间和内存占用。 如果我们有一个模块化的JDK，在下载时，我们就会提供启动特定应用所需的那些模块，而不是整个JRE。Java Kernel是这种解决方案的第一步，使用定义良好的模块的进一步好处是下载流可以根据当前应用的特定需要提前定制。

Weijun对最初的帖子发表了意见，认为JDK的整体特性是由于Java没有管理依赖的合适方式导致的：

JDK很大是因为Java从来没有指定任何管理软件依赖的工业级方法。

因此，唯一可靠部署java栈的办法就是把它打包成一个巨大的怪物。

顺便说一句，只有SUN和其JDK是这样的。这种缺少依赖性管理的最坏结果不是导致JDK臃肿，而是所有带有硬编码类路径和大量分支的无法管理的应用（因为如果你无法独立的管理和更新依赖，你可能会分支出一个被迫绑定到应用的私有拷贝）。

你应该很容易理解为什么Java只存在于J2EE服务器中（服务器提供了基础java平台所缺少的管理功能）

GeekyCoder认为模块化的JDK对大多数开发人员来说可能不是最急需的：

虽然这很“酷”，但我怀疑这对大多数开发人员来说是否是最急需的。

我有一种不好的感觉，就是你可能会被少数对你博客的积极回应所影响，而不论他们是否代表了整个Java开发社区。

即使只是修复一个票数最多的bug也比仅仅搞“酷”要好得多。

我认为“倾听你的客户”只是一个过时的、封闭的、已经被彻底抛弃的想法，但是，看一看好的方面...你现在拥有两名声称乐于助人的开发人员。祝你好远。

Similarly Michael B似乎认为企业用户不关心模块化JDK：

模块化的JDK（或更确切地说JRE）对企业用户完全无关。我认为，企业用户喜欢JDK它现在的样子，因为模块意味着依赖，这听起来像“DLL地狱” 。现在JDK很容易分发和打补丁，这很重要。另外，Java具有良好的向上兼容性：不仅“编写一次，到处运行” ，而且还“编写一次，永远运行” ，这意味着巨大的投资回报率（ ROI ）。这是人们更喜欢Java而不是.NET的原因之一 。MS的战略一直是： “这是添加了最新功能的新版本，请修改和兼容你的所有应用。 ”MS技术太短命了。 Java平台目前已经模块化：模块是我的应用所需要的第三方库。我喜欢SUN的模式——只有这些库足够成熟了才会变成平台的一部分。 健壮性和可靠性是Java成功的关键。所以，请回去继续解决那些剩余的bug吧。我真的很喜欢JDK 6 update 10版的这方面功能。

查看英文原文：The Massive, Monolithic JDK should become Modular

相关内容