Not exactly, although that also seems, what the author of https://jspecify.dev/_sources/index.rst.txt is thinking. But given, that the last attempt at this went nowhere, and has been abandoned about 10 years ago, I think it is rather unlikely, that this one would make the difference.
And why should it be necessary for the user, to know the details of the interpretation of the checking framework? Annotations are kind of interfaces, and as such may be interpreted just as any other interface as defining element of a contract, which could be detailed in Javadoc. The same way as Eclipse Link and Hibernate do with JPA annotations, while at least hibernate still also works with its own annotations. In fact, @NotNull and its compannions can all be interpreted as describing a predicate applying to certain elements of the source tree. So all what is needed, is to match the annotations with the predicates, the framework can support. The challenge is in the inference, when these predicates are applied to the source tree. This way, a checker framework may take also advantage of the knowledge hidden in foreign annotations: JPA, Hibernate, Jackson all have constructs for indicating nullability and attribute sizes, that might be of use. Gesendet: Montag, 08. Februar 2021 um 00:37 Uhr Von: "Gary Gregory" <garydgreg...@gmail.com> An: "Commons Developers List" <dev@commons.apache.org> Betreff: Re: [lang] Introduce @NonNull, and @Nullable Isn't the root issue is that all toolchains need to agree on the new annotations? What's that going to be? On Sun, Feb 7, 2021, 17:56 si...@ochsenreither.de <si...@ochsenreither.de> wrote: > > Agree on that – adding a dependency on the JSR-305 jar is a really really > bad idea for all the reasons already outlined. I'll add another one: > > At my place, we have actively been removing any usage of these annotations > as you simply can't use these annotations and the "real" javax.annotations > package (javax.annotation:javax.annotation-api) under the module system > (that was introduced in Java 9, for the record). > > People are already working on a replacement library (Jetbrains, Google, > others), but I forgot the exact URL due to a lack of interest. > (The JSR-305 approach to nullability is wrong, broken, and will never work > reliably from my POV.) > > Cheers, > > Simon > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
