海南省住房与城乡建设部网站,wordpress播放歌,网站在线开放端口,江苏中星建设集团网站什么是JAR地狱#xff1f; #xff08;或者是classpath地狱#xff1f;还是依赖地狱#xff1f;#xff09;在考虑使用Maven或OSGi等现代开发工具时#xff0c;哪些方面仍然有意义#xff1f; 有趣的是#xff0c;似乎没有对这些问题的结构化答案#xff08;即#… 什么是JAR地狱 或者是classpath地狱还是依赖地狱在考虑使用Maven或OSGi等现代开发工具时哪些方面仍然有意义 有趣的是似乎没有对这些问题的结构化答案即即使第二页也没有希望的头条新闻。 该职位应填补这一空白。 总览 我们将从构成JAR地狱的一系列问题开始暂时忽略构建工具和组件系统。 当我们评估当前的状况时我们将回到第二部分。 杰尔·地狱 JAR Hell是一个可爱的术语指的是Java的类加载机制的特性所引起的问题。 其中一些相互依存。 其他人是独立的。 未表达的依赖性 JAR无法以JVM可以理解的方式来表示它依赖的其他JAR。 需要一个外部实体来识别和实现依赖关系。 开发人员必须通过阅读文档找到正确的项目下载JAR并将其添加到项目中来手动执行此操作。 可选的依赖项如果开发人员要使用某些功能则JAR可能仅需要另一个JAR会使过程进一步复杂化。 运行时在需要访问依赖之前将不会检测到它们。 这将导致NoClassDefFoundError崩溃正在运行的应用程序。 传递依存关系 为了使应用程序正常工作可能只需要少数几个库。 每个反过来可能需要少量其他库依此类推。 由于未表达的依赖关系的问题变得更加复杂因此它变得越来越费力且容易出错。 遮蔽 有时类路径上的不同JAR包含具有相同完全限定名称的类。 可能由于不同的原因而发生这种情况例如当同一库有两个不同版本时或者当胖JAR包含也作为独立JAR引入的依赖项时或者当一个库被重命名并在不知不觉中两次添加到类路径时。 因为将从类路径上的第一个JAR加载类以包含它们所以该变体将“遮盖”所有其他类并使它们不可用。 如果变体在语义上有所不同则可能导致从微妙到通知错误的行为到破坏破坏性错误的一切。 更糟糕的是此问题本身表现出来的形式似乎不确定。 这取决于搜索JAR的顺序。 这在不同的环境中可能完全不同例如在开发人员的IDE和最终将运行代码的生产机器之间。 版本冲突 当两个必需的库依赖于第三个库的不同的不兼容的版本时就会出现此问题。 如果两个版本都存在于类路径中则该行为将不可预测。 首先由于存在阴影两个版本中都存在的类将仅从其中一个加载。 更糟糕的是如果访问一个中存在但另一个不存在的类则该类也将被加载。 因此调用库的代码可能会同时找到这两个版本。 由于需要不兼容的版本如果缺少其中一个版本则该程序很可能无法正确运行。 同样这可以表现为意外行为或NoClassDefFoundErrors。 复杂类加载 默认情况下所有应用程序类均由同一类加载器加载但是开发人员可以自由添加其他类加载器。 这通常是通过组件系统和Web服务器之类的容器完成的。 理想情况下这种隐式使用对应用程序开发人员是完全隐藏的但是众所周知 所有抽象都是泄漏的 。 在某些情况下开发人员可能会明确添加类加载器以实现功能例如允许其用户通过加载新类来扩展应用程序或者能够使用具有相同依赖性的冲突版本。 无论多个类加载器如何进入画面它们都可以Swift导致显示出意料之外且难以理解的行为的复杂机制。 类路径地狱和依赖地狱 Classpath地狱和JAR地狱本质上是同一件事尽管后者似乎更加关注由复杂的类加载器层次结构引起的问题。 这两个术语都特定于Java和JVM。 另一方面 依赖地狱是一个使用更广泛的术语。 它描述了软件包及其依赖项的一般问题适用于操作系统以及各个开发生态系统。 考虑到它的通用性它并不涵盖特定于单个系统的问题。 从上面的列表中它包括可传递的和可能未表达的依赖关系以及版本冲突。 类的加载和屏蔽是Java特定的机制依赖地狱将不会涵盖这些机制。 发布时间由惠康图书馆在CC-BY 4.0 事态 构建工具 查看问题列表我们看到构建工具如何帮助解决其中的一些问题。 它们擅长使依赖关系显式化以便可以沿着传递依赖关系树的无数边沿搜寻每个所需的JAR。 这在很大程度上解决了未表达和传递依赖的问题。 但是Maven等。 对阴影不做任何事情。 尽管它们通常致力于减少重复的类 但不能阻止它们 。 除了指出版本冲突之外构建工具也无助于解决版本冲突。 而且由于类加载是运行时构造因此它们也不涉及。 组件系统 我从未使用过OSGi或Wildfly之类的组件系统因此无法证明它们的工作情况。 从他们的说法看来他们似乎能够解决大多数JAR地狱问题。 但是这带来了额外的复杂性并且经常要求开发人员更深入地研究类加载器机制。 具有讽刺意味的是上面的列表中也有一点。 但是无论组件系统是否确实在很大程度上缓解了JAR地狱的痛苦我的印象是绝大多数项目都没有使用它们。 在这种假设下绝大多数人仍然遭受与类路径有关的问题。 这在哪里离开我们 由于它们未被广泛使用因此组件系统不会影响大局。 但是构建工具的普遍存在大大改变了JAR地狱不同圈子的严重性。 我参与或听说过的任何构建工具都不支持的项目都花费了大量的时间来处理来自未表达或可传递依赖的问题。 阴影有时会抬起丑陋的头需要花费不同的时间来解决-但最终总是如此。 版本冲突是JAR地狱中最棘手的问题。 但是每个项目迟早都要依靠相互冲突的版本进行斗争并且必须做出一些艰难的决定才能解决这些问题。 通常必须推迟某些所需的更新因为这将强制执行当前无法执行的其他更新。 我敢说对于大多数大小合适的应用程序服务和库版本冲突是何时以及如何更新依赖项的主要决定因素之一。 我觉得这是无法忍受的。 对于非平凡的类加载器层次结构我经验不足无法评估它们有多少重复出现的问题。 但是考虑到我迄今为止从事的所有项目都不需要它们我敢说它们并不常见。 在网络上搜索使用它们的原因通常会发现我们已经讨论的内容依赖关系导致版本冲突。 因此根据我的经验我会说版本冲突是JAR地狱中最棘手的问题。 反射 我们已经讨论了JAR地狱的构成要素 未表达的依赖性 传递依赖 遮蔽 版本冲突 复杂类加载 根据为游戏带来的构建工具和组件系统以及它们的使用范围我们得出结论很大程度上解决了未表达的和可传递的依赖关系这至少掩盖了缓解和复杂类加载的不常见性。 这使版本冲突成为JAR地狱中最有问题的方面影响了大多数项目中的日常更新决策。 翻译自: https://www.javacodegeeks.com/2015/10/jar-hell.html
