Eclipse Juno M4 includes support for annotation based null analysis. To take advantage of the feature enable the preference shown below and start using the default annotations mentioned in the text fields.
You will also notice that all the null analysis related options have moved to a new group on the preference page.
As usual feedback is extremely welcome especially in form of bug reports :-)
UPDATE: JDT provides default annotations which are shipped in org.eclipse.jdt.annotation bundle with the Eclipse SDK. However you are free to use your own annotation types, just specify the custom annotations in the preferences.
You will also notice that all the null analysis related options have moved to a new group on the preference page.
As usual feedback is extremely welcome especially in form of bug reports :-)
UPDATE: JDT provides default annotations which are shipped in org.eclipse.jdt.annotation bundle with the Eclipse SDK. However you are free to use your own annotation types, just specify the custom annotations in the preferences.
Will the dependency for org.eclipse.jdt.annotation.* be deployed to maven central? Otherwise no maven (or ant+ivy) project can even entertain the idea of using these annotations. :-(
ReplyDeleteMake sure this is in Maven Central, otherwise you won't be able to compile unless you have those dependencies. I'd be careful of including IDE specific functionality into the system. Annotations are great, as long as they are freely distributable and don't have dependencies on IDEs to be used.
ReplyDelete@joakime, @David The annotation bundle is part of the Eclipse SDK. What exactly needs to be deployed to Maven Central?
ReplyDeleteGreat! What next in support from JDT?
ReplyDeleteconcurrency annotations & analysis to get better code for multicore processors? Maybe OS resource memory leak annotations & checks?
See http://eclipseandjazz.blogspot.com/2011/12/inter-procedural-null-analysis-using.html for more details.
ReplyDeleteA jar containing the annotations (Nullable, NonNull, NonNullByDefault, …) needs to be deployed to Maven Central so anybody using Ant/Ivy/Maven/Gardle/… can use it in their regular builds (anything besides PDE build/Typcho).
ReplyDeleteAlright, an important goal in implementing this analysis in the JDT is: devs should have no excuse when *not* using null annotations, everything should be right there at their finger tips in their favorite IDE, feedback will be given instantly.
ReplyDeleteSounds like you came up with the next excuse: the annotation types are not there! For one: you may even use your own annotation types and push them to what ever repo you want them in, but that's a weak excuse.
So, yes, we want that tiny little bundle to be available as easily as possible for everyone. From the JDT/UI side we have https://bugs.eclipse.org/366014, for the maven issue we could probably use some help, so I filed https://bugs.eclipse.org/366298
Finally! JSR-305 (@Nullable annotation) is rather old, as was bug 186342. Congratulations for a really useful feature.
ReplyDeleteTo make this even more useful: Add these annotations to the JavaDoc tooltips and when auto-completing method parameters.
Great work! Looking forward to using this.
ReplyDeleteAre you familiar with the FindBugs work on this? They also have the CheckForNull annotation. The difference with Nullable is that if a value is annotated with CheckForNull, it must be checked for null before dereferenced or passed to a NonNull value. Nullable, on the other hand, may be used without checking.
ReplyDeleteIt's awesome default support for this is coming in Eclipse. I think it would be a good thing if the behavior matches FindBugs if there is no reason to deviate. They support this for years and lots of people (including me) already use it.
On a similar note, custom annotation name support is great. There will probably will be the need for a list of names though, in case libaries like Spring or Google use different names for NonNull annotations. Oh JSR305 where are you...
@Peter:
ReplyDeleteYes, we are aware of FindBugs.
After talking to various people from similar projects it turned out that all agreed on the concepts of two annotations, with one sad exception: the FindBugs' idea of @Nullable doesn't fit into any well-defined model that I know of.
The problem with the FindBugs semantics of @Nullable is that it lacks clear conceptual foundation but has been invented to support heuristics for catching *some* NPEs.
By contrast, the work in JDT aims at a system where eventually *all* NPEs are detected at compile time (a few things are still missing, notably JSR 308). This goal cannot be achieved using the FindBugs approach.
Re JSR 305: I suspect that the above is actually one of the reasons why that JSR stalled: in order to become a standard people would have to agree on one semantic model, but no-one outside the FindBugs team would agree on the annotations as they are proposed in that JSR.
If you want to map FindBugs annotations to the JDT, please map @CheckForNull to @Nullable and try to avoid FindBugs' @Nullable. The best approximation for FindBugs' @Nullable is: unspecified, i.e., no annotation.
any maven plugin out there which brings the null analysis also to the build machine?
ReplyDelete@maggus: you may want to include org.eclipse.tycho:tycho-compiler-plugin in your pom, then you can tell the maven-compiler-plugin to use the compiler with compilerId "jdt".
DeleteSee also http://www.eclipse.org/tycho/sitedocs/tycho-compiler-plugin/plugin-info.html
I would love to use these annotations, but I'm quite disappointed that there is no easy way to use it with maven. I'm not really interested in the compiler warnings while building in maven (I'll check them in Eclipse)-- I just want it to build. I was expecting to find an eclipse annotations jar somewhere in the maven central repository, but after all this time it still doesn't seem to be there.
ReplyDeleteToo bad...