我们讨论的一件事情，大家似乎都同意了，下一代模块看起来有些像JAR。但是，随后协议终止了。不同的是JAR的内容应该是什么样、如何表示导入、如何导出公共的内容。然而，大家对下代模块都有一个共识，我们至少要提供一个标志：我们选择圆角矩形。Jigsaw模块的图片看起来像：

　　这张图片看起来和类、包的图片有很大的不同，因为Jigsaw模块导出类型，但另一方面是他们的导入模块。从另一个角度来看，Java另人很惊讶，因为类和包模块导入、导出他们的内容。

　　对称性和论证

　　类型导入/导出成员、包导入/导出类型，下一代模块化似乎很自然，它导入/导出包。的确，Jigsaw导出类型（包的成员），仅仅导入模块（包的父类）。它主要表现在包不存在的时候。可以清楚的看到下面的UML图表，参照OSGi设计的Jigsaw（封闭的方块是抑制，开放的方块是同意）：

　　如果我们描述OSGi模块，它在Java中看起来像天然的接班人：

　　对称性不用论证，然而，历史已经为我们显示，对称性通常通向最简单的解决方案。在Java中，VM给我们很大的回旋余地来操纵类的可视性，执行非常有趣的内容变化。尽管一些变化非常有用（短期内的一些用例），但是，他们很少超过长期的成本开销，并且给我们增加 了复杂性。

　　我在1996年就喜欢上了Java，因为它比C++更实用。不幸地是，他们没有走完全程。在那段时间，Java原始类型和数据听起来是个不错的主意，但是，我们如今为这些变化付出了代价。看看泛型和反射。

　　所以，我们不应该使用包作为模块化导入/导出的粒度？包在Java中是最高级的模块，他们经常使用具有凝聚力的实体。例如，在JCP中，几乎所有的JSR都指定一个或多个语义和语法的包：JPA (javax.persistence.*)、JTA (javax.transaction.*)、JDBC (javax.sql)、XML解析 (javax.xml.parsing)等。

　　依赖javax.persistence 1.1.2替代从随机的提供者命名一些JAR不是一个伟大的想法？我们确实依赖我们的代码，这不是一个事实吗？为什么我要在Apache Geronimo、Oracle、JBoss或者SpringSource中做一个选择，我的代码中真的要依赖他们定义的javax.transaction包吗？

　　至少要有一些原因，为什么Jigsaw会偏离当年的Java架构如此之多。不幸地是，我从来都不能找到一些有意义的话。相反，偏离引起了两个严重的问题：

• 在模块化上表示导入，建立依赖平行宇宙
• 作为单元导出处理类，违反了包的模块化