集团网站,湖南郴州市,wordpress链接图像地址,购物网站开发在过去的几周中#xff0c;围绕即将发布的Java 9及其最著名的功能#xff1a;Java平台模块系统JPMS展开了激烈的辩论。 –以项目拼图Jigsaw的名称而闻名。 模块系统以正式规范过程的形式引入Java生态系统 – JSR –需要由专家组以最终形式批准。 在该专家组的其他成员中围绕即将发布的Java 9及其最著名的功能Java平台模块系统JPMS展开了激烈的辩论。 –以项目拼图Jigsaw的名称而闻名。 模块系统以正式规范过程的形式引入Java生态系统 – JSR –需要由专家组以最终形式批准。 在该专家组的其他成员中红帽和IBM的代表现已投票反对在他们认为尚未准备好生产的第一轮投票中拒绝Java的模块系统。 到底有什么毛病 即使在今天Java开发人员也对模块化非常熟悉。 像Maven这样的构建系统将代码组织为针对一组声明的依赖项进行编译的模块。 仅在运行时这些模块才放到这些编译时模块边界消失的类路径上。 使用Jigsaw模块路径可以作为此类路径的替代方式JVM在运行时为其保留了此类编译时边界。 通过不使用此模块路径应用程序应该像以前一样运行。 但是这依赖于JVM内部的API的应用程序除外。 即使将类路径专门用于无法再访问内部Java API的情况下Java标准库也始终作为模块的集合加载。 兼容性上的后一个限制引起了库和最终用户应用程序维护者的一些关注。 在这种情况下最近的反对意见与这些关注关系不大可能会令人感到惊讶。 虽然提到兼容性方面的问题但Red Hat和IBM都主要认为JPMS需要进一步扩展以允许与现有模块系统如JBoss模块和OSGi更好地集成。 还有什么问题需要解决 通过jar hell 开发人员通常描述Java应用程序需要两个不同版本的库来满足不同的传递依赖关系的情况。 使用类路径这是不可能的因为一个版本的库会遮盖第二个副本。 如果是第一次加载给定名称的类则系统类加载器将按其命令行顺序扫描jar文件并加载其发现的第一个类文件。 在最坏的情况下如果带阴影的jar文件包含一些链接到带阴影的jar类的专有类则可能会导致科学怪人功能。 但是更典型的是一旦触发了依赖于特定版本的功能就会导致运行时失败。 使用OSGi和JBoss模块可以部分解决此问题。 后一个模块系统允许每个库自己的类加载器加载一个库从而避免了负责类路径的系统类加载器。 使用这种方法可以通过隔离在单独的类加载器中来共存同一类的多个版本。 这样做例如两个库都可能都依赖于它们通常中断的Guava API的特定版本。 使用类加载器隔离在加载依赖类时任何库都会将调用委派给其所需的版本。 使用模块路径时JPMS当前不应用此类类加载器隔离。 这意味着Java 9无法解决jar hell的问题。与使用类路径相反JVM确实会检测到所描述的版本冲突并在启动时使应用程序失败而不是推测意外的兼容性。 为了强制执行此约束每个Java包名称现在都专有于特定模块或类路径。 因此两个模块不可能共享一个包。 如果不打算公开私有软件包则此限制也成立这是Jigsaw评论家认为当前模块设计的另一个缺陷。 错过了逃脱地狱的机会吗 为了使类加载器隔离有效必须使同一模块的版本永不交互。 而且尽管两个这样的版本当然永远不会直接交互但是不幸的是两个版本是不同模块的公共API的一部分比通常情况更常见。 例如如果两个库返回番石榴的实例Function类型每个模块的番石榴版本之间的版本冲突不能再使用的类加载器隔离即使解决了Function型没有这些版本之间切换。 在运行时任何已加载的类都被描述为其名称和类加载器的元组但是由于两个类加载器现在提供了Function类型应该解决哪个类型 实际上该描述的问题不能由模块系统解决。 相反模块系统可以发现此冲突并告知用户需要明确的解决方案。 这是通过JPMS的当前实现以及OSGi和JBoss模块实现的。 归根结底只有通过以兼容方式发展API才能避免版本冲突。 拼图游戏太简单了吗 尽管类装入器隔离模块系统仍然存在局限性但当前反对Jigsaw的论点主要围绕此问题。 此外拒绝Jigsaw的专家组成员指出缺少对循环模块依赖关系的支持“模块A依赖于B依赖于C依赖于A依赖”以及在创建模块图后无法更改模块图。 从技术角度来看当然可以添加这些功能。 实际上Java 9已经附带了模块构建器API该模块允许使用排他类加载器加载模块。 选择为模块路径保留单个类加载器没有技术限制。 相反该决定被Oracle认为是JVM的负责任选择。 在深入探讨这些论点之前我想声明我完全同意公司的推理。 类加载器隔离有什么问题 如前所述即使使用类加载器隔离也常常无法避免手动版本管理。 此外依赖具有不兼容版本例如Guava的通用API的库作者的确越来越掩盖了这种依赖性。 着色时将库的代码复制到单独的名称空间中从而使应用程序可以使用不同的名称而不是通过不同的类加载器来引用“其版本”。 当然这种方法有其自身的缺陷特别是当阴影依赖项使用JNI时。 另一方面这种方法克服了在使用具有冲突的共享依赖项的库时刚刚提到的类加载器隔离的缺点。 同样通过隐藏公共依赖关系库作者可以独立于部署方法而使用户免于潜在的冲突。 允许循环依赖既不会带来很大的技术挑战。 但是循环依赖关系很少见像Maven这样的许多构建系统都不支持它们。 通常可以通过将至少一个模块分成实现和API来将循环依赖关系重构为非循环依赖关系。 在这种情况下如果某个功能似乎很少引起人们的普遍关注那么我认为角落情况并不能证明其附加功能是合理的尤其是当类路径仍充当备用功能时。 而且如果最终决定是错误的则可以在以后的版本中始终启用循环依赖关系。 但是取消此功能将是不可能的。 最后动态模块提供的功能可能对多个应用程序有用。 根据我上一个项目的经验当您需要动态地重新部署具有生命周期的模块时OSGi是一个很好的选择。 也就是说大多数应用程序都是静态的没有充分的理由使用它。 但是通过添加对动态模块图的支持此功能的复杂性将转化为JPMS。 因此我认为暂时不使用此功能等到更好地理解其用途是正确的决定。 自然可访问的模块系统会提高采用率。 兼容性至上 这种不兼容性是否意味着OSGi和JBoss模块的终结 当然不是。 恰恰相反标准化模块描述符的引入为现有模块系统提供了机会。 使用OSGi时缺少描述包的清单标头是主要的痛点之一因为大量库没有考虑专有模块描述符。 通过引入标准化的模块描述符现有的模块系统可以通过使用后一个描述符作为模块描述的辅助来源来减轻此限制。 我毫不怀疑红帽和IBM出于最佳意图拒绝了JSR。 同时我不能同意对模块系统缺乏覆盖面的批评。 在我看来现有的变更对于Java生态系统的采用而言是充满挑战的尤其是最后一刻引入类装入器隔离具有带来意外意外的潜力。 有鉴于此我发现针对拼图的当前状态提出的论据不一致因为它批评了向模块过渡的复杂性但也要求对其进行扩展。 没有完善的模块系统 我个人认为目前的JPMS提案面临两个重大挑战。 不幸的是由于最近的讨论它们成为了背景。 自动模块 如果没有模块描述符则模块化代码只能以所谓的自动模块的形式引用非模块化jar文件。 自动模块没有任何限制并由其jar文件命名。 这对于最终用户应用程序的开发人员非常有用这些用户永远不会发布其代码以供其他应用程序使用。 但是库开发人员确实缺少一个稳定的模块名称来引用其依赖的自动模块。 如果发布它们将依赖稳定的文件名来获取依赖关系这很难假设。 对于采用Jigsaw而言这意味着一种自下而上的方法其中任何库作者只能在所有相关代码都已经模块化之后才能对其软件进行模块化。 为了简化过渡添加了一个清单条目该清单条目允许发布具有稳定自动模块名称的jar而无需模块化代码甚至迁移到Java9。这允许依赖此第一个库的其他用户使用具有稳定名称的库。对他们的代码进行模块化从而突破了自下而上的要求。 我认为让库维护者在迁移其代码以完全使用JPMS之前声明一个明确的模块名称非常重要并且我认为这是处理此问题的一种充分方法这不可能提供更好的解决方案。 反思和可及性 使用Jigsaw不再允许使用反射来访问非公共未导出的成员这是许多框架当前所认为的机会。 当然设置了安全管理器后即使在当今的Java版本中也无法进行这种访问但是由于很少使用安全管理器因此无需过多考虑。 对于Jigsaw这种默认设置是相反的在这种情况下需要显式打开用于这种反射访问的包从而影响许多Java应用程序。 总的来说我认为Jigsaw的封装比当前的通用开放性更好。 如果我想让Hibernate访问我的bean则JPMS允许我仅通过合格的出口将bean打开到Hibernate。 使用安全管理器即使不是不可能实现也很难控制这种细粒度的访问。 但是这种过渡会带来很多麻烦并且许多库的维护不够积极无法适应这些新要求。 因此添加此限制肯定会杀死某些原本可以提供价值的库。 此外仍然存在一些反射的用例。 对于模拟库Mockito我帮助维护例如我们需要一种在任何类加载器中定义类的方法。 这过去只能通过使用内部Java API来实现而目前还没有其他选择。 由于Mockito仅在测试环境中使用因此在这种情况下安全性无需关注。 但是由于sun.misc.Unsafe开放性我们已经依靠该开放性来实例化模拟类而无需构造函数调用因此我们可以通过使用其直接内存API更改其可访问性来简单地打开这些API。 当然这在接下来的几年中还不够好解决但是我坚信可以在完全删除不安全类之前解决这些问题。 作为一种可能性可以使用需要在命令行上明确解决的测试模块来扩展JVM并允许这种扩展访问。 另一种选择是要求任何测试运行程序都附加Java代理因为它们具有突破模块障碍的能力。 但是就目前而言任何维护的软件都有机会解决其非标准Java使用问题并在未来几年继续讨论缺少的API。 寻找共识 考虑到社交焦虑的计算机呆子的刻板印象软件开发可能是一件相当感性的事情。 甲骨文一直以来都是Java开发人员所讨厌的公司当前的讨论在一定程度上推动了这一潮流。 但是从Java作为一种语言和平台的成功来看我确实认为Oracle值得称赞的是它在管理方面的客观出色表现。 考虑到未来的成功当今破解软件是一项微妙而无济于事的任务。 任何重构正确但复杂的代码的人都应该同情这个挑战。 拼图项目经常因不必要的努力而受到批评我承认这种想法已经超出了我的想法。 但是归功于模块系统像CORBA或RMI这样的自重组件最终可以从JVM中删除。 随着模块化Java应用程序大小的隐式减小JVM对于在容器化应用程序和云计算中的使用变得越来越有吸引力这对于Oracle的市场策略而言肯定不是巧合。 虽然当然可以将这种工作进一步推迟到更高的Java版本但是JVM必须在某个时候解决功能的删除。 现在是一个好时机。 为了简化即将到来的过渡将重大更改降低到最小很重要。 因此我坚信扩展Jigsaw的范围并不符合更广泛的Java社区的最大利益。 最近投票的许多否决票都要求有关各方就悬而未决的问题达成共识。 不幸的是在只有一方放弃立场的情况下才能达成共识的情况下可以实施或放弃所讨论的功能。 考虑到典型的Java应用程序我希望Oracle不会通过范围扩展来满足需求只是为了确保对Jigsaw JSR进行成功的投票。 相反我想呼吁那些对JSR表示反对的专家组成员重新考虑他们对整个Java生态系统需求的投票因为现有企业模块解决方案的需求只是众多因素中的一个因素。 随着Java从商业应用程序到低延迟系统的广泛使用自然而然地不同的各方会为平台的发展确定不同的优先级。 我相信Oracle已经为服务于大多数用户的模块系统找到了共同点。 翻译自: https://www.javacodegeeks.com/2017/05/yet-another-jigsaw-opinion-piece.html
