Community
Participate
Working Groups
I think 'Type mismatch' is a bit odd in the following strings. It should probably be 'Nullness mismatch'. 910 = Type mismatch: required ''@{0} {1}'' but the provided value is null 911 = Type mismatch: required ''@{0} {1}'' but the provided value can be null 912 = Potential type mismatch: required ''@{0} {1}'' but nullness of the provided value is unknown i.e. the new messages should be 910 = Nullness mismatch: required ''@{0}'' but the provided value is null 911 = Nullness mismatch: required ''@{0}'' but the provided value can be null 912 = Potential Nullness mismatch: required ''@{0}'' but nullness of the provided value is unknown where {0} is the annotation name. While M4 would be ideal, it is also OK to fix this in M5.
(In reply to comment #0) > I think 'Type mismatch' is a bit odd in the following strings. It should > probably be 'Nullness mismatch'. > > 910 = Type mismatch: required ''@{0} {1}'' but the provided value is null > 911 = Type mismatch: required ''@{0} {1}'' but the provided value can be null > 912 = Potential type mismatch: required ''@{0} {1}'' but nullness of the > provided value is unknown What's wrong with the message? null is not a legal value for the type '@NonNull Object' etc. Only provably non-null values are (safely) assignable to a variable of that type. Please see bug 186342 comment 110, where I switched from speaking of null contracts to considering null annotations as an extension of the type system. That's when the "Type mismatch:" wording got introduced - intentionally :) Also the wiki (http://wiki.eclipse.org/JDT_Core/Null_Analysis) uses this terminology since August. So this is nothing we should change in a hurry, if at all.
I also considered this in my review but the reasoning for moving from "contracts" to extension of a type system seemed sound. Also, I believe this was already clarified in discussions between Stephan and markus at ECE '11. Anyway, definitely *not* for M4 please, whatever you decide :)
(In reply to comment #1) > Please see bug 186342 comment 110, where I switched from speaking of > null contracts to considering null annotations as an extension of the > type system. That's when the "Type mismatch:" wording got introduced - > intentionally :) I like your original messages! :-) Sure researchers may think of null annotations as an extension of the type system, but would an average Java user also do so, given that Java does not have null-safe types at this point in time? - In Java do we have a precedent of '@Someannotation SomeType' being thought of as a different type from 'SomeType'? - Can you search for references of 'type' '@Nullable SomeType' in JDT? > Also the wiki (http://wiki.eclipse.org/JDT_Core/Null_Analysis) > uses this terminology since August. So this is nothing we should change > in a hurry, if at all. Sure, this can be done in M5 also.
This may be splitting hairs: These error messages are not coming from the eclipse java compiler, but are coming from the annotation processor for the null family of annotations. It is a different matter that in the current scenario, the compiler doubles as the annotation processor when a switch is on. If the notion of a type constrains the domain and range of values a typed entity may assume, then @Nullable and @NonNull, by virtue of further constraining or making express the range, act as modifiers for the type system. So personally I am comfortable with the current set of messages.
I first agreed that considering nullness as part of a type is not exactly what the JLS considers as a type. But from the view of the nullness annotation processor, the annotations are indeed considered as an extension of the type system, so from that POV, the term "Type mismatch" is fine. I'm a bit indifferent now, but I'd like to keep the type in the message. If we ever get JSR 308, then the annotation can even show up embedded in the type, e.g. "required '@NonNull List<@NonNull String>' but the provided value is '@NonNull List<String>'".
Given the overwhelming majority in favor of letting things be, closing this as WONTFIX.
