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