> 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 <[email protected]> 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 <[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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
