Let's use them only for method parameters (not return values) on public APIs. They help with Javadoc documentation.
D. On Fri, Feb 20, 2015 at 2:04 AM, Sergi Vladykin <[email protected]> wrote: > I don't think these annotation will make development easier. It will only > require additional efforts to support these annotations in actual state on > each method. But they will not replace unit testing. I'd prefer not using > them at all if the choice is between all and nothing. > > Sergi > > 2015-02-20 4:06 GMT+03:00 Konstantin Boudnik <[email protected]>: > > > I think it's a great idea. But that's just my uneducated opinion. > > > > On Thu, Feb 19, 2015 at 02:51PM, Sergey Evdokimov wrote: > > > It's a wrong usage of @Nullable annotation, Ignite.jcache("mycache") > must > > > NOT be marked as @Nullable , because we does not want to force > > > null-checking by user. A good place for @Nullable annotation > > > java.io.BufferedReader#readLine() method. Feel the difference. > > > > > > > I think that having annotations only on public API is ok. @NotNull > and > > > > @Contract seem to be extra effort. > > > Why public only? Marking parameters in private code will make > development > > > easier for us. > > > > > > If you are agree I suggest to create a ticket. > > > > > > On Wed, Feb 18, 2015 at 6:54 PM, Dmitriy Setrakyan < > > [email protected]> > > > wrote: > > > > > > > My problem is IDEA warnings. For example, Ignite.jcache("mycache") > may > > > > return null, and if I don't check for null, IDEA gives an warning. In > > 99% > > > > of the cases here I don't need to check of null because I know that > > cache > > > > is there. > > > > > > > > D. > > > > > > > > On Wed, Feb 18, 2015 at 7:00 AM, Sergi Vladykin < > > [email protected]> > > > > wrote: > > > > > > > > > I think that having annotations only on public API is ok. @NotNull > > and > > > > > @Contract seem to be extra effort. > > > > > > > > > > Sergi > > > > > > > > > > 2015-02-09 9:33 GMT+03:00 Dmitriy Setrakyan <[email protected] > >: > > > > > > > > > > > I generally found myself suppressing IDE warnings whenever these > > > > > > annotations are used. Personally, I would not, but I would want > to > > hear > > > > > > what others think as well. > > > > > > > > > > > > D. > > > > > > > > > > > > On Sun, Feb 8, 2015 at 10:29 PM, Sergey Evdokimov < > > > > > [email protected] > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > Whats about @NotNull and @Contract annotations? Can we use its > > in our > > > > > > code? > > > > > > > > > > > > > > On Mon, Feb 9, 2015 at 8:02 AM, Konstantin Boudnik < > > [email protected]> > > > > > > wrote: > > > > > > > > > > > > > > > Sounds like a good idea. In my experience having @Nullable > for > > > > > returns > > > > > > > is a > > > > > > > > good thing, as it quickly let a user of the API to see what's > > the > > > > > > > contract. > > > > > > > > > > > > > > > > Cos > > > > > > > > > > > > > > > > On Sun, Feb 08, 2015 at 04:36PM, Dmitriy Setrakyan wrote: > > > > > > > > > Hi Igniters, > > > > > > > > > > > > > > > > > > I want to revisit the use of the @Nullable annotation > within > > the > > > > > > > project. > > > > > > > > > What I am noticing more and more, is that @Nullable > > annotation > > > > just > > > > > > > > causes > > > > > > > > > extra warnings in IDE, especially on public API, causing > > most of > > > > > the > > > > > > > > users > > > > > > > > > and developers to disable it. > > > > > > > > > > > > > > > > > > I want to propose the following policy: > > > > > > > > > - Use @Nullable for method parameters on public API for > > > > > documentation > > > > > > > > > purposes. > > > > > > > > > - Do not use @Nullable for return types on public API to > > avoid > > > > > > > > unnecessary > > > > > > > > > warnings. > > > > > > > > > - Do not use @Nullable within internal implementation logic > > to > > > > > avoid > > > > > > > > > unnecessary clutter in code. > > > > > > > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > > > > > D. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
