Bug 490408

Comment 1 Ed Willink 2016-03-24 19:34:01 EDT

Correction the message is irritating for List<T>.

The message is useful for Reference<T> that I must annotate as @Nullable.

Just need to be able to annotate List.get as 'safe'.

Comment 2 Stephan Herrmann 2016-03-24 19:47:43 EDT

Did you see the entry in M6 N&N [1] ?

It explains how .eea can be used to address this.

[1] https://www.eclipse.org/eclipse/news/4.6/M6/#null-analysis-generics

Comment 3 Stephan Herrmann 2016-03-24 19:48:30 EDT

(In reply to Stephan Herrmann from comment #2)
> Did you see the entry in M6 N&N [1] ?
> 
> It explains how .eea can be used to address this.
> 
> [1] https://www.eclipse.org/eclipse/news/4.6/M6/#null-analysis-generics

See the paragraph starting "The dilemma can be resolved by ..."

Comment 4 Ed Willink 2016-03-25 03:08:00 EDT

(In reply to Stephan Herrmann from comment #3)
> See the paragraph starting "The dilemma can be resolved by ..."

Yes, it solves the primary use case, but is IMHO dangerously cute (and has no quickfix etc).

Consider the consequence of adding new List<T> methods

T firstElement() { return size() > 0 ? get(0) : null; }

T firstElementOrDefault(T default) { 
    assert default != null;
    return firstElement() != null ? firstElement() : default;
}

Now the dilemma is that get() needs to be safe but firstElement() needs to be @Nullable and firstElementOrDefault() needs to be @NonNull.

Comment 5 Stephan Herrmann 2016-03-25 09:37:18 EDT

(In reply to Ed Willink from comment #4)
> (In reply to Stephan Herrmann from comment #3)
> > See the paragraph starting "The dilemma can be resolved by ..."
> 
> Yes, it solves the primary use case, but is IMHO dangerously cute (and has
> no quickfix etc).

Adding a quickfix is planned.
 
> Consider the consequence of adding new List<T> methods
> 
> T firstElement() { return size() > 0 ? get(0) : null; }
> 
> T firstElementOrDefault(T default) { 
>     assert default != null;
>     return firstElement() != null ? firstElement() : default;
> }
> 
> Now the dilemma is that get() needs to be safe but firstElement() needs to
> be @Nullable and firstElementOrDefault() needs to be @NonNull.

That's not a dilemma: add a .eea where get() remains untouched, firstElement() gets the @Nullable and firstElementOrDefault() gets the @NonNull. Where's a problem?

Comment 6 Ed Willink 2016-03-25 10:01:20 EDT

(In reply to Stephan Herrmann from comment #5)
> That's not a dilemma: add a .eea where get() remains untouched,
> firstElement() gets the @Nullable and firstElementOrDefault() gets the
> @NonNull. Where's a problem?

Technically, none. A per-Operation absence of annotation has the flexibility.

Editorially, "The dilemma can be resolved by adding a (possibly empty) external annotation file (.eea) to each affected library class. By using an empty annotation file, the user signals that all types in this class should be interpreted verbatim (like in the List case - use with care). " needs rewording to make clear that it is a per-Operation annotation absence that resolves a per-Operation dilemma, not a total absence ("empty annotation file") annotating everything.

"By using an incomplete annotation file, the user signals that all unannotated types in unannotated declarations should be interpreted verbatim"

Comment 7 Stephan Herrmann 2016-04-19 17:04:37 EDT

(In reply to Ed Willink from comment #6)
> (In reply to Stephan Herrmann from comment #5)
> > That's not a dilemma: add a .eea where get() remains untouched,
> > firstElement() gets the @Nullable and firstElementOrDefault() gets the
> > @NonNull. Where's a problem?
> 
> Technically, none. A per-Operation absence of annotation has the flexibility.
> 
> Editorially, "The dilemma can be resolved by ... " needs rewording ...

I'll try to resolve this in the user documentation.

Comment 8 Manoj N Palat 2016-04-27 04:31:46 EDT

Verified for Eclipse Neon 4.6 M7 Build id: I20160425-1300