JSR 305 : Movement towards Software defect detection within the Code

Following are the notes / observations from video session (you can find video at google videos:
Google Video of JSR
I’ll express my opinion about Annotations over the course of next few posts ( I don’t like them personally; I will state my reasons later).

Core topics in Software development boils down to two things:
1.) How do you write bug free / less bug prone code; meaning if you are writing a simple method for example doing something trivial as taking two arguments (i am saying arguments and NOT parameters) and dividing both; returns remainder of the division, you would want two things to happen in this case :
• Both arguments are non null OR at the very least the denominator is NEVER null.
• Even though arguments are not null, sometimes my arguments be of incompatible types …
• How do you provide enough information about program behavior being predictible by using either tools or doing a “dry run” of the code (i.e. running code mentally).

Out of all of the above reasons; the general consensus is that “there is never enough information” for the compiler to “infer” things on its own by parsing the code and analyzing it. Therefore whereas additional information can be added on the behalf of the compiler, (like synthetic stuff in Java may be or something else) or annotations by users that go along with the code to provide some help as an add on info to compiler.
Basic idea of an Annotations (for Non knowers):
For those of you who are not familiar with annotations; i suggest you go through :
Annotations

For those of you coming from C#, you guys are already familiar with annotations I am guessing (I am looking for how it is in C# though, I am not familiar with it completely).
In short for helping Java Compiler, you provide additional information for it to infer some things on its own using them. For example; you could write something like:
@Test
Public void testSomething( )

And the frameworks (frameworks like TestNG, JUNIT use the above), would simply use the above annotation to invoke this method as a test. (Yeah … for those of us who have done a bit of coding in past with JUNIT may agree that It was such a pain to stub out test cases by doing something like: public void _testSomething( ) to allow the framework to ignore it; but anyways)
But the most common usage that comes to mind (it happens often) to some us is; wont it be great if we could have something like @NonNull or something of that sorts that provides compiler with enough information to infer and allow / disallow addition of certain values to a reference type or anything for that matter?
JSR 305 addresses above issues and allows (as part of language) to add annotations in more places … ( like List<@NotNull String> for example). If there’s something that all of us as programmers want it is that method parameters being annotated with NotNull so that at some point some tool gives some warning that the value “might” be null as soon as it is de-referenced somewhere.
3 Cases proposed:

1. @NonNull – Should be non null, for fields should be non null when the object is initialized. Tools (following this spec, or implementing this spec) will try to generate a warning when they see a possibly null value being used where a non-null value is required. (Note that all this happens at Compile time! Just to be clear; otherwise there’s no use of this tool or spec 
2. @Nullfeasible – code should always worry about the fact that this value might be null. Tools will flag a warning whenever a de-reference is NOT preceded by a null check.
3. @UnknownNullness – default annotation, similar to having NO annotations at all. Reason they are going to that route, they would introduce default and inherited annotations (to
4. over-ride a default behavior, say for example for this package I don’t know anything about nullness, but oh! For a specific case I might need Null check.)

Other suggestions include @NonNegative, @Signed, @NonSigned etc… work is still in progress.

Another interesting aspect that was discussed was to add something like:

when you pass parameters in a different order, you get weird behavior at Runtime! Rather than compiler complaining about it, this is because all above “parameters” are integer types … (small ints!); so it doesn’t matter.
The fix of this was pretty cool; you basically add @ResultSetType annotation (you must create such an annotation yourself and add this annotation to the method parameter that you want to typify ( for example in above I would write @ResultSetType annotation followed by resultSetType name) and the next time a programmer calls things in wrong order, well guess what compiler would complain!  (assuming that you add the @ResultSetType to small int static constants of ResultSetTypes you declared, which should have been an Enum in the first place.

For full details, refer to above video link.
Regards
Vyas, Anirudh