是否存在技术原因来避免在大型 Java 项目中创建高度混乱的包依赖关系？
我对现代 Java 编译器和虚拟机很陌生，所以我很好奇，随着包依赖关系的棘手问题的增长，大型 Java 项目（5000 多个相当大的类）在编译期间和运行时会遇到哪些技术问题？
在大型 C++ 项目中，如果您远离大型项目中的非循环库（或包）依赖关系图，您可能会陷入技术麻烦（除了所有可维护性问题）。
如果包含大部分源代码树，某些示例
- 编译可能会耗尽内存，
- 如果包含太多对象存档（对象存档通常与 C++ 项目中的包相关），链接也会耗尽内存
。内联模板实例化会大大加剧该问题。现代工作站不具备编译和链接项目的能力，该项目在构建的任一阶段都将 5000 个相当大的类中的大部分集中在一起。
我询问过的 Java 开发人员并不认为技术限制是避免循环包依赖的理由（其他动机也适用）。有吗？
I'm new to modern Java compilers and Virtual Machines, so I'm curious, what technical issues do large Java projects (5000+ sizable classes) encounter, during compilation and at runtime, as the gordian knot of package dependencies grows?
In large C++ projects, you can get yourself into technical trouble (all maintainability concerns aside) if you stray far from an acyclic library (or package) dependency graph in large projects.
Some examples
- compilation can run out of memory if most of a source tree is included
- linking can too if too many object archives are included (object archives generally correlate with packages in C++ projects)
The problem is considerably exacerbated with inline template instantiation. Modern workstations aren't equipped to compile and link a project that pulls most of 5000 sizable classes together in either phase of the build.
The Java developers I've asked do not believe technical limitations are a reason to avoid circular package dependencies (other motivations apply). Are there any?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Java 编译器 (
javac) 不会同时编译所有类，而是逐一编译，动态发现未编译或陈旧的.class文件。< /p>没有链接。相反，所有
.class文件在编译后都会打包在jar文件中。这基本上是 ZIP 压缩，甚至不需要此步骤。由于语言语法和语义简单，Java 编译器相当简单。没有太多的元编程、类型推断等。例如，Scala 编译器要慢得多，因为语言本身要复杂得多。
话虽这么说，我找不到编译大型、复杂项目的任何技术限制。显然，构建时间会增加，一旦超过 10 分钟，就会变得很痛苦，但这并不是真正的问题。
纠结、循环、交叉引用的真正问题是源代码的可维护性。主要是重构代码要困难得多。一旦项目达到一定规模（5000 多个类可能约为 50 万个 LOC），开发人员将尝试将其拆分为多个部分。提取库、模块和层。如果依赖关系如此强烈，这个过程几乎是不可能的。
The Java compiler (
javac) does not compile all the classes at the same time, but rather one by one, dynamically discovering uncompiled or stale.classfiles.There is no linking. Instead all the
.classfiles are packaged together in ajarfile once compiled. This is basically a ZIP compression and this step isn't even required.The Java compiler is moderately simple due to simple language syntax and semantics. There isn't much metaprogramming, type inference, etc. Scala compiler, for example, is much slower because the language itself is much more complicated.
That being said I can't find any technical limitations of compiling large, tangled projects. Obviously the build time grows and once it exceeds 10 minutes it becomes a pain, but that isn't really an issue.
The real problem with tangled, circular, cross-references is source code maintainability. Mainly it is much harder to refactor code. Once the project reaches certain size (5000+ classes is probably around half million LOC) developers will try to split it into pieces. Extract libraries, modules and layers. If the dependencies are so strong, this process is close to impossible.
Java中确实不存在包依赖这样的东西。只有类（和接口）依赖关系。当您在 Java 中导入包时，您只是告诉编译器如何解析名称（因此您不需要完全限定您使用的每个类或静态导入名称）。
数千个类之间的循环依赖可能会让编译器崩溃。
There is really no such thing as package dependencies in Java. There are only class (and interface) dependencies. When you import a package in Java, you are only telling the compiler how to resolve names (so you don't need to fully qualify every class or static import name you use).
Circular dependencies between thousands of classes would probably bring a compiler to its knees.