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/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.
>
>
--
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.
