And I found the original thread, for reference:
http://www.mail-archive.com/core-libs-dev@openjdk.java.net/msg02950.html
Stephen
On 14 January 2011 11:30, Stephen Colebourne <scolebou...@joda.org> wrote:
> There are a number of strands to this thread
>
> 1) Null useful or not.
> There are arguments on both sides here, and developers are divided.
> Personally, I use null every single day to use not known or not
> required, such as in a search request:
>
> /**
> * The set of exchange object identifiers, null to not limit by
> exchange object identifiers.
> * Note that an empty set will return no exchanges.
> */
> private List<UniqueIdentifier> _exchangeIds;
> /**
> * The exchange keys to match, null to not match on exchange keys.
> */
> private IdentifierSearch _exchangeKeys;
> /**
> * The exchange name, wildcards allowed, null to not match on name.
> */
> private String _name;
>
> For me, null is incredibly useful. I understand those that want it
> removed, or push against it - I just disagree. (Thats why I want
> better null-handling syntax features). BTW, I believe but can't prove
> that far more people in the real world make use of null than avoid it.
>
> 2) Other utilities
> These are prior art that users are familiar with, just as much as the JDK.
> Google Guava - Objects:
> public static <T> T firstNonNull(T first, T second)
>
> Google Guava - Preconditions:
> public static <T> T checkNotNull(T reference)
>
> Commons Lang - ObjectUtils:
> public static Object defaultIfNull(Object object, Object defaultValue)
>
> Commons Lang - StringUtils:
> public static boolean isEmpty(String str)
> public static boolean isNotEmpty(String str)
> public static boolean isBlank(String str)
> public static boolean isNotBlank(String str)
> public static String trimToNull(String str)
> public static String trimToEmpty(String str)
> public static String defaultString(String str)
> public static String defaultString(String str, String defaultStr)
> public static String defaultIfEmpty(String str, String defaultStr)
>
> 3) Prior discussions
> When this was first raised I argued for the addition of a Validate
> (Commons Lang)/Preconditions (Google Guava)/Assert (JUnit) class
> alongside and separate from Objects. The "notNull" method would make
> much more sense there with its given name.
>
> Validate.notNull(foo)
>
> 4) Fluency
> The Objects.notNull code is designed for writing fluent code that
> asserts the non-null status of the value.
>
> public void process(String foo) {
> if (nonNull(foo).length() > 3) { ... }
> }
>
> This is a style/taste thing. Personally I prefer:
>
> public void process(String foo) {
> Validate.notNull(foo);
> if (foo.length() > 3) { ... }
> }
>
> I believe that the latter (my choice) is more in the spirit of the
> Java core libraries. (And I've used the latter style for many years
> with great success, whereas I wouldn't touch the assert keyword with a
> bargepole)
>
> It is critical to understand that the basis of the method as written
> is the fluency. Therefore "checkNotNull" simply isn't as readable:
>
> if (checkNotNull(foo).length() > 3)
>
> The suggestion of "nullChecked" is more fluent:
>
> if (nullCheked(foo).length() > 3)
>
> However, I still argue that this kind of fluency is not appropriate
> for such a core JDK class when compared to the Validate/Preconditions
> alternative.
>
> 5) Now
> *** If you are time-pressured, I'd recommend removing this method from v7. ***
>
> A "defaultIfNull" method would be much more useful in this class:
> public static Object defaultIfNull(Object object, Object defaultValue) {
> return object != null ? object : defaultValue;
> }
> andf much more in keeping (I wouldn't ever want to see the above
> method just called "notNull".
>
> Stephen
>
>
> On 14 January 2011 05:23, Brian Goetz <brian.go...@oracle.com> wrote:
>> Thinking some more:
>>
>> - The name nonNull() is just confusing. It could reasonably mean one of
>> several things, and we've seen this in people's reactions: some don't like
>> it for the throwing behavior because its not clear that it has a strong
>> checking behavior, others don't like it for the defaulting behavior because
>> the find the defaulting behavior unnatural. This suggests it is just too
>> vague to make anyone happy.
>> - I'm still enamored of checkNonNull() for the throwing version but am
>> still open to better names.
>> - If we add carpet-sweeping versions later, asNonNull() or makeNonNull()
>> both seem better than nonNull().
>> - We just stay away from the not-specific-enough name nonNull() here.
>>
>>
>>
>> On 1/13/2011 7:20 PM, mark.reinh...@oracle.com wrote:
>>>>
>>>> Date: Thu, 13 Jan 2011 18:15:30 -0500
>>>> From: brian.go...@oracle.com
>>>
>>>> ...
>>>>
>>>> Between checkNonNull() and throwIfNull(), I lean towards the former. In
>>>> any
>>>> case the answer should be driven by what is more obvious to the reader.
>>>
>>> Agreed.
>>>
>>>>
>>>> So
>>>> let's look at some typical code:
>>>>
>>>> public Moo fooWrapper(String x, String y) {
>>>> return foo(throwIfNull(x), throwIfNull(y));
>>>> }
>>>>
>>>> vs
>>>>
>>>> public Moo fooWrapper(String x, String y) {
>>>> return foo(checkNonNull(x), checkNonNull(y));
>>>> }
>>>>
>>>> Since throwing should be the exceptional path, it feels to me that having
>>>> throw
>>>> in the name sets slightly the wrong expectations. ...
>>>
>>> Agreed.
>>>
>>> I'm still troubled by the "check" prefix, though. It implies that the
>>> named condition will be tested but it doesn't clearly relate the result
>>> of that test to the method's exception-throwing behavior.
>>>
>>> Here's an idea: Why not treat this as a (degenerate) kind of conversion
>>> operation? Call it asNonNull(x) -- it (trivially) converts its argument
>>> to a non-null value, and if it can't then it throws an NPE.
>>>
>>> public Moo fooWrapper(String x, String y) {
>>> return foo(asNonNull(x), asNonNull(y));
>>> }
>>>
>>> Of all the names we've considered, this looks the most natural to me.
>>>
>>> - Mark
>>
>
