Add support for JDK 21

[bdeneuter]

In September JDK 21 will be released.It seems some internal classes were removed from the JDK. When I run our build with the JDK 21 ea, I get this error:
error-prone version: 2.21.1 BugPattern: (see stack trace) Stack Trace: java.lang.NoClassDefFoundError: com/sun/tools/javac/code/TypeMetadata$Entry at com.uber.nullaway.NullAway.handleInvocation(NullAway.java:1616) at com.uber.nullaway.NullAway.matchMethodInvocation(NullAway.java:402) at com.google.errorprone.scanner.ErrorProneScanner.processMatchers(ErrorProneScanner.java:449) at com.google.errorprone.scanner.ErrorProneScanner.visitMethodInvocation(ErrorProneScanner.java:746) at com.google.errorprone.scanner.ErrorProneScanner.visitMethodInvocation(ErrorProneScanner.java:150) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1832) at jdk.compiler/com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:92) at com.google.errorprone.scanner.Scanner.scan(Scanner.java:74) at com.google.errorprone.scanner.Scanner.scan(Scanner.java:48) at jdk.compiler/com.sun.source.util.TreeScanner.visitExpressionStatement(TreeScanner.java:503) at com.google.errorprone.scanner.ErrorProneScanner.visitExpressionStatement(ErrorProneScanner.java:633) at com.google.errorprone.scanner.ErrorProneScanner.visitExpressionStatement(ErrorProneScanner.java:150) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1611) at jdk.compiler/com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:92) at com.google.errorprone.scanner.Scanner.scan(Scanner.java:74) at com.google.errorprone.scanner.Scanner.scan(Scanner.java:48) at jdk.compiler/com.sun.source.util.TreeScanner.scan(TreeScanner.java:111) at jdk.compiler/com.sun.source.util.TreeScanner.visitBlock(TreeScanner.java:272) at com.google.errorprone.scanner.ErrorProneScanner.visitBlock(ErrorProneScanner.java:520) at com.google.errorprone.scanner.ErrorProneScanner.visitBlock(ErrorProneScanner.java:150) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1104) at jdk.compiler/com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:92) at com.google.errorprone.scanner.Scanner.scan(Scanner.java:74) at com.google.errorprone.scanner.Scanner.scan(Scanner.java:48) at jdk.compiler/com.sun.source.util.TreeScanner.scanAndReduce(TreeScanner.java:96) at jdk.compiler/com.sun.source.util.TreeScanner.visitMethod(TreeScanner.java:224) at com.google.errorprone.scanner.ErrorProneScanner.visitMethod(ErrorProneScanner.java:740) at com.google.errorprone.scanner.ErrorProneScanner.visitMethod(ErrorProneScanner.java:150) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:948) at jdk.compiler/com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:92) at com.google.errorprone.scanner.Scanner.scan(Scanner.java:74) at com.google.errorprone.scanner.Scanner.scan(Scanner.java:48) at jdk.compiler/com.sun.source.util.TreeScanner.scan(TreeScanner.java:111) at jdk.compiler/com.sun.source.util.TreeScanner.scanAndReduce(TreeScanner.java:119) at jdk.compiler/com.sun.source.util.TreeScanner.visitClass(TreeScanner.java:203) at com.google.errorprone.scanner.ErrorProneScanner.visitClass(ErrorProneScanner.java:548) at com.google.errorprone.scanner.ErrorProneScanner.visitClass(ErrorProneScanner.java:150) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:855) at jdk.compiler/com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:92) at com.google.errorprone.scanner.Scanner.scan(Scanner.java:74) at com.google.errorprone.scanner.Scanner.scan(Scanner.java:48) at jdk.compiler/com.sun.source.util.TreeScanner.scan(TreeScanner.java:111) at jdk.compiler/com.sun.source.util.TreeScanner.scanAndReduce(TreeScanner.java:119) at jdk.compiler/com.sun.source.util.TreeScanner.visitCompilationUnit(TreeScanner.java:152) at com.google.errorprone.scanner.ErrorProneScanner.visitCompilationUnit(ErrorProneScanner.java:560) at com.google.errorprone.scanner.ErrorProneScanner.visitCompilationUnit(ErrorProneScanner.java:150) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:623) at jdk.compiler/com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:66) at com.google.errorprone.scanner.Scanner.scan(Scanner.java:58) at com.google.errorprone.scanner.ErrorProneScannerTransformer.apply(ErrorProneScannerTransformer.java:43) at com.google.errorprone.ErrorProneAnalyzer.finished(ErrorProneAnalyzer.java:156) at jdk.compiler/com.sun.tools.javac.api.MultiTaskListener.finished(MultiTaskListener.java:133) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1435) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1382) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:965) at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.lambda$doCall$0(JavacTaskImpl.java:104) at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.invocationHelper(JavacTaskImpl.java:152) at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:100) at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:94) at org.gradle.internal.compiler.java.IncrementalCompileTask.call(IncrementalCompileTask.java:92) at org.gradle.api.internal.tasks.compile.AnnotationProcessingCompileTask.call(AnnotationProcessingCompileTask.java:94) at org.gradle.api.internal.tasks.compile.ResourceCleaningCompilationTask.call(ResourceCleaningCompilationTask.java:57) at org.gradle.api.internal.tasks.compile.JdkJavaCompiler.execute(JdkJavaCompiler.java:55) at org.gradle.api.internal.tasks.compile.JdkJavaCompiler.execute(JdkJavaCompiler.java:39) at org.gradle.api.internal.tasks.compile.daemon.AbstractIsolatedCompilerWorkerExecutor$CompilerWorkAction.execute(AbstractIsolatedCompilerWorkerExecutor.java:78) at org.gradle.workers.internal.DefaultWorkerServer.execute(DefaultWorkerServer.java:63) at org.gradle.workers.internal.AbstractClassLoaderWorker$1.create(AbstractClassLoaderWorker.java:54) at org.gradle.workers.internal.AbstractClassLoaderWorker$1.create(AbstractClassLoaderWorker.java:48) at org.gradle.internal.classloader.ClassLoaderUtils.executeInClassloader(ClassLoaderUtils.java:100) at org.gradle.workers.internal.AbstractClassLoaderWorker.executeInClassLoader(AbstractClassLoaderWorker.java:48) at org.gradle.workers.internal.FlatClassLoaderWorker.run(FlatClassLoaderWorker.java:32) at org.gradle.workers.internal.FlatClassLoaderWorker.run(FlatClassLoaderWorker.java:22) at org.gradle.workers.internal.WorkerDaemonServer.run(WorkerDaemonServer.java:96) at org.gradle.workers.internal.WorkerDaemonServer.run(WorkerDaemonServer.java:65) at org.gradle.process.internal.worker.request.WorkerAction$1.call(WorkerAction.java:138) at org.gradle.process.internal.worker.child.WorkerLogEventListener.withWorkerLoggingProtocol(WorkerLogEventListener.java:41) at org.gradle.process.internal.worker.request.WorkerAction.lambda$run$0(WorkerAction.java:135) at org.gradle.internal.operations.CurrentBuildOperationRef.with(CurrentBuildOperationRef.java:80) at org.gradle.process.internal.worker.request.WorkerAction.run(WorkerAction.java:127) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36) at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:182) at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:164) at org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:414) at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64) at org.gradle.internal.concurrent.AbstractManagedExecutor$1.run(AbstractManagedExecutor.java:47) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) at java.base/java.lang.Thread.run(Thread.java:1583) Caused by: java.lang.ClassNotFoundException: com.sun.tools.javac.code.TypeMetadata$Entry at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:445) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:593) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526) ... 91 more

[msridhar]

We will start working on this as soon as we can. It may take a bit of time to get through all the issues (I'm sure there are more crashes than this one). Thanks!

[msridhar]

Small update here. In order to support JDK 21 we will have to update to Checker Framework dataflow version 3.37.1 when it is released (beginning of September). Once that goes through, I have a commit msridhar@8acfb89 that should fix the crash above, except when JSpecify mode is enabled (it is off by default). So, hopefully it won't be too painful to get core NullAway functionality running on JDK 21 fairly quickly.

[msridhar]

@bdeneuter it seems based on #826 that at least basic NullAway should now be working on JDK 21. Are you able to test it out with a snapshot build? And how urgent is it for you that we cut a release with JDK 21 support?

[bdeneuter]

@msridhar I can test it with a snapshot build. Where are the snapshot versions published?
We try to stay on the latest JDK. So we upgrade our Java services each 6 months. So it would be nice to have a stable version of NullAway when JDK 21 is released. As we really depend on NullAway (our build breaks when it detects a problem) it is important that the version of NullAway is stable. If your snapshot versions are stable enough we can use the snapshot version for a while until you release a stable version.

[msridhar]

@bdeneuter The snapshots are in the Sonatype repo: https://oss.sonatype.org/content/repositories/snapshots

If you could give version 0.10.14-SNAPSHOT a try that would be fantastic; it would give us a bit more confidence before cutting a release. Thanks!

[bdeneuter]

I ran our builds and automated tests on JDK 21 with version 0.10.14-SNAPSHOT for our core libraries. All our automated tests pass. I also broke the build by passing null in a required parameter and NullAway did its job and failed the compilation step. So looks good

[msridhar]

Ok, great, thanks! We'll look into cutting a 0.10.14 release sometime this week so we support JDK 21 when it comes out.

[lazaroclapp]

NullAway 0.10.14 has been released and should appear in Maven Central shortly. It supports JDK 21 in the sense of all our existing tests running on JDK 21 (and #825 being fixed). That said, we are considering this support experimental for now in that we don't have either a large set of Java 21 tests or a production Java 21 codebase to run NullAway on, so we are definitely curious what issues you might run into while adopting Java 21 with NullAway. Feel free to send the bug reports our way! 😉