Thanks everybody for the opinions. Looks like we all agree on option 2, but
nevertheless I'll organize a formal vote after the New Year holidays.
On Wed, Dec 22, 2021 at 9:18 AM Ivan Pavlukhin wrote:
> Val,
>
> > Basically, what I'm suggesting is to accept non-nullable as default
>
> Sounds
Val,
> Basically, what I'm suggesting is to accept non-nullable as default
Sounds good for me. Then it should be clearly stated in code
guidelines and regular static analysis for this should be organized
from the beginning.
2021-12-21 20:35 GMT+03:00, Valentin Kulichenko :
> Ivan,
>
> I agree
Ivan,
I agree with you. Basically, what I'm suggesting is to accept non-nullable
as default, but if a parameter must be nullable for whatever reason, mark
it with the @Nullable annotation.
Regarding "a user can put anything there without much thinking": I
understand what you mean, but I believe
Val,
> Therefore, it's crucial to bring the attention of the API's user to such
> parameters. (@Nullable)
This sounds wrong for me. If a method parameter is marked as
@Nullable, then a user can put anything there without much thinking.
Opposite happens with @NotNull parameters, with them a user
Neither solution is completely bulletproof, and I don't think that's what
we are looking for. We need something that provides a reasonable value, but
also does not clutter the code with too many annotations.
I would also keep in mind that annotations are used not only for static
analysis, but by
Hi, Ivan.
> it seems not bulletproof
I completely agree with you. As I wrote in the original message, this
becomes even worse in case of 3-rd party dependencies, because they may not
be annotated, which can lead to confusions. But looks like this is not a
big deal, because these annotations are
Hi,
While option #2 looks very appealing it seems not bulletproof
reliable, someone can occasionally miss @Nullable annotation. Option
#3 seems more practical too me, as missed @NotNull annotations cannot
do much harm.
Also I am thinking about using nullable parameters in general. Perhaps
we can
Maksim, thank you for the suggestion.
I've never used NullAway, but after having a quick look I think it might be
an overkill, since it is a plugin for the ErrorProne, which is a separate
tool. I recall some efforts of introducing ErrorProne to Ignite 3 and they
were not successful. But again, I
+1 for option No. 2.
On Fri, 17 Dec 2021 at 12:10, Maksim Timonin
wrote:
> Hi!
>
> There is a pretty popular project NullAway [1] that checks code of a
> project in compile-time for possible NPE. AFAIK, it works only with the
> "@Nullable" annotation. I think we can try to add this check to
Hi!
There is a pretty popular project NullAway [1] that checks code of a
project in compile-time for possible NPE. AFAIK, it works only with the
"@Nullable" annotation. I think we can try to add this check to Ignite2 and
3.
But I wonder, whether smbd already tried to introduce this check? If
I'm for the second option.
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 :
>
> > Option 2 seems the most sensible.
> > It translates to/from other languages
+1 for 2
чт, 16 дек. 2021 г. в 18:50, Pavel Tupitsyn :
> 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
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.
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
15 matches
Mail list logo
