The other good benefit from this rename is that "requireNonNull" is much more expressive when used as a static import.
On Tue, Jan 25, 2011 at 2:24 PM, Brian Goetz <brian.go...@oracle.com> wrote: > There is a webrev for CR 7012540 (java.util.Objects.nonNull() incorrectly > named) at: > > > http://cr.openjdk.java.net/~briangoetz/7012540/webrev/<http://cr.openjdk.java.net/%7Ebriangoetz/7012540/webrev/> > > Code review would be appreciated. > > Text of CR: > > The class java.util.Objects is new for JDK 7. Its mission is to provide > "null-safe or null-tolerant versions of common operations on objects." > > The methods nonNull(x) have the behavior of throwing NPE if their argument > is null, and returning their argument if non-null. It is very common in > Java source bases for a method named nonNull(x) to have the behavior of > coercing their argument to null; that is, it is generally associated with a > null-tolerant rather than a null-safe behavior. > > These methods should be renamed to something that makes its > checking/verification behavior clear, while preserving the convenient > self-return property so that it can be used in cases like: > > public void fooWrapper(String s, String t) { > foo(checkNonNull(s), checkNonNull(t)); > } > > > Additional notes: After much discussion on core-libs-dev, the name > requireNonNull() seemed the least objectionable. > >
