null related annotations

Jay Shaughnessy jshaughn at redhat.com
Tue Jul 10 15:22:28 UTC 2012


OK, from DinoLand, I'm not a big fan of anything proposed so far. I 
don't think we should use IJ annotations, I'd prefer we use something 
standard to Java.  I am a fan of jdoc, which we rarely use but could use 
more often.  I like being able to hover over a method call, or a list of 
autocompletions,  and see useful info about the call.  Even if it is 
simple info about the params or return value.

If we do use @NotNull I'd prefer to see it only at the method/return 
level.  Injecting annotations in the argument list makes code pretty 
unreadable imo. it just gets too verbose.   And unreadable code leads to 
coding mistakes.

Also, if we use @NotNull I think you'd also need to use @Nullable, 
because otherwise you don't know if the writer simply forgot to add the 
annotation, and then you're off looking at the imp to figure it out.  Of 
course this would be a major task to add all over the place.

Also, is we adopt something, we need to ensure Eclipse and IJ both 
handle formatting and hover intelligently.  I don't want to have to 
visit the impl to see if it's annotated.  I want that info presented to 
me.   And formatting differences will kill us more than we're already 
getting beat up.

Some options:

  * jdoc anything a caller should know.
  * write code that handles null arguments.
      o IllegalArgumentException is better than NPE)
      o callers will still pass in nulls even if it is annotated or jdoc'd
  * don't return nulls when you can return empty collections.


On 7/10/2012 10:02 AM, mike thompson wrote:
> 4) The pragmatic Google Guava library (even works with GWT) has an 
> Optional<T> wrapper that provides:
>
> Optional<Integer>  possible=  Optional.of(5);
> possible.isPresent();  // returns true
> possible.isAbsent()// returns false
> possible.get();  // returns 5
>
> http://code.google.com/p/guava-libraries/wiki/UsingAndAvoidingNullExplained
>
> This makes the null checks explicit and the code reads nicely (IMO).
> And there is the preconditions to go along with that:
>
> checkNotNull(T) 
> <http://docs.guava-libraries.googlecode.com/git-history/release/javadoc/com/google/common/base/Preconditions.html#checkNotNull%28T%29>
> this.field = checkNotNull(field).
>
> and also sprintf formatting:
>
> checkArgument(i<  j,  "Expected i < j, but %s > %s",  i,  j);
>
>  As a bonus you get all the cool google collections and caches:
> http://code.google.com/p/guava-libraries/wiki/NewCollectionTypesExplained
> http://code.google.com/p/guava-libraries/wiki/CachesExplained
>
>
>
>
> On Jul 10, 2012, at 6:29 AM, Charles Crouch wrote:
>
>> Mike T's mention of @NonNull annotations this morning reminded me I'd 
>> done some research on this recently, so I thought I would send out my 
>> notes. Lets start the discussion/flamefest...
>>
>>
>> Basically I'm a big fan of anything that can help us catch NPEs at 
>> compile time rather than runtime, so I think if we can agree on an 
>> approach, we should adopt it and embrace it.
>>
>> One of the issues folks have had historically is that RHQ has 
>> generally used Intellij's annotations but with nothing setup in the 
>> main mvn build to check these annotations, the only people to get any 
>> benefit from them were intellij users. Well now there are now *lots* 
>> of alternatives to intellij's:
>>
>> http://stackoverflow.com/questions/4963300/which-notnull-java-annotation-should-i-use
>>
>> e.g. eclipse, findbugs, jsr305, istack (from sun), javax.validation 
>> all offer their own set of annotations. We shouldn't use istack 
>> apparently: http://stackoverflow.com/a/4963565 and the 
>> javax.validation are only meant for runtime not compile time checking.
>>
>> Unfortunately there is still no standardized set of annotations 
>> around handling nulls. JSR305 isn't going anywhere apparently and 
>> JSR308 won't land until jdk8 
>> (http://stackoverflow.com/questions/1476757/jsr305-vs-jsr308-java-type-anotations-which-is-going-to-be-the-standard)
>>
>> Even more painfully there doesn't even seem to be consistency in the 
>> names of the annotations across implementations:
>>
>> For things whose value can't ever be null:
>> @NonNull(eclipse, findbugs), @Nonnull(jsr305), @NotNull(intellij)
>>
>> For things whose value can be null:
>> @CheckForNull(findbugs, jsr305), @Nullable(intellij, eclipse)
>>
>> For things whose value if it is null, it may be fine or maybe a 
>> problem???
>> @Nullable(findbugs, jsr305)
>> [IMHO this is pointless and better just to not put any annotation]
>> http://findbugs.sourceforge.net/manual/annotations.html
>>
>>
>>
>> So what can we do? Well here are the options I can think of, please 
>> add more...
>>
>> 1) We could keep using the intellij annotations and combine that with 
>> running findbugs as part of the main build to enforce them.
>> Findbugs actually has support for converting intellij annotations 
>> into one's it knows about:
>> http://code.google.com/searchframe#Fccnll6ERQ0/trunk/findbugs/src/java/edu/umd/cs/findbugs/ba/NullnessAnnotation.java
>>
>> 2) We could define our own annotations and combine that with running 
>> findbugs as part of the main build to enforce them.
>> The only restriction is we have to use the same Classnames as 
>> findbugs, see link above, e.g. org.rhq.NonNull and org.rhq.CheckForNull
>>
>> 3) Or we could use the checker tool, which seems like it is going to 
>> be the RI for jsr308: 
>> http://types.cs.washington.edu/checker-framework/current/checkers-manual.html
>> This seems by far the sophisticated and flexible solution: "Your goal 
>> is to add @Nullable annotations to the types of any variables that 
>> can be null. (The default is to assume that a variable is non-null 
>> unless it has a @Nullable annotation.) Then, you will run the 
>> Nullness Checker."
>> The downside with this option is that it seems to want to replace 
>> javac, with its own updated version that supports jsr308. 
>> "Eventually, you will be able to use any Java compiler, such as the 
>> OpenJDK compiler, but Oracle has been slow to incorporate all the 
>> patches, so the bundled javac is superior, for the purpose of 
>> pluggable type-checking, and is equivalent in all other respects." 
>> It's not clear to me how this would work for people just checking out 
>> RHQ or in the product build environment.
>>
>> 4)...
>> _______________________________________________
>> rhq-devel mailing list
>> rhq-devel at lists.fedorahosted.org
>> https://fedorahosted.org/mailman/listinfo/rhq-devel
>
>
>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel





More information about the rhq-devel mailing list