You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Konrad Windszus <ko...@gmx.de> on 2015/02/02 09:10:41 UTC
Re: JSR305
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 <ro...@lmn.ro> wrote:
>
> On Fri, Jan 30, 2015 at 2:55 PM, Konrad Windszus <konrad_w@gmx.de <ma...@gmx.de>> 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 <ro...@apache.org> wrote:
>>>
>>> On Fri, Jan 30, 2015 at 2:15 PM, Konrad Windszus <ko...@gmx.de> 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> 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
Re: JSR305
Posted by Tommaso Teofili <to...@gmail.com>.
2015-02-05 14:27 GMT+01:00 Julian Sedding <js...@gmail.com>:
> > 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 <ko...@gmx.de> 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 <to...@gmail.com>
> wrote:
> >>
> >> 2015-02-05 9:59 GMT+01:00 Konrad Windszus <ko...@gmx.de>:
> >>
> >>> 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 <ko...@gmx.de> 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 <robert@lmn.ro <mailto:
> >>> robert@lmn.ro>> wrote:
> >>>>>
> >>>>> On Fri, Jan 30, 2015 at 2:55 PM, Konrad Windszus <konrad_w@gmx.de
> >>> <ma...@gmx.de>> 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 <rombert@apache.org
> >>> <ma...@apache.org>> wrote:
> >>>>>>>
> >>>>>>> On Fri, Jan 30, 2015 at 2:15 PM, Konrad Windszus <konrad_w@gmx.de
> >>> <ma...@gmx.de>> 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
> >>>>
> >>>
> >>>
> >
>
Re: JSR305
Posted by Julian Sedding <js...@gmail.com>.
> 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 <ko...@gmx.de> 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 <to...@gmail.com> wrote:
>>
>> 2015-02-05 9:59 GMT+01:00 Konrad Windszus <ko...@gmx.de>:
>>
>>> 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 <ko...@gmx.de> 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 <robert@lmn.ro <mailto:
>>> robert@lmn.ro>> wrote:
>>>>>
>>>>> On Fri, Jan 30, 2015 at 2:55 PM, Konrad Windszus <konrad_w@gmx.de
>>> <ma...@gmx.de>> 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 <rombert@apache.org
>>> <ma...@apache.org>> wrote:
>>>>>>>
>>>>>>> On Fri, Jan 30, 2015 at 2:15 PM, Konrad Windszus <konrad_w@gmx.de
>>> <ma...@gmx.de>> 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
>>>>
>>>
>>>
>
Re: JSR305
Posted by Konrad Windszus <ko...@gmx.de>.
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 <to...@gmail.com> wrote:
>
> 2015-02-05 9:59 GMT+01:00 Konrad Windszus <ko...@gmx.de>:
>
>> 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 <ko...@gmx.de> 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 <robert@lmn.ro <mailto:
>> robert@lmn.ro>> wrote:
>>>>
>>>> On Fri, Jan 30, 2015 at 2:55 PM, Konrad Windszus <konrad_w@gmx.de
>> <ma...@gmx.de>> 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 <rombert@apache.org
>> <ma...@apache.org>> wrote:
>>>>>>
>>>>>> On Fri, Jan 30, 2015 at 2:15 PM, Konrad Windszus <konrad_w@gmx.de
>> <ma...@gmx.de>> 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
>>>
>>
>>
Re: JSR305
Posted by Tommaso Teofili <to...@gmail.com>.
2015-02-05 9:59 GMT+01:00 Konrad Windszus <ko...@gmx.de>:
> 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 <ko...@gmx.de> 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 <robert@lmn.ro <mailto:
> robert@lmn.ro>> wrote:
> >>
> >> On Fri, Jan 30, 2015 at 2:55 PM, Konrad Windszus <konrad_w@gmx.de
> <ma...@gmx.de>> 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 <rombert@apache.org
> <ma...@apache.org>> wrote:
> >>>>
> >>>> On Fri, Jan 30, 2015 at 2:15 PM, Konrad Windszus <konrad_w@gmx.de
> <ma...@gmx.de>> 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
> >
>
>
Re: JSR305
Posted by Konrad Windszus <ko...@gmx.de>.
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!)
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 <ko...@gmx.de> 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 <robert@lmn.ro <ma...@lmn.ro>> wrote:
>>
>> On Fri, Jan 30, 2015 at 2:55 PM, Konrad Windszus <konrad_w@gmx.de <ma...@gmx.de>> 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 <rombert@apache.org <ma...@apache.org>> wrote:
>>>>
>>>> On Fri, Jan 30, 2015 at 2:15 PM, Konrad Windszus <konrad_w@gmx.de <ma...@gmx.de>> 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
>