Same here. The second option seems the most reasonable. -Val
On Thu, Dec 16, 2021 at 8:07 AM Alexei Scherbakov < alexey.scherbak...@gmail.com> wrote: > +1 for 2 > > чт, 16 дек. 2021 г. в 18:50, Pavel Tupitsyn <ptupit...@apache.org>: > > > Option 2 seems the most sensible. > > It translates to/from other languages and should be already familiar to > > some developers. > > > > For example, with nullable checks enabled, C# treats everything as not > > null, unless specified otherwise with "?". > > Same for other languages where Option/Maybe type is present. Nothing is > > null by default. > > > > On Thu, Dec 16, 2021 at 6:14 PM Alexander Polovtcev < > > alexpolovt...@gmail.com> > > wrote: > > > > > Dear Igniters! > > > > > > I would like to propose a discussion about defining a policy regarding > > > where and how to use @Nullable/@NotNull annotations. These annotations > > are > > > used in conjunction with a static analysis engine (e.g. built in IDEA) > > and > > > are useful for avoiding null dereferencing and specifying method > > contracts. > > > > > > I can see the following possible options: > > > > > > 1. *Use both @Nullable and @NotNull annotations everywhere* (i.e. > method > > > parameters and return types, class fields). Pros: the most robust and > > > expressive variant; easy to agree on and specify. Cons: very verbose; > may > > > lead to code cluttering; > > > 2. *Use only @Nullable *for specifying method parameters that accept > null > > > or class fields that can be null, treating @NotNull as an implicit > > default. > > > Pros: correlates with the default IDEA settings (with all corresponding > > > inspections enabled); not as verbose as option 1, since nullable > > parameters > > > are quite rare. Cons: less sound and complete, especially when working > > with > > > third-party libraries that are not annotated, since we cannot apply the > > > implicit @NotNull there; > > > 3. *Use only @NotNull *and treat @Nullable as an implicit default. > Pros: > > > less verbose than option 1, better correlates with Java language > > semantics > > > (since all Java references are nullable). Cons: more verbose than > option > > 2; > > > may be impossible to properly set up the analysis engine or may require > > > switching to a different annotation provider that supports jsr-305 > > > @ParametersAreNullableByDefault; > > > 4. *Do not use @Nullable nor @NotNull*. The most radical option in case > > we > > > will not be able to agree on any of the above three. No annotations - > no > > > need for the discussion. > > > > > > What do you think? Are there any other options out there? I would like > to > > > collect as many options as possible and organize a vote some time > later. > > > > > > -- > > > With regards, > > > Aleksandr Polovtcev > > > > > > > > -- > > Best regards, > Alexei Scherbakov >
