Thanks very much for reporting. This is a case that we are sadly aware of but have been embarrassingly slow to do anything about.

The JDK bug for it is JDK-8225377.

Many nullness checkers have grown their own workarounds (using internal JDK APIs), but we want to get the bug fixed, both so that those checkers can someday remove their workarounds (some of which are buggy, e.g., ours :)) and so that annotation processors that just try to use nullness information (like yours) can do so without needing to employ similar tricks.

@cpovirk Thank you for the comment! It was extremely helpful. I tried ErrorPrones Symbol getRawAttributes hack and I think it could work but the required setup would be rather painful for consumers of the library.

For now I'm going to shelve our nullable support for my library at the moment: jstachio/jstachio#4.

Partly because of the hack but mostly as I'm not sure what level of support to provide as it is just a templating language.

As a side note I was wondering as a workaround to the jdk bug some JSpecify tool/implementation annotation processor could generate external annotations (such as eclipses external annotation format) as a class resource. Then downstream tools could check kind of like the non modular service loader (META-INF/services) if the annotations file is present.

Using my previous example ModuleA would be compiled with external annotation generator. ModuleB could then read the file (classpath resource). Not ideal but it is a tool even I could make ... I think.

You're welcome. I'm glad it was helpful. Thanks for the link to your project and for your interest.

As for the workaround: We've occasionally had conversations about developing a consensus format for external annotations. I don't know if we'd connected that with this current issue, though, with the idea of writing the information we already know into an external file so that it can be read without hacks.

To be fully general, we'd want to write that information for all classes on the classpath that might contain nullness annotations. And we'd want various tools to read it—which might be straightforward if we can provide drop-in replacements for all the relevant javax.lang APIs. Overall, there's enough uncertainty (e.g., when a class in the dependencies is repackaged/shaded) that I think we'll probably still focus more on fixing javac—even though that, too, is uncertain :) But it's helpful to have another option to keep in mind and to inspire other ideas. And it probably is a straightforward option for cases in which you care only about one or two tools and only about certain kinds of classes.

FYI: Just to say the JDK bug is fixed in 22 and back ported to 21.0.2, 17.0.11, 11.0.23:

JDK-8319885 21.0.2
JDK-8321934 17.0.11
JDK-8322203 11.0.23

Unfortunately the fix is no longer going to be in 21.0.2, and may be backed out of the upcoming 17u and 11u releases also: JDK-8322883

Just ran into this one today, it was quite baffling. I got around it by using a TypeVisitor on the typeMirror, so while I can't directly read TypeMirror.getAnnotationMirrors() I can use the visitor to extract the annotations and do the checks.

Edit: Ah yeah, the visitor is generated from another processor so it's not in git, so here is the gist for it.

Edit 2: no wait, I guess it isn't that simple. Back to the drawing board.

Unfortunately the fix is no longer going to be in 21.0.2, and may be backed out of the upcoming 17u and 11u releases also: JDK-8322883

I'm sorry that this was backed out of the update versions :-(
In the bug report I see only javac fails with "Unable to implement <class> method". Do you have a reproducible test case for this failure? Do you think the fixes would go into the update versions if that bug were fixed?

@wmdietl the javac fails with "Unable to implement <class> method" issue was fixed by micronaut-projects/micronaut-core#10293. There are probably other similar issues in the wild, so the question is how many processors are affected and what the impact will be. I wrote up a CSR to discuss the compatibility impact (JDK-8323093). If it does get backed out for now, I think we could try again for the next update release in July.

As I start the migration of Spring Framework main branch (future Spring Framework 7.0) that will very significantly increase JSpecify reach, I would welcome an update on the backport of the JDK fix to 17 and 21 (we don't care about Java 11 as Spring baseline is Java 17). Spring contains runtime checks of null-safety annotation so it is very important that Spring Boot applications works as expected once migrated to JSpecify as of Java 17.

I would welcome an update on the backport of the JDK fix to 17 and 21

Re-doing the backport is tracked by JDK-8341779. There was a compiler-dev@ thread from July/August linked from the bug, I don't have more recent updates.

@sdeleuze I'm not sure Spring has to worry about this as it is mostly reflection based.

That is the JSpecify Nullable annotations are visible with reflection (no JDK fix needed).

Is Spring using some annotation processors for tooling or code generation (that I'm unaware of)?

@agentgt Spring Boot is using 2 annotation processors org.springframework.boot.autoconfigureprocessor.AutoConfigureAnnotationProcessor and org.springframework.boot.configurationprocessor.ConfigurationMetadataAnnotationProcessor. In org.springframework.boot.configurationprocessor.MetadataGenerationEnvironment#hasNullableAnnotation, we check for the existence of org.springframework.lang.Nullable, and we need as part of Spring Boot 4 to add similar support for org.jspecify.annotations.Nullable. If I am not mistaken, for now it is only possible with Java 22+, so it would be a significant regressions for Java 17 and 21 users.

@cushon @kevinb9n Looking forward to synchronize on how we can collaborate for a new push for backporting this fix to Java 17 and 21.