RE: JSR 305 annotations (nullability)

[Stefan Seifert]

ah, - i'm fine with jetbrains annotations as well (although they include 
serveral more annotations we do not need and that are probably specific to 
jetbrains tools - but this is the case for all annotation artifacts).

then we would be in line with jackrabbit.

stefan

>-Original Message-
>From: Julian Reschke [mailto:julian.resc...@gmx.de]
>Sent: Sunday, July 8, 2018 2:50 PM
>To: dev@sling.apache.org; Stefan Seifert
>Subject: Re: JSR 305 annotations (nullability)
>
>On 2018-07-08 14:34, Stefan Seifert wrote:
>> i would also favor switchting to the findbugs nullable annotations (now
>repackaged and maintained as spotbugs annotations).
>
>AFAIU, we can't due to the license (LGPL).
>
>> we should remove the jsr 305 dependency from our parent pom, and probably
>add instead:
>>
>>  
>>com.github.spotbugs
>>spotbugs-annotations
>>3.1.5
>>provided
>>
>>  
>>com.google.code.findbugs
>>jsr305
>>  
>>
>>  
>>
>> in recent eclipse versions it's possible to configure multiple nullable-
>annotations - so it's possible to support both the javax.annotation and the
>findbugs annotations - making it easy working with already released sling
>artifacts still using the javax.annotation annotations. on the long run we
>should migrate away from those.
>>
>> and we have to update [1] then. not we sure if we still need to support
>only "CheckForNull" - it would be nice to also support "Nullable" (in
>eclipse it's possible to configure both). the related jackrabbit ticket is
>[2].
>> ...
>
>See also <https://issues.apache.org/jira/browse/JCR-4301> which for now
>has been resolved by switching to the Jetbrains annotations.
>
>Best regards, Julian

Re: JSR 305 annotations (nullability)

[Julian Reschke]

On 2018-07-08 14:34, Stefan Seifert wrote:

i would also favor switchting to the findbugs nullable annotations (now 
repackaged and maintained as spotbugs annotations).


AFAIU, we can't due to the license (LGPL).


we should remove the jsr 305 dependency from our parent pom, and probably add 
instead:

 
   com.github.spotbugs
   spotbugs-annotations
   3.1.5
   provided
   
 
   com.google.code.findbugs
   jsr305
 
   
 

in recent eclipse versions it's possible to configure multiple 
nullable-annotations - so it's possible to support both the javax.annotation 
and the findbugs annotations - making it easy working with already released 
sling artifacts still using the javax.annotation annotations. on the long run 
we should migrate away from those.

and we have to update [1] then. not we sure if we still need to support only 
"CheckForNull" - it would be nice to also support "Nullable" (in eclipse it's 
possible to configure both). the related jackrabbit ticket is [2].
...


See also  which for now 
has been resolved by switching to the Jetbrains annotations.


Best regards, Julian

RE: JSR 305 annotations (nullability)

[Stefan Seifert]

i would also favor switchting to the findbugs nullable annotations (now 
repackaged and maintained as spotbugs annotations).

we should remove the jsr 305 dependency from our parent pom, and probably add 
instead:


  com.github.spotbugs
  spotbugs-annotations
  3.1.5
  provided
  

  com.google.code.findbugs
  jsr305

  


in recent eclipse versions it's possible to configure multiple 
nullable-annotations - so it's possible to support both the javax.annotation 
and the findbugs annotations - making it easy working with already released 
sling artifacts still using the javax.annotation annotations. on the long run 
we should migrate away from those.

and we have to update [1] then. not we sure if we still need to support only 
"CheckForNull" - it would be nice to also support "Nullable" (in eclipse it's 
possible to configure both). the related jackrabbit ticket is [2].

should we do a vote on this?

stefan

[1] https://sling.apache.org/documentation/development/jsr-305.html
[2] https://issues.apache.org/jira/browse/OAK-7511


>-Original Message-
>From: Konrad Windszus [mailto:konra...@gmx.de]
>Sent: Tuesday, May 15, 2018 5:17 PM
>To: dev@sling.apache.org
>Cc: stilla...@apache.org
>Subject: Re: JSR 305 annotations (nullability)
>
>IMHO migration from JSR-305 to
>https://github.com/spotbugs/spotbugs/tree/release-3.1/spotbugs-
>annotations/src/main/java/edu/umd/cs/findbugs/annotations
><https://github.com/spotbugs/spotbugs/tree/release-3.1/spotbugs-
>annotations/src/main/java/edu/umd/cs/findbugs/annotations> is very
>painless, because the former evolved from the latter. You only need to
>adjust the package name but the semantics of the annotations are the same.
>Also it has most probably the best tooling/IDE support because those are by
>far the oldest nullability annotations (invented by FindBugs before JSR-305
>has even been started). Now they are actively maintained by the spotbugs
>community. I currently fail to see a better alternative, but I am open to
>other suggestions.
>Konrad
>
>> On 15. May 2018, at 17:12, Julian Reschke  wrote:
>>
>> On 2018-05-15 16:39, Konrad Windszus wrote:
>>> There are some ideas in https://issues.apache.org/jira/browse/SLING-7312
><https://issues.apache.org/jira/browse/SLING-7312> but not yet a solution,
>as even the proposed alternative spotbugs-annotations is not yet JSR-305
>free (which might be problematic from a licensing point of view). But IMHO
>the spotbugs annotations are the best alternative:
>https://github.com/spotbugs/spotbugs/tree/release-3.1/spotbugs-
>annotations/src/main/java/edu/umd/cs/findbugs/annotations
><https://github.com/spotbugs/spotbugs/tree/release-3.1/spotbugs-
>annotations/src/main/java/edu/umd/cs/findbugs/annotations>, because they
>are not bound to a specific IDE and are still supported by
>spotbugs/findbugs. The only thing I am not sure about is whether SonarQube
>natively supports spotbugs-annotations.
>>> Konrad
>>
>> It seems everybody agrees on the goal to move away, however it's not
>clear what to move to (see for instance,
><https://github.com/google/guava/issues/2960>).
>>
>> Best regards, Julian
>>

Re: JSR 305 annotations (nullability)

[Julian Reschke]

On 2018-05-15 17:16, Konrad Windszus wrote:

IMHO migration from JSR-305 to 
https://github.com/spotbugs/spotbugs/tree/release-3.1/spotbugs-annotations/src/main/java/edu/umd/cs/findbugs/annotations
 

 is very painless, because the former evolved from the latter. You only need to 
adjust the package name but the semantics of the annotations are the same. Also it 
has most probably the best tooling/IDE support because those are by far the oldest 
nullability annotations (invented by FindBugs before JSR-305 has even been started). 
Now they are actively maintained by the spotbugs community. I currently fail to see a 
better alternative, but I am open to other suggestions.
Konrad


...the Guava developers seem to have a preference on the ones used by 
the Checker framework. I personally don't care much, as long as we don't 
have to re-do this exercise too soon :-).

Re: JSR 305 annotations (nullability)

[Konrad Windszus]

IMHO migration from JSR-305 to 
https://github.com/spotbugs/spotbugs/tree/release-3.1/spotbugs-annotations/src/main/java/edu/umd/cs/findbugs/annotations
 

 is very painless, because the former evolved from the latter. You only need to 
adjust the package name but the semantics of the annotations are the same. Also 
it has most probably the best tooling/IDE support because those are by far the 
oldest nullability annotations (invented by FindBugs before JSR-305 has even 
been started). Now they are actively maintained by the spotbugs community. I 
currently fail to see a better alternative, but I am open to other suggestions.
Konrad

> On 15. May 2018, at 17:12, Julian Reschke  wrote:
> 
> On 2018-05-15 16:39, Konrad Windszus wrote:
>> There are some ideas in https://issues.apache.org/jira/browse/SLING-7312 
>>  but not yet a solution, 
>> as even the proposed alternative spotbugs-annotations is not yet JSR-305 
>> free (which might be problematic from a licensing point of view). But IMHO 
>> the spotbugs annotations are the best alternative: 
>> https://github.com/spotbugs/spotbugs/tree/release-3.1/spotbugs-annotations/src/main/java/edu/umd/cs/findbugs/annotations
>>  
>> ,
>>  because they are not bound to a specific IDE and are still supported by 
>> spotbugs/findbugs. The only thing I am not sure about is whether SonarQube 
>> natively supports spotbugs-annotations.
>> Konrad
> 
> It seems everybody agrees on the goal to move away, however it's not clear 
> what to move to (see for instance, 
> ).
> 
> Best regards, Julian
> 

Re: JSR 305 annotations (nullability)

[Julian Reschke]

On 2018-05-15 16:39, Konrad Windszus wrote:

There are some ideas in https://issues.apache.org/jira/browse/SLING-7312 
 but not yet a solution, as even 
the proposed alternative spotbugs-annotations is not yet JSR-305 free (which might be 
problematic from a licensing point of view). But IMHO the spotbugs annotations are the best 
alternative: 
https://github.com/spotbugs/spotbugs/tree/release-3.1/spotbugs-annotations/src/main/java/edu/umd/cs/findbugs/annotations
 
,
 because they are not bound to a specific IDE and are still supported by spotbugs/findbugs. 
The only thing I am not sure about is whether SonarQube natively supports 
spotbugs-annotations.
Konrad


It seems everybody agrees on the goal to move away, however it's not 
clear what to move to (see for instance, 
).


Best regards, Julian

Re: JSR 305 annotations (nullability)

[Konrad Windszus]

There are some ideas in https://issues.apache.org/jira/browse/SLING-7312 
 but not yet a solution, as 
even the proposed alternative spotbugs-annotations is not yet JSR-305 free 
(which might be problematic from a licensing point of view). But IMHO the 
spotbugs annotations are the best alternative: 
https://github.com/spotbugs/spotbugs/tree/release-3.1/spotbugs-annotations/src/main/java/edu/umd/cs/findbugs/annotations
 
,
 because they are not bound to a specific IDE and are still supported by 
spotbugs/findbugs. The only thing I am not sure about is whether SonarQube 
natively supports spotbugs-annotations.
Konrad

> On 15. May 2018, at 15:26, Julian Reschke  wrote:
> 
> Hi there,
> 
> does the Sling team have a plan how to move away from the JSR 305 annotations?
> 
> See
> 
> 
> 
> and
> 
> 
> 
> 
> It would probably good to coordinate with Jackrabbit Oak; see 
> ...
> 
> Best regards, Julian