是否有技术原因可以避免在大型Java项目中创建高度复杂的包依赖关系？

Question

我是现代Java编译器和虚拟机的新手，所以我很好奇，大型Java项目(5000+相当大的类)在编译期间和运行时会遇到哪些技术问题？

在大型C++项目中，如果远离大型项目中的无循环库(或包)依赖图，您可能会陷入技术麻烦(所有可维护性问题除外)。

一些例子

如果大多数源树是included

• linking，则
• 编译可能会耗尽内存，如果包含太多的对象存档(对象归档通常与C++项目中的包相关)

内联模板实例化大大加剧了这个问题。现代工作站不具备编译和链接一个项目的设备，该项目在构建的两个阶段都将5000个相当大的类中的大部分集合在一起。

我问过的Java开发人员并不认为技术限制是避免循环包依赖的原因(其他动机也适用)。有吗？

Answer 1

1. Java编译器(javac)不是同时编译所有类，而是一个接一个地动态地发现未编译或陈旧的.class文件。
2. 没有链接。相反，一旦编译，所有.class文件都打包在一个jar文件中。这基本上是一个ZIP压缩，甚至不需要这个步骤。

，

1. ，由于简单的语言语法和语义，它是相当简单的。没有太多的元编程、类型推断等。例如，Scala编译器要慢得多，因为语言本身更complicated.

。

尽管如此，我还是找不到编译大型、混乱的项目的任何技术限制。显然，构建时间会增长，一旦超过10分钟，就会变得很痛苦，但这并不是真正的问题。

真正的问题是源代码的可维护性，有复杂的、循环的、交叉的引用.主要而言，重构代码要困难得多。一旦项目达到一定的规模(5000+类可能在50万LOC左右)，开发人员将尝试将其分割成几个部分。提取库、模块和层。如果依赖关系如此强烈，这个过程几乎是不可能的。

Answer 2

Java中确实没有包依赖这类东西。只有类(和接口)依赖关系。当您在Java中导入一个包时，您只是告诉编译器如何解析名称(因此您不需要完全限定您使用的每个类或静态导入名)。

数千个类之间的循环依赖可能会使编译器陷入瘫痪。