jsr305 usage causes compile error

[xenoterracide]

/home/xeno/.gradle/caches/modules-2/files-2.1/org.springframework/spring-core/6.1.3/a002e96e780954cc3ac4cd70fd3bb16accdc47ed/spring-core-6.1.3.jar(/org/springframework/lang/NonNullApi.class): warning: Cannot find annotation method 'value()' in type 'TypeQualifierDefault': class file for javax.annotation.meta.TypeQualifierDefault not found
error: warnings found and -Werror specified
1 error

So, here's the series of problems having this is.

1. should be a compileOnlyApi dependency, since it needs to be on classpath at compile time for consumers to avoid compile time warnings.
2. jsr305 is not compatible with JPMS and shouldn't be used. I've noticed that jakarta annotations-api 2 has Nullable/Nonnull now... but not these meta annotations. Issue Provide two annotations, NonnullField and NonnullApi jakartaee/common-annotations-api#124 is open, I'm happy to put in some leg work right now on these issues (not that anyone here has control over that issue).

the workaround is for me to add compileOnly on jsr305 and then monkey patch the jar to add module info, and hope that I don't need the old javax-annotations api for any reason, since it conflicts, then requiring me to do even more monkey patching of jars.

[bclozel]

Potential duplicate of #25095 (comment)

[xenoterracide]

significant overlap, that doesn't mention (that I noticed), that it breaks JPMS, so monkey patching will be required for anyone trying to use JPMS.

although the answer of "we can't do anything about it now" because this has obviously progressed into version 6... and if now never comes it'll be 7 too. Issues that should be fixed should remain open. Even when they can't be fixed now. Like why did it get lost? is it because it got closed?

Also, I find it questionable whether findbugs is actually part of the published api, if it's not correctly defined as an API dependency (IMHO). It shouldn't break anyone's build to remove it because no one is getting it from spring to begin with.

[bclozel]

We're stuck in this situation until #28797 is done (the other issue is superseded by this one), and this is not just up to the Spring team - it requires participation from the broader industry. As for JPMS with Spring, I guess this is another limitation for this use case.

I'm closing this in favor of #28797 then.