So what you're saying is that one needs to repeat code instead of being able to use library functions. null--;
On Tue, Oct 12, 2010 at 10:09 AM, Reinier Zwitserloot <[email protected]> wrote: > 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. > > -- 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.
