nonNull and similar methods [was Re: First round of java.util.Objects for code review (bug 6797535)]

[Joe Darcy]

Stephen Colebourne wrote:
> Joseph D. Darcy wrote:
>> If such a validation class is added to the platform, the nonNull 
>> methods can be moved there.  Until then, they can live in Objects.
> At first glance, such an approach makes perfect sense. However, we
> should really stop and question whether it is right or not.
>
> One point that has been made about Java over recent times is that it
> lacks a clear direction. A number of small changes are being added
> (Project Coin and here) which don't necessarily have a cohesive goal. To
> my eye it seems that one reason for these getting the go-ahead is that
> they are suposedly low-risk and low-issue. Each individual change seems
> small and relatively minor that sometimes its tempting to think that
> they can cause no harm. Yet even with these seemingly simple changes we
> find that the lack of a clear vision for Java kicks in and causes 
> trouble.
>
> I mention Coin here, because there have been real debates there on

There have more often been long exchanges dominated by heat rather than 
light, but that is not unique to the Coin list.

[snip]

> More broadly, and looking at this discussion overall and Joe's
> responses, I read between the lines that Joe only has approval to add a
> single class "Objects", and no other classes (such as "Hasher",
> "Joiner", "Strings", "Validate", and many others we might find useful).

My side project here is defining java.util.Objects.  It is not defining 
"Hasher," "Joiner," "Splitter," "Validator," or any other possibly 
useful class.  Anyone else is free to send in proposals, 
implementations, and tests for such facilities and someone might offer 
to sponsor such proposals through the currently Sun-internal processes 
to get API changes in JDK 7, as I've recently offered to do for String.join.

-Joe