No, jsr305 should be abandoned or restarted from scratch. With all due respect to Bill Pugh, the current findbugs annotations don't seem to be particularly well thought out. I'd love to see a well thought out set of annotations, though.
For example, here's the Nullable annotation, straight from trunk: http://code.google.com/p/jsr-305/source/browse/trunk/ri/src/main/java/javax/annotation/Nonnull.java What the heck is all that when stuff? @Nullable(when=When.NEVER) actually means @NotNull. That's crazy. There's also the defaulting mechanism; by annotating classes or packages with for example this: http://code.google.com/p/jsr-305/source/browse/trunk/ri/src/main/java/javax/annotation/ParametersAreNonnullByDefault.java you can save a programmer the annoyance of having to @NonNull all his parameters. Unfortunately any kind of flexible defaulting weakens the strength of code snippets: A method declaration ceases to be portable, and ceases to be interpretable, without the appropriate context. This is to a certain extent true of all code, but this is a particularly problematic version of it: In the _vast_ majority of use cases, you'd never notice that your parameter just switched from nullable to never null or vice versa. Better to leave defaulting out for now and think of something less marred by serious problems, which can always be added later. jsr305 (the set of extra annotations) are also dependent on jsr 308. You can't have jsr 305 without jsr 308 (or at least, not the current set). jsr 308 lets you annotate types directly. Right now you can annotate a method or a parameter which is often interpreted as an annotation on a type, but you can't, for example, annotate a type in generics (List<@Foo String> foo; is illegal right now), nor can you annotate for example the type present in a cast. jsr308 has been excluded from the JDK7 set. Presumably because its not ready enough to meet the now very stringent deadline for JDK7. jsr305 clearly cannot be ready for JDK7 if its dependency, jsr308, isn't either. One solution is to create a new jsr which includes just a basic subset of the jsr305 annotations that nobody is currently worried about and which aren't type-based annotations, though this set isn't particularly large. We'd have: OverridingMethodsMustInvokeSuper CheckReturnValue WillClose / WillCloseWhenClosed / WillNotClose ThreadSafe NotThreadSafe GuardedBy Dropped by the wayside: All type annotations, the 'when' meta- framework, @Immutable, and @NonNull / @Nullable. In case you don't see why immutable, nonnull, and nullable aren't ready: Immutability: Actually, immutability is complicated. For example, java.io.File seems immutable for all intents and purposes, and has some of the practical properties of immutables (such as: cloning a File object is pointless, as is making a defensive copy), and certainly looks like one (only final fields, and the class is even final itself), and you can even share them between threads without synchronization, but nevertheless it clearly looks like a mutable: Something like .mkdir() or .delete() changes some state (it's just not state in the object that you're changing!), and something like .isFile() is not predictable (i.e. it can change over time, which is a property of mutables). Similar issues exist for read-only wrappers around mutable lists. Are these 'immutable'? jsr305 has a definition for this, which is focused around the notion of never being able to see any of an object's state change. However, the definition itself as given in the current javadoc is broken; it means that an object that is capable of changing another object, but is NOT capable of telling you this happened, is immutable. Such an object is not thread-safe, but the javadoc says that any immutable is necessarily thread-safe. Hence: broken. It's clearly far too complicated to include now, given the small window of time to investigate. NonNull / Nullable: There's actually 4 states of nullability, not 2. There's "definitely never null", there's "definitely allows null", there's "Either way", and "legacy". This is entirely analogous to the 4 states of a generics type parameter: X, "? super X", "? extends X", and raw. Properties of these states: Definitely Never Null: incoming: No need to nullcheck. outgoing: Cannot return null, or something that might be. Cannot be null. Definitely allows null: incoming: Need to null check. outgoing: Allowed to return null, or something that might be. Can be null. Might allow null: incoming: Need to null check. outgoing: *NOT ALLOWED* to return null, or something that might be. Can be null. Legacy: Everything goes, though you might get warnings. Required for the same reason raw types are required: To ensure code written before this system is in place continues to compile. The third one (Might allow null) shows up for the same reason generics is so complicated: If you want to write a method, that, say, takes in a list, inspects some elements in it, and then adds an element to it, and this method null-checks every item it reads, and never writes null into the list, then it doesn't matter if you give it a list of nullable strings or a list of never-null strings. It'll work fine on either. However, you need to be able to express this fact. Just like List<Number> and List<Integer> are totally separate types, so is List<@NonNull String> and List<@Nullable String>. Just like you need List<? extends Number> in order to accept either a List<Number> or a List<Integer>, so you also need a List<@EitherNullity String> in order to write a method that'll accept both List<@NonNull String> and List<@Nullable String>. Given that you cannot overload based on generics /annotated types alone, shipping nullity support without considering this issue would be a big mistake. One alternative is to offer double bounds; might allow null is effectively the same thing as something like: List<? super @Nullable String extends @NonNull String>. However, aside from being both unwieldly and a new language feature all by itself, having to wrap your mind around why that is effectively equal to @EitherNullity String is very complicated. Besides, nullity clearly needs jsr308 to work. TLDR: jsr305 is not ready. On Oct 10, 5:11 am, "[email protected]" <[email protected]> wrote: > I enjoyed the episode too. I've listened to it more than once. > > Let me add a +1 vote for Tor's prompting of adding JSR305 (Annotations > for Static code analysis) to Java 7 > > It'll be interesting to see how the JCP responds to the JSR. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
