依赖包似乎很明显，我有时总是有点错愕，为什么要激烈的反对如此简单的想法。所以，让我们看一看反对派的论点。

　　最常见的异议是，它太难了。有很多简单手工指定的包。我同意。幸好，我们已经指定了我们的导入：

　　对我们来说，更妙的是，编译器会通过实现包，在我们的类中记录每个类的引用。像工具BND和SpringSource的Bundlor都可以从类属性中记录这些依赖，生成适当的元数据模块，不需要再次指定依赖。

　　被引用的公共包需要进行版本控制。然而，这个工作通常少于维护模块版本。包版本很容易实现自动化确认，因为，定义的公共共享包的变化率明显小于模块，聚合了很多实现包，以及API包。（这总是让我很困惑，那些版本号的实际意义是什么）

　　Jigsaw模型建立了一个平行宇宙，当依赖包存在时，就不会消失。所以，现有模型上的额外的宇宙是如何使事情变得简单？

　　第二个异议是，依赖包可以找到包含复杂工具包的产品。论点是开发者为产品指定一些逻辑名字，我们可以很容易的通过URL地址仓库，映射这个名字到一个URL地址。因此，我们可以不用任何逻辑，得到这个仓库。

　　简单是最重要的，但是简单而不要出错，破坏的设计是不正确的。例如Maven，支持版本排序，因此不能在构造URL。版本排序需要相同的逻辑，因此要找到包的提供商。把逻辑拴在一个过分简单的模型上比从一开始就考虑到这一点还要难。

　　第三个异议是，依赖包建立一个丰富的可用空间集合，能够提供这些包。解决这个集合的最佳方案是NP-complete问题，所以，它是真的、真的、真的太难了。废话吗？这好象不是解决通常涉及的数以十万计的包。即使在很系统中大量的共享包是不足数千计、或者更少的提供商。

　　在基于用户服务的模块化系统中，需求少竽共享，这个数字明显偏低。很多问题可能会是NP-complete的，但是，实际的情况是从没有运行在末端，平时都是NP-complete发出假警报。

　　Apache的Felix和Equinox可以在很短的时间内解决在型的系统。曾经使用过一个本地系统，在很短的时间内，就给出了一个非常好的解决方案？他们搜索的空间比我们大、复杂得多。

　　即使有很多包源于那些产品，没有任何原因，解析过程必须发生在运行时。这是一个典型的OSGi用法模型，因为它允许我们具有动态性。然而，动态性是静态的超集，静态是比较容易的部分。例如，如果产品和测试需求并没有相同的解决方案，那么，系统可以在未来解决，而不是影响运行时。

　　结论

　　OSGi开始于依赖包，而不需要太多的思考。只要自然就好。我们没有足够的洞察力，我现在可以分享在这篇文章中。然而，在2003年，我用Eclipse的时候，让我大吃一惊，他们坚持在模块中用依赖。我为他们提供所需的bundle，这很明显，如果他们不做让步，很可能会失去他们。

　　虽然在极少数情况下，所需的bundle是有用的，总的来说，后来的OSGi规范是很详细的。例如，在之前的OSGi版本中，我们想把合成模型放入到一套bundle中，看起来就像一个单独的bundle。依赖包可以精确的处理它。整合完所需的bundle和碎片的合成物，使我又增加了一些白发，因为，我们把它移到核心处。

　　最后，不同模块的图表看起来就像一个IQ测试，为什么不这样处理它呢？下列哪一种模块化不合适呢？

　　毫无疑问，在我看来Jigsaw有一个严重的错误，它忽略了Java语言方面已经存在的模块。打破包的隐私，在设计中忽略包，不必建立另人头痛的、而又几乎没有收获的东西。

　　可能因为历史的原因，VM模块化需要分割包，就像James Gosling认为的那样，原始的东西是支持90年代硬件的关键。Smalltalk已经证明，原始的会隐藏在背后，影响着面向对象观，在相同的方式下，OSGi已经证明了，分割包是没有必要的。遗憾的是，忽视这些教训，会把Java社区处于危险之中。