把类型导入嵌入类的属性中，为类型-安全代码完全指定最小的依赖关系图：“把你的代码给我，我会告诉你，你依赖什么。”虽然类的属性只包含类型的名字，Java类型意味着包作为名字的一部分。关系完全是封闭的。

　　包是模块化的，它实际的内容必须以一个黑盒子形式处理，不能控制它、甚至不能在外边观看它。模块层是私有设计选择，由设计者来决定。在模块化系统中，导入类型意味着导入一个完整的包。

　　因此，可以从你的类型-安全代码中构建一个完整的关系图。在图表上边，Jigsaw建立了一个模块关系图表，以平衡你的代码的依赖、和重叠的代码的依赖。

　　Jigsaw模块导入另一个模块，使用这些信息建立一个模块的路径。VM找到模块的路径，应该在那么模块中找到请求类型。例如，模块X寻找发生在模块C中的类型p.T。VM可以找到这些类型，通过搜索模块A、然后模块B、最终在模块C中找到它，下面的图表中描述。

　　Java语言中，模块C和类型p.T没有包含关系。保持相同的依赖性，为错误提供两次充足的机会，因为在两个体系中没有直接的语言关系，编译器无法验证他们之间的关系。

　　在这篇文章中，我认为一个方法、类和包必须视为一个原子处理。挑选和选择是不允许的。要么全有，要么全无。Java模块也是这样的吧？JLS既没有Jigsaw的规则，也没有OSGi的bundle。所以，在这个例子中，我们实际上可以允许包移向模块间。

　　我们甚至可以允许多个bundle导出相同的包。包是原子的，对于无论什么来原的包来说，都具有相同的访问规则。可能有限制，例如内部包的依赖，但是，他们是模块化设计的一部分，因此不能在逻辑上终止依赖。

　　在模块化之间能够移动包，甚至在不同的模块间复制他们，这是一个强大的概念，可以用来抗衡专家下载互联网而引起的短暂的依赖问题。

　　不是专家下载互联网——而是人们下载互联网！这是真实的，事实上，尽管专家共享相同的平行宇宙依赖模型，使它在Jigsaw设计中很容易继续那些依赖。所以专家已经表明，产品应该更好的设计，以减少他们的传递依赖。这需要重构现有的产口。

　　例如，一个模块被分为两个模块，因为原来是一个非常大的库中的一个单独的包，所以，让我们说，我们把模块B重构成模块B和模块C，并包含有引起问题的包。

　　在Jigsaw中，通过我们所有的依赖重构波痕，就像他们在模块B上表达他们的依赖。模块依赖图表不能表达代码的依赖，所以，我们必须为所有的用户解释（如果我们能捞到他们）发生了什么事情，他们也包括模块C。在这个例子中，我们必须更新模块A在模块B、C上的依赖，使之成为一个模块版本。因为我们已经改变了A，我们必须找到它所有的依赖，他们也必须更新。

　　然而，当我们看到里边的模块，实际的依赖是模块A不在依赖模块B，只依赖的包y移向模块C。如果我们能在包y上表述这个依赖，模块A根本不会对重构的模块B产生影响；解析器会自动把它绑定到模块C，而不是模块B。下图是描述：

　　模块依赖的平行宇宙建立了一个脆弱的宇宙模型。即使是所有依赖的监控改变、模块波痕的重构。很难估算波痕所引起的开销。

　　违反包的模块化

　　Jigsaw为对称的其他问题是，它违反了包的模块化。Jigsaw导入模块化，并且导出类型。包省去了设计，因此两种不同的Jigsaw模块可以把类型添加到相同的包。

　　模块的主要优点是更改私有的部分，而不影响其他模块。然而，如果两种不同的产品可以捐献出相同的部分，分享包，那么我们不在有隐私。

　　例如，一个包实现了复杂的类型，使用真实的和虚拟的浮点数。有一些包的私有属性，一些其他的类也在相同的包里（复杂的Vector类），出于性能的原因，可以直接操纵这些属性。如果我们以模块的形式处理包，我们可以改变虚拟的、真实的部分的特性，因为我们知道包中的所有类都可能会在我们的控制下压缩。

　　然而，如果一些其他人引用我们的包（如复杂的矩形），我们就不会再优化或者重构它，因为我们不知道谁依赖我们的包。即使我们做了，我们也不能确保他们会适应我们的改变，所以，我们通常在产品中丢弃它。