(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.
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]
