Comments on: JSR 305: a silver bullet or not a bullet at all?

By: Adam Gent

Adam Gent — Thu, 19 Aug 2010 18:10:34 +0000

I think the real benefit to having something like @NonNull is better documentation.
Annotations can be included in Java Doc.
I can’t tell you how many times have written java doc stating whether or not parameters can be null or whether the return value will be null.

@NonNull would provide a consistent way of documenting this.
Otherwise if you are looking for better static analysis perhaps a language such as Scala or F# would be better suited. Typing final in-front of every object is just to much of a pain in the butt.

By: Andreas Krey

Andreas Krey — Fri, 16 Apr 2010 15:28:47 +0000

It is quite funny: The exact arguments against @nonnull could also be used against specifying the parameter type in methods (and elsewhere). Those can just as well be inferred by global analysis. After all, @nonnull only exists because the java designer allowed null to be used in places where an Whatever is expected even though null clearly does not honor the contract of any Whatever. When allowed nullness of a value would have to be declared, NullPointerException could easily be a checked exception.

By: How to avoid “!= null” statements in Java? « Technical Jottings

How to avoid “!= null” statements in Java? « Technical Jottings — Thu, 28 Jan 2010 09:25:15 +0000

[...] Java has proposed for the null type annotation in JSR 305 and the proposal has some contradictions described here. [...]

By: Lars Ræder Clausen

Lars Ræder Clausen — Wed, 29 Jul 2009 12:46:21 +0000

I completely disagree with your suggestion that whole program analysis can take the place of annotations. Whole program analysis cannot reason about JNI code or code that is provided at run time, and it cannot say anything about future changes. Furthermore, any automatic analysis is only a conservative guess, whereas explicit annotations are a contract. Having a contract makes it a lot easier for the compiler to check – doing full-program analysis is most certainly a huge task in the presence of large libraries. I look forward to having @Nonnull available (especially since they added the @Default annotation).

By: Mikhail Ksenzov

Mikhail Ksenzov — Thu, 09 Apr 2009 16:01:39 +0000

Thank you for your comments guys. Here is a couple of thoughts:

About maintenance cost:

I tend to agree that it is a good idea to invest time and effort in automated testing (such as junit tests) or automated verification (such as adding some metadata with annotations). However it makes sense only in the cases when the testing and verification are the only way to check your code. There is no reason to add tests for the defects which would be caught by compiler. You can think of the static analysis tool as a compiler on steroids. Most NPEs can be detected by modern tools w/o any human effort, if the tools are doing their jobs.

In the following posts I would like to show when using the annotations for defect detection makes sense and where it does not.

About final values:

Even if you declare all the variables and parameters as final ones it would not fix the NPE problems in the snippets above. Saying that I think that using final values where possible is the good practice, though totally unrelated to the blog post.

By: TeLryarroma

TeLryarroma — Thu, 09 Apr 2009 06:28:41 +0000

FANTASTIC!

By: Ex Boyfriend

Ex Boyfriend — Wed, 08 Apr 2009 22:49:19 +0000

Not that I’m impressed a lot, but this is a lot more than I expected for when I stumpled upon a link on SU telling that the info is quite decent. Thanks.

By: Fabrizio Giudici

Fabrizio Giudici — Thu, 02 Apr 2009 20:11:51 +0000

I agree with Mikko’s second paragraph: indeed I think the time spent to put annotations and ensure they are consistent is very well spent, as it forces you to be precise with your design. Also, if you adopt standard practices such as using mostly @NotNull (e.g. by using NullObject or SpecialCase patterns) the amount of work is really reduced.

The fact that things in Java are not final by default is no excuse for developers not using the “final” keyword as much as possible ;-)

By: Mikko Kauppila

Mikko Kauppila — Wed, 01 Apr 2009 16:25:08 +0000

The tragedy is that Java designers chose to make all variables non-final and nullable by default. This makes inter-procedural analysis difficult since the analyzer cannot assume pretty much anything. Also, classes are non-final by default, which makes inter-procedural analysis even harder (since dynamic dispatch due to inheritance may occur).

I disagree about the maintenance cost associated with annotations. This is akin to saying that unit tests are bad since they need to be updated whenever contracts change. Maintaining the annotations — or unit tests, for that matter — means that you’re managing the correctness of your code, which is only right.

The last snippet (with methods “test” and “saveName”) you present is indeed hard to analyze. However, it can be argued that it duplicates information: whether the entity has a qualified name is a property of the entity itself, and should not be passed as a separate parameter (“boolean qualified”). My humble opinion is that programmers should strive to write code that’s easy to analyze.

Otherwise, your post was good and informative.