+1 for using @Nullable as it is a kind of documentation +1 for using @NotNull as it protects from wrong fields/variables assignments if modern IDE is used.
пт, 27 мар. 2020 г. в 14:28, Sergey-A Kosarev <sergey-a.kosa...@db.com>: > Classification: Public > > +1 for using @Nullable. > > @Nullable is not panacea, but much better than nothing. > > It's clear indication that you should check the marked object for null > before using. There is advantage in using @Nullable than @NotNull - Idea or > any tool like findbugs shows you potential NPE places - where you forgot to > check for null object marked @Nullable, otherwise if you use only @NotNull > it's much harder to see NPE problems as, I believe, always will be too many > noise - places where developers just forgot to place annotation. > > And another arguable point is statistics, in my experience there are more > objects that not null by nature than nullable. So if you should mark only > all @NotNull objects, you will need to place much more annotations than if > mark only @Nullable objects. > > Kind regards, > Sergey Kosarev > > > -----Original Message----- > From: Ivan Pavlukhin [mailto:vololo...@gmail.com] > Sent: 27 March 2020 13:28 > To: dev <dev@ignite.apache.org> > Subject: Re: Get rid of @Nullable and @NotNull > > Here is my opinion. As we do not have a common practice to use @Nullable > and @NotNull annotations everywhere I would consider every not annotated > item as effectively @Nullable. @NotNull seems a useful annotation for me, > sometimes it is a really good thing to assume that something cannot be null > instead of doing explicit null check everywhere. > > Best regards, > Ivan Pavlukhin > > пт, 27 мар. 2020 г. в 13:05, Denis Garus <garus....@gmail.com>: > > > > Hi! > > I'm not sure that @Nullable can really fix the NPE problem. > > Currently, we have @Nullable annotation and NPE simultaneously. > > The best way to avoid NPE is by using a null object pattern. > > I agree we shouldn't rely on @Nullable. > > > > > > пт, 27 мар. 2020 г. в 12:58, Sergey Antonov <antonovserge...@gmail.com>: > > > > > I disagree. > > > > > > Intellij idea IDE has a static code analysis, which uses that > > > annotation too. IDE highlights possible problems. It helps to make > > > our code more stable and bugless. > > > > > > пт, 27 мар. 2020 г. в 12:06, Pavel Tupitsyn <ptupit...@apache.org>: > > > > > > > I disagree, it would be a step back. > > > > > > > > > What's the reason for using it? > > > > Null was a billion dollar mistake [1]. > > > > NullPointerExceptions happen quite a lot in Ignite, and > > > > annotations > > > provide > > > > some clues to avoid those. > > > > > > > > [1] > > > > https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions > > > > > > > > On Fri, Mar 27, 2020 at 10:58 AM Anton Vinogradov <a...@apache.org> > wrote: > > > > > > > > > Folks, > > > > > > > > > > Found we still use @Nullable annotation. > > > > > > > > > > What's the reason for using it? > > > > > Everything is Object and Nullable :) > > > > > > > > > > How about get rid of @Nullable usages and restrict its usage by > > > > checkstyle > > > > > plugin? > > > > > > > > > > BTW, We already "do not use @NotNull annotation" (с) Coding > > > > > Guidelines > > > > [1] > > > > > which may have some cense in contrast to @Nullable. > > > > > But I see a lot of usages at code. > > > > > > > > > > How about to get rid of @NotNull too and to add such check to > > > checkstyle > > > > > plugin too? > > > > > > > > > > [1] > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines > > > #CodingGuidelines-@Annotations > > > > > > > > > > > > > > > > > > -- > > > BR, Sergey Antonov > > > > > > --- > This e-mail may contain confidential and/or privileged information. If you > are not the intended recipient (or have received this e-mail in error) > please notify the sender immediately and delete this e-mail. Any > unauthorized copying, disclosure or distribution of the material in this > e-mail is strictly forbidden. > > Please refer to https://www.db.com/disclosures for additional EU > corporate and regulatory disclosures and to > http://www.db.com/unitedkingdom/content/privacy.htm for information about > privacy. >
