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

[Stephen Colebourne]

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 
various features (including diamond type inference, ARM and map literals 
vs pair literals) and their proposed implementation. The question is 
whether the choices made *now* will hinder future evolution of the Java 
language. Because we (the Java community, and, I strongly suspect, Sun) 
have no clear view of where Java is going, it becomes impossible to 
judge whether those choices are the right ones or not.

In this specific case, again we have a case where a change *now* may 
hinder the future evolution of the JDK libraries. If we add nonNull to 
"Objects", then it will be in the wrong place and confusing if we then 
add a "Validate" class in JDK8. Or we all have to accept duplication.

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).

Because the remit is so narrow, we don't get to properly examine more 
broadly what additions are needed to the core libraries. As such, it 
feels like the decisions taken here and now have the potential to be 
remarkably hit and miss.

Stephen