ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Evdokimov <sevdoki...@gridgain.com>
Subject Re: use of @Nullable
Date Fri, 20 Feb 2015 10:37:45 GMT
> It will only require additional efforts to support these annotations in
actual state on each method.
You don't have to add @Nullable / @NotNull annotations to EACH method, you
should use it only if you feel that annotations is needed.

> Let's use them only for method parameters (not return values) on public
APIs.
Can we use @Nullable / @NotNull / @Contract annotations on private API
where it is pertinently?

Can we use @NotNull annotation on method return? Somewhere it's useful.

Can I enable "Probable bugs | Constant conditions & exceptions" inspection
in ggprivate/idea/gridgain_inspections.xml and send email with suggestion
to enable this inspection to whole team? Currently this inspection is
disabled in our inspection configuration.



On Fri, Feb 20, 2015 at 1:12 PM, Dmitriy Setrakyan <dsetrakyan@apache.org>
wrote:

> 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 <sergi.vladykin@gmail.com>
> 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 <cos@apache.org>:
> >
> > > 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 <
> > > dsetrakyan@apache.org>
> > > > 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 <
> > > sergi.vladykin@gmail.com>
> > > > > 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 <
> dsetrakyan@apache.org
> > >:
> > > > > >
> > > > > > > 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 <
> > > > > > sevdokimov@gridgain.com
> > > > > > > >
> > > > > > > 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
<
> > > cos@apache.org>
> > > > > > > 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.
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message