With the 4 states I described? No, your anyAreNull cannot statically check if you're passing definitely-never-null to it. You'd need more states. A standard library method can't change the nullity of parameters, but code analysis can. If you remove anyAreNull and make it if (x == null || y == null || z == null) instead, then you won't get warnings.
On Oct 11, 10:28 pm, Ricky Clarkson <[email protected]> wrote: > I wonder whether nullability can sanely deal with this: > > void foo(@Nullable String name, @Nullable String address, @Nullable > String telephone) { > if (anyAreNull(name, address, telephone)) > System.out.println("At least one of those was null."); > else > System.out.println("Total length: " + (address.length() + > name.length() + telephone.length()); > > } > > anyAreNull returns false if any of those are null, true otherwise, but > can any static checking reflect that, or will I get nullable warnings > when I use name in the else branch? > > > > > > > > On Mon, Oct 11, 2010 at 9:18 PM, Reinier Zwitserloot <[email protected]> > wrote: > > 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... > > > 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... > > > 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 > > athttp://groups.google.com/group/javaposse?hl=en. -- 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.
