[spring-projects/spring-boot]允许使用 Java 16 构建项目

你好，

此 PR 使我们对 JDK 16 的支持更进了一步（参见 #24402）。

我正处于这样一个阶段，我的机器出现随机故障，似乎与网络错误和超时有关，所以我既有信心又迫切地想分享我的初稿。

本质上，PR 用buildJavaHome一个新属性取代了原来的功能toolchainVersion，该属性控制是否应该为编译、javadoc 和测试运行配置可选工具链。

我应该指出，spring-boot-gradle-plugin有多个问题。当前版本都不支持 JDK 16，因此很多测试失败。不幸的是，您不能在中提供空流GradleCompatibilityExtension.provideTestTemplateInvocationContexts。我有一些 hacky 代码可以解决这个问题，但我认为一个简单的排除就足够了。例如，我使用了以下内容：

./gradlew build -x :spring-boot-project:spring-boot-tools:spring-boot-gradle-plugin:test -x :spring-boot-project:spring-boot-tools:spring-boot-gradle-plugin:validatePlugins -PtoolchainVersion=16

如您所见，我validatePlugins也排除了该任务，该任务由于https://github.com/gradle/gradle/issues/15538而失败。

不过，最大的问题还在于其他方面。在 JDK 16 和更具体的JEP-396中，我们默认启用了强封装。这破坏了很多测试和库。仅举几例：

AbstractServletWebServerFactoryTests由于该字段被重置而导致的任何情况URL.factory。
CliTester出于类似的原因
JsonbTesterTests由于Johnzon 中的一个错误
由于https://github.com/spring-projects/spring-ldap/issues/570，进行了几个与 LDAP 相关的测试
...

我决定添加--illegal-access=warn，以便我们收到警告，但同时暂时允许访问。

请随意使用此 PR 进行测试。再说一遍 - 我今天没有一次测试是成功的，但所有测试失败都是随机的，并且在单独运行时都是成功的。

下一步

如果这个 PR 最终被合并，我会解决实际的管道问题。我认为这对这个 PR 来说可能有点多，因为我需要向 CI 镜像添加辅助 JDK。（不过我希望可以重用我过去为 Boot 构建的一些逻辑）

请告诉我你的想法。 Christoph

dreis2211

非常感谢@dreis2211。以下是针对建议更改的构建扫描：https://ge.spring.io/s/ovgtv4h7lapkc。

CLI 中的失败似乎是由于 Groovy 不支持 Java 16 字节码。测试JarCommandIT失败似乎是由于 Groovy 的 ASM 版本不支持 Java 16 字节码。从测试的输出中看不出来，但在我的 IDE 中运行后，命令的输出如下jar：

Caused by: java.lang.IllegalArgumentException: Unsupported class file major version 60
    at groovyjarjarasm.asm.ClassReader.<init>(ClassReader.java:196)
    at groovyjarjarasm.asm.ClassReader.<init>(ClassReader.java:177)
    at groovyjarjarasm.asm.ClassReader.<init>(ClassReader.java:163)
    at groovyjarjarasm.asm.ClassReader.<init>(ClassReader.java:284)
    at org.codehaus.groovy.ast.decompiled.AsmDecompiler.parseClass(AsmDecompiler.java:81)
    at org.codehaus.groovy.control.ClassNodeResolver.findDecompiled(ClassNodeResolver.java:251)
    at org.codehaus.groovy.control.ClassNodeResolver.tryAsLoaderClassOrScript(ClassNodeResolver.java:189)
    at org.codehaus.groovy.control.ClassNodeResolver.findClassNode(ClassNodeResolver.java:169)
    at org.codehaus.groovy.control.ClassNodeResolver.resolveName(ClassNodeResolver.java:125)
    at org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveClassNullable(AsmReferenceResolver.java:57)
    at org.codehaus.groovy.ast.decompiled.Annotations.createAnnotationNode(Annotations.java:40)
    at org.codehaus.groovy.ast.decompiled.DecompiledClassNode.addAnnotations(DecompiledClassNode.java:268)
    at org.codehaus.groovy.ast.decompiled.DecompiledClassNode.lazyInitSupers(DecompiledClassNode.java:184)
    at org.codehaus.groovy.ast.decompiled.DecompiledClassNode.getInterfaces(DecompiledClassNode.java:98)
    at org.codehaus.groovy.ast.ClassNode.getInterfaces(ClassNode.java:375)
    at org.codehaus.groovy.ast.ClassNode.getAllInterfaces(ClassNode.java:438)
    at org.codehaus.groovy.ast.ClassNode.getAllInterfaces(ClassNode.java:440)
    at org.codehaus.groovy.ast.ClassNode.getAllInterfaces(ClassNode.java:430)
    at org.codehaus.groovy.control.ResolveVisitor.setRedirect(ResolveVisitor.java:526)
    at org.codehaus.groovy.control.ResolveVisitor.resolveNestedClass(ResolveVisitor.java:485)
    at org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:462)
    at org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:428)
    at org.codehaus.groovy.control.ResolveVisitor.resolveOrFail(ResolveVisitor.java:343)
    at org.codehaus.groovy.control.ResolveVisitor.visitAnnotations(ResolveVisitor.java:1330)
    at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:51)
    at org.codehaus.groovy.control.ResolveVisitor.visitClass(ResolveVisitor.java:1465)
    at org.codehaus.groovy.control.ResolveVisitor.startResolving(ResolveVisitor.java:230)
    at org.codehaus.groovy.control.CompilationUnit$13.call(CompilationUnit.java:700)
    at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:965)
    ... 17 more

ASM 已支持 Java 16，但尚未发布。Framework 正在通过修补其自己的 ASM 版本来避免此问题，以便在发布之前引入最新更改。预计 Java 16 的 ASM 版本将“与 JDK 16 同时发布”，因此我们可能不得不暂时跳过 Java 16 上的测试，忍受这种情况。

wilkinsona

@wilkinsona 谢谢。我想知道为什么你提到的测试在我的计算机上没有失败。

但是没有看到工具链的迹象，我想我会带回一个自定义值。

dreis2211

预计 Java 16 的 ASM 版本将“与 JDK 16 同时发布”，因此我们可能不得不暂时忍受这种情况，跳过对 Java 16 的测试。

ASM 方面的事情似乎比上面链接的票所暗示的进展更快。根据https://asm.ow2.io/versions.html，包含 Java 16 支持的 ASM 9.0 于 9 月发布。

wilkinsona

但是没有看到工具链的迹象，我想我会带回一个自定义值。

我也看不到任何迹象。我向 Gradle 团队提出了这个问题，他们确认它尚未出现在构建扫描中。他们建议暂时使用自定义值。

wilkinsona

我想知道为什么你提到的测试在我的计算机上没有失败。

我也是。结果发现中有一个错误CommandLineInvoker。如果构建输出中有多个 zip，它将使用找到的第一个，但这可能不是正确的。因此，测试使用的是 2.4 的 CLI 和 Groovy 2.5.x。它们通过了 2.5 的 CLI 和 Groovy 3.0.x。

wilkinsona

@wilkinsona 谢谢你的检查。我确实clean在中间跑了几圈。

我将自定义工具链值添加到扫描中。如果您仍然错过此 PR 的任何内容，请告诉我。

dreis2211

@philwebb 我看到你更改了标题，但我个人还不太愿意说“支持 Java 16”。https: //github.com/spring-projects/spring-ldap/issues/570上的问题和 Gradle 插件完全不受支持可能会给阅读变更日志并看到这一点的用户留下错误的印象。最后，它更像是“支持 Java 16构建”，并更进一步支持 Java 16。

dreis2211

我们很高兴地宣布 Spring Boot 本身支持 Java 16，即使这并非全面支持。例如，我们的 Java 9 支持在几个月内排除了 Cassandra。如有必要，我们可以对 Spring LDAP 和 Gradle 做同样的事情。后者真的还不错，因为只要用户在较早的 JVM 上运行 Gradle 本身，他们仍然可以在运行时使用 Java 16。

wilkinsona

很公平...

dreis2211

@wilkinsona @snicoll 我已发布修订版本，将工具链配置提取到其自己的插件/扩展中。总体感觉更简洁，但请让我知道你对此有何看法。

自定义插件 + 扩展可以设置最大兼容的 Java 版本，如果不匹配则禁用基于工具链的任务（有关示例，请参阅spring-boot-cli的build.gradle）这样做的积极副作用是不再需要通过自定义任务排除，这将有利于整体管道复杂性。./gradlew build -x excludedTask

dreis2211

这太棒了。非常感谢，@dreis2211。我特别喜欢通过插件和扩展配置工具链内容的新方法。

wilkinsona

这是使用 Java 16 工具链对 2.4.x 版本进行的扫描。

wilkinsona

[spring-projects/spring-boot]允许使用 Java 16 构建项目

回答