OK, let's wait for the JEP to arrive then. > Such a dependency would only be useful if compilers. > IDEs, and incremental compilers within IDEs (like in Eclipse) would > know about them to report warnings.
Luckily, at least the IDEs do. For maven builds, you'd need sth like the checker framework or Google ErrorProne. But not worth it for existing projects. > I'm sure they'd want to do so through a JEP API Yes, JSpecify tries to be what Joda was for java.time. At the moment, IntelliJ will just use any @Nullable annotation, and Eclipse can be configured (just add any fqcn). I hope we get a little bit better parameter documentation, though. Am Di., 13. Feb. 2024 um 04:11 Uhr schrieb Gary Gregory <[email protected]>: > > On Mon, Feb 12, 2024 at 6:33 AM Matthias Bünger > <[email protected]> wrote: > > > > (I'm neither a Maven core or plugin maintainer) > > > > I don't like such annotations as in my opinion, they save you nothing, > > but bring an addional dependency and problems with the tools that > > (don't) support (only a specific version of) them. > > I agree 100%. Such a dependency would only be useful if compilers. > IDEs, and incremental compilers within IDEs (like in Eclipse) would > know about them to report warnings. If they wanted to do that, then > I'm sure they'd want to do so through a JEP API, not > yet-another-attempt-at-null-annotations. > > An example of why this is a bad idea is depending on > com/google/code/findbugs/jsr305/3.0.2/jsr305-3.0.2.jar's @Nonnull, > which, in the current version Eclipse at least shows up as an illegal > annotation when you use it, defeating the purpose: "Annotation types > that do not specify explicit target element types cannot be applied > here Objects.java > /commons-lang3/src/test/java/org/apache/commons/lang3/function line 74 > Java Problem" > > Gary > > > > > If my method needs arguments that are not null than I have to check them > > and throw an exception if the caller of the method tries to pass NULL > > into it. If I'm too lazy to check my parameters than I deserve it to get > > NPE e.g. (funny enough an external coder with 20+ years of experience at > > my work just experience that exactly now, as he just relies that > > everything is always there...). > > > > Am 11.02.2024 um 22:27 schrieb Benjamin Marwell: > > > Hello devs and plugin maintainers! > > > > > > Since JSR 305 (Nullable annotations etc.) did not get implemented > > > officially, and Maven allows `null` in a lot of locations, I wanted to > > > ask about your opinions about using jspecify: https://jspecify.dev/ > > > > > > JSpecify was created by the Java community (i.e. Java decs but also > > > larger corporations like Google, if I am not mistaken. It was seen as > > > needed since JSR 305 never materialized and probably never will. > > > Google hat a Guava Situation [1] and decided to do something about it. > > > > > > JSpecify says it is safe to adopt it [2]. Although the current version > > > is 0.3, it is more like 0.9. > > > > > > I honestly think that Maven would benefit from those annotations, as > > > many recent libraries try to avoid `null` as best as they can. Younger > > > developers may not be used to seeing nullable parameters, and even > > > some of us don't know which parameters can be nulled (or not). > > > > > > Let me know what you think about this idea. > > > > > > My personal opinion: I am pretty confident jspecify will displace > > > checker-qual as the "top dog" of nullness annotations in the future. I > > > also want to give plugin authors a way to use null in their plugins, > > > too, although we could make it an optional dependency (just > > > annotations...). > > > > > > Looking forward to reading your opinions! > > > > > > - Ben > > > > > > 1: https://github.com/google/guava/issues/2960 > > > 2: https://github.com/jspecify/jspecify/wiki/adoption > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
