什么是网站备案,遵义网约车资格证,兰州400电话网站建设,前端特效网站通过提供Java 9 module-info.class来了解如何使用Gradle构建支持JPMS#xff08; Java平台模块系统 #xff09;的Java 6-8库。 介绍 如果您需要JPMS本身的介绍#xff0c;请查看此概述 。 这篇文章主要针对Java库维护者。 任何此类维护者都必须选择要针对的JDK#xff… 通过提供Java 9 module-info.class来了解如何使用Gradle构建支持JPMS Java平台模块系统 的Java 6-8库。 介绍 如果您需要JPMS本身的介绍请查看此概述 。 这篇文章主要针对Java库维护者。 任何此类维护者都必须选择要针对的JDK 针对最新的JDK JDK 11或刚刚发布的JDK 12 开发人员和用户可以使用新的API和更多功能。 但是这会阻止所有使用较旧JDK的用户使用该库。 那些较老的JDK仍然很受欢迎 在2018年约占95的份额 并预计在2019年将约90的 份额 。 因此对于许多图书馆维护者而言后者无疑是一个决定性因素 。 例如 vavr 1.0 旨在以JDK 11为目标 但最终将以JDK 8为目标 。 尽管如此还是建议为JPMS添加一些支持以期将来会被广泛采用我想从现在起5年以上。 Stephen Colebourne在这里描述了三个选项 不执行任何操作不建议。 最低要求在MANIFEST.MF文件中添加一个“ Automatic-Module-Name条目。 最佳添加一个针对JDK 9的module-info.class同时提供所有其余针对JDK 6-8 *的类。 在这里我们将深入研究如何实现选项3最佳选择。 *我写的是JDK 6-8而不是JDK 5-8因为在JDK 11中 javac的--release选项限制为6-11。 理由 不过在深入研究“如何”之前让我们先略过“为什么”。 为什么JPMS完全值得打扰 主要是因为JPMS 提供强大的封装 防止引入拆分包 确保更快的类加载 。 综上所述JPMS 非常酷 更多信息请参见此处 鼓励我们采用JPMS是我们的最大利益 因此我鼓励Java 6-8库的维护者充分利用JPMS 自己针对模块的JDK 6-8类和其他模块编译module-info.java 对于他们的用户通过提供module-info.class来使库在module-path上正常工作。 可能的行为 可以在两个位置找到module-info.java 与其他所有类在src/main/java 在单独的“源集”中例如src/main/java9 。 我喜欢选项1因为它看起来更自然。 module-info.class可以在两个地方结束 在根输出目录以及所有其他类中 在META-INF/versions/9 多发行版JAR又名MRJAR 阅读了塞德里克·尚波 CédricChampeau关于MRJAR的帖子后 我对MRJAR颇为怀疑因此我更喜欢选项1。 但是请注意 Gunnar Morling报告说选项1存在一些问题。另一方面我希望距JDK 9发行1.5年后所有主要库都已打补丁以正确处理module-info.class 。 每个构建工具的示例库 本节包含一些在针对JDK 6-8时提供module-info.class的库示例。 蚂蚁 Lombok JDK 6 main JDK 9 module-info.class 马文 ThreeTen-extra JDK 8 main JDK 9 module-info.class Google Gson –尚未发布JDK 6 main JDK 9 module-info.class SLF4J –尚未发布 META-INF/versions/9 JDK 6 main JDK 9 module-info.class 请注意 Maven编译器插件提供了如何提供这种支持的示例 。 摇篮 我还没有找到任何流行的库使用Gradle提供这种支持请注释如果您知道的话。 我只知道vavr试图这样做 2230 。 Gradle中的现有方法 修改 ModiTect 由Gunnar Morling编写 及其Gradle插件 由Serban Iordache编写 具有一些非常酷的功能 。 本质上ModiTect基于特殊符号或直接从module-info.java 生成 module-info.class -info.class 而无需使用javac 。 但是在从module-info.java直接生成的情况下ModiTect有效地复制了javac所做的操作同时引入了自己的问题例如90 。 这就是为什么我觉得它不是最好的工具。 Badass Jar插件 Serban Iordache还创建了一个Gradle插件 该插件可以“无缝创建针对9之前的Java版本的模块化jar”。 看起来不错但是 为了构建适当的JAR并验证module-info.java Gradle构建必须运行两次 它不使用javac的--release选项该选项保证仅引用正确的API 它不使用javac来编译module-info.java 。 同样我觉得这里不是正确的工具。 JpmsGradlePlugin 这是我最近的发现 JpmsGradlePlugin由阿克塞尔Howind 。 该插件可以做一些不错的事情例如从javadoc任务中排除module-info.java 但是 它也不使用javac的--release选项 它不完全支持Java模块化例如模块修补 感觉还不够成熟 难以遵循的代码非标准行为例如直接调用javac 。 Gradle中的拟议方法 摇篮脚本 最初我想通过添加自定义源集来做到这一点 。 但是事实证明这种方法会引入不必要的配置和任务 而我们真正需要的只是一个额外的任务它正确地“钩住”了构建生命周期 。 结果我想到了以下几点 将compileJava配置为 排除 module-info.java 使用--release 6/7/8选项。 添加一个名为compileModuleInfoJava的新JavaCompile任务并将compileModuleInfoJava配置为 仅包含 module-info.java 使用--release 9选项 使用compileJava的类路径作为--module-path * 使用compileJava *的目标目录 取决于 compileJava * 。 配置classes任务以依赖于compileModuleInfoJava 。 以上内容在Groovy DSL中表示为Gradle脚本可以在我的Stack Overflow答案中找到。 *这三个步骤对于compileModuleInfoJava查看由compileJava编译的类是compileJava 。 否则由于未解析的引用 javac将无法编译module-info.java 。 请注意在这种配置中每个类仅被编译一次 与推荐的Maven Compiler Plugin配置不同 。 不幸的是这样的配置 在存储库之间不容易重用 不完全支持Java模块化。 Gradle模块插件 最后有一个插件 Gradle Modules Plugin 它为Gradle添加了对JPMS的完全支持由Java 9 Modularity的作者Sander Mak和Paul Bekker创建 。 该插件仅不支持本文所述的方案。 因此我决定 通过此插件提交功能请求 72 提供具有72的完整实现的“拉取请求”作为“概念证明” 73 我尽力做出这些高质量的贡献。 最初的反馈意见非常受欢迎 甚至Mark Reinhold都喜欢。 谢谢 现在我正在耐心地等待进一步的反馈 以及潜在的改进要求然后才能希望合并PR。 摘要 在本文中我展示了如何使用Gradle构建Java 6-8库以便将module-info.java编译为JDK 9格式JPMS支持而将所有其他类编译为JDK 6-8格式。 我还建议对这种配置使用Gradle Modules插件 一旦我的PR合并并且发布了新的插件版本。 翻译自: https://www.javacodegeeks.com/2019/03/building-java-6-8-libraries-jpms-gradle.html
