I'd prefer not. Every additional dependency we add is a liability. It's not clear we need something like this and even if we do, JSpecify is only a few months old. This is only the latest of many efforts to establish a standard for nullness annotations. I don't see why JSpecify will be the one ring to rule them all. XKCD 927 applies:
https://xkcd.com/927/ Really what needs to happen here is someone needs to reboot the JSR 305 work in the JCP. I'm not sure why it failed the first time, but perhaps it can be fixed. On Sun, Feb 11, 2024 at 9:28 PM Benjamin Marwell <[email protected]> wrote: > > 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] > -- Elliotte Rusty Harold [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
