abandon Guava Constraints ?

[Tom Zeller]

>> I think that annotating a returned Collection with @NonnullElements
>> does not raise sufficient awareness that adding a null element to the
>> Collection will result in an NPE.
>
> Well, awareness and behavior are somewhat distinct. I think from a caller PoV, the annotation should be sufficient (along with just a general design note that I think we want all our collection APIs to be considered guarded now). But we definitely want guarded collections, IMHO.

I am not questioning guarded collections, I am questioning
implementation of them via a deprecated "dead-end" Guava class.

I was surprised by the behavior of @NonnullElements. The Javadoc says
"does not contain any null elements" but does not say "throws an NPE
if a null element is added" while the wiki documents @NonnullElements
as "whether a collection may contain null elements or not". I think we
should be really clear when dealing with NPEs.

I agree that annotations should be sufficient from a caller PoV, but I
think they are not. Partly because as an Eclipse user, annotations
only appear when generating Javadoc but not in the Outline view, for
example.

>> The Java Coding Conventions should be revised as they suggest use of
>> our Assert class, which was later renamed to Constraint, which is
>> different from a Guava Constraint.
>
> I didn't remember that offhand. So the only place we use it is in some of the attribute code, I guess? We could rewrite those constraints ourselves.

We use Guava Constraints in a variety of places. If we used our
Constraint rather than Guava's, then we could throw our
ConstraintViolationException rather than an NPE.


TL;DR Consider alternatives to deprecated Guava Constraints and
improve documentation of @NonnullElements.