2015-02-05 14:27 GMT+01:00 Julian Sedding <[email protected]>: > > Could you enlighten me, why you don’t leave out the @Nullable for > parameters at all? > > I would think that adding it makes it clear that you considered a > methods contract and made it explicit. When you just leave it off it > may just have been forgotten or no consideration was given. > > So for a reader of the code having the annotation reveals more about > the original developer's intention. >
+1 Regards, Tommaso > > Regards > Julian > > On Thu, Feb 5, 2015 at 11:51 AM, Konrad Windszus <[email protected]> wrote: > > Hi Thommaso, > > thanks for your input. > > I observed that Oak is using both @Nullable and @CheckForNull. What is > the reason why you use both? > > I would assume that all tools implicitly assume @Nullable in case no > annotation is set, and as I already explained, Eclipse can only be > configured to either understand > > @Nullable or @CheckForNull. > > > > Could you enlighten me, why you don’t leave out the @Nullable for > parameters at all? > > Is this only to make implementors of that Interface aware of that fact? > Or is it giving any additional value for semantic code checks (e.g. for > Findbugs?) > > > > Thanks, > > Konrad > > > > > >> On 05 Feb 2015, at 11:34, Tommaso Teofili <[email protected]> > wrote: > >> > >> 2015-02-05 9:59 GMT+01:00 Konrad Windszus <[email protected]>: > >> > >>> I created https://issues.apache.org/jira/browse/SLING-4377 < > >>> https://issues.apache.org/jira/browse/SLING-4377> to track that. > >>> But I just faced another problem: > >>> I can make Eclipse only understand one type of nullable annotation: So > >>> either @Nullable or @CheckForNull. > >>> The problem now is, that I would need to rely on both for Findbugs if I > >>> also want to leverage the @ParametersAreNonNullByDefault. I opened the > bug > >>> https://sourceforge.net/p/findbugs/bugs/1355/ < > >>> https://sourceforge.net/p/findbugs/bugs/1355/> about this different > >>> behaviour between Eclipse and Windbags > >>> > >>> In Oak Solr this was solved by not using the class/package annotation > >>> @ParametersAreNonNullByDefault. But that way writing the annotations is > >>> quite verbose, because in most of the cases, parameters are not > supposed to > >>> be null! > >>> I would need to annotate all of those with @NonNull (because @Nullable > is > >>> the default then!) > >>> > >> > >> actually it's like that for Oak generally, not just for Oak Solr; apart > >> from that the side effect of what you noticed is, in my experience, not > so > >> negative: meaning that your IDE (Eclipse, IDEA do it IIRC) will suggest > you > >> to add the relevant annotations also to the implementors of a certain > API > >> to avoid seeing "warnings", which in the end leads to a better > awareness of > >> the contract to who's writing such an API implementation ending up with > >> annotating also the implementation methods with the right one > >> (@CheckForNull or @Nullable). > >> > >> My 2 cents, > >> Tommaso > >> > >> > >>> > >>> Do you have any other idea how to deal with that except for limiting > >>> oneself to only @CheckForNull and @NonNull? > >>> > >>> Thanks a lot for any input on that > >>> Konrad > >>> > >>> > >>>> On 02 Feb 2015, at 09:10, Konrad Windszus <[email protected]> wrote: > >>>> > >>>> Indeed Eclipse supports configurable annotations. You can find the > >>> information at > >>> > http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Freference%2Fpreferences%2Fjava%2Fcompiler%2Fref-preferences-errors-warnings.htm&anchor=null_annotation_names > >>> < > >>> > http://help.eclipse.org/juno/index.jsp?topic=/org.eclipse.jdt.doc.user/reference/preferences/java/compiler/ref-preferences-errors-warnings.htm&anchor=null_annotation_names > >. > >>> Therefore it will probably make sense to use the JSR305 annotations. > >>>> I will create a feature branch where I will add those annotations for > >>> Sling API as well as Sling Models and Sling Validation. > >>>> Thanks for your input. > >>>> > >>>>> On 30 Jan 2015, at 13:59, Robert Munteanu <[email protected] <mailto: > >>> [email protected]>> wrote: > >>>>> > >>>>> On Fri, Jan 30, 2015 at 2:55 PM, Konrad Windszus <[email protected] > >>> <mailto:[email protected]>> wrote: > >>>>>> The question for me is whether we should rely on the dormant > standard > >>> (which did never release anything officially) 305, because that is not > >>> supported by Eclipse or whether we should use something else? > >>>>>> Any ideas, opinions on that? > >>>>>> What is your experience with the JSR305 javax.annotation support in > >>> major IDEs (see also > >>> > http://stackoverflow.com/questions/4963300/which-notnull-java-annotation-should-i-use > >>> < > >>> > http://stackoverflow.com/questions/4963300/which-notnull-java-annotation-should-i-use > > > >>> < > >>> > http://stackoverflow.com/questions/4963300/which-notnull-java-annotation-should-i-use > >>> < > >>> > http://stackoverflow.com/questions/4963300/which-notnull-java-annotation-should-i-use > >>>>> )? > >>>>> > >>>>> AFAIR for Eclipse you can configure the annotation types to use ( see > >>>>> [1] ) . But of course we'd need to validate this before starting > >>>>> conversions. > >>>>> > >>>>> Robert > >>>>> > >>>>> > >>>>> [1]: > >>> > http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Ftasks%2Ftask-using_null_annotations.htm > >>> < > >>> > http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Ftasks%2Ftask-using_null_annotations.htm > >>>> > >>>>> > >>>>>> Konrad > >>>>>> > >>>>>>> On 30 Jan 2015, at 13:37, Robert Munteanu <[email protected] > >>> <mailto:[email protected]>> wrote: > >>>>>>> > >>>>>>> On Fri, Jan 30, 2015 at 2:15 PM, Konrad Windszus <[email protected] > >>> <mailto:[email protected]>> wrote: > >>>>>>>> What about adding annotations like > >>> > https://code.google.com/p/jsr-305/source/browse/trunk/ri/src/main/java/javax/annotation/CheckForNull.java > >>> < > >>> > https://code.google.com/p/jsr-305/source/browse/trunk/ri/src/main/java/javax/annotation/CheckForNull.java > > > >>> < > >>> > https://code.google.com/p/jsr-305/source/browse/trunk/ri/src/main/java/javax/annotation/CheckForNull.java > >>> < > >>> > https://code.google.com/p/jsr-305/source/browse/trunk/ri/src/main/java/javax/annotation/CheckForNull.java > >> > >>> to the Sling API? > >>>>>>> > >>>>>>> +1 > >>>>>>> > >>>>>>> I wonder if there is a static analyser which can fail the build > when > >>>>>>> violations are found, e.g. immediately dereferencing the result of > a > >>>>>>> method which is @Nullable. > >>>>>>> > >>>>>>> Robert > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Sent from my (old) computer > >>>> > >>> > >>> > > >
