> 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. 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 >>>> >>> >>> >
