是否存在技术原因以避免在大型Java项目中创建高度纠结的包依赖项？

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了是否存在技术原因以避免在大型Java项目中创建高度纠结的包依赖项？，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含1204字，纯文字阅读大概需要2分钟。

内容图文

我是现代Java编译器和虚拟机的新手,所以我很好奇,大型Java项目(5000个大型类)在编译期间和运行时遇到了哪些技术问题,因为包依赖关系的gordian结？

在大型C项目中,如果您远离大型项目中的非循环库(或包)依赖关系图,您可能会遇到技术问题(除了所有可维护性问题).

一些例子

>如果包含大部分源树,则编译可能会耗尽内存
如果包含太多的对象归档,也可以链接(对象归档通常与C项目中的包相关)

内联模板实例化会严重加剧这个问题.现代工作站不具备编译和链接项目的能力,该项目在构建的任一阶段将大多数5000个相当大的类拉到一起.

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

解决方法:

> Java编译器(javac)不会同时编译所有类,而是逐个编译,动态发现未编译或过时的.class文件.
>没有链接.相反,所有.class文件在编译后一起打包在jar文件中.这基本上是ZIP压缩,甚至不需要此步骤.
>由于简单的语言语法和语义,Java编译器非常简单.没有太多的元编程,类型推断等等.例如,Scala编译器要慢得多,因为语言本身要复杂得多.

话虽如此,我找不到编译大型纠结项目的任何技术限制.显然,构建时间会增加,一旦超过10分钟就会变得很痛苦,但这不是一个真正的问题.

纠结,循环,交叉引用的真正问题是源代码可维护性.主要是重构代码要困难得多.一旦项目达到一定的规模(5000个类可能是大约50万LOC),开发人员将尝试将其分成几部分.提取库,模块和图层.如果依赖关系如此强大,那么这个过程几乎是不可能的.

内容总结

以上是互联网集市为您收集整理的是否存在技术原因以避免在大型Java项目中创建高度纠结的包依赖项？全部内容，希望文章能够帮你解决是否存在技术原因以避免在大型Java项目中创建高度纠结的包依赖项？所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端