Code review: 7012540 (java.util.Objects.nonNull() incorrectly named)

[Ulf Zibis]

Am 28.01.2011 05:58, schrieb David Holmes:
> Rémi Forax said the following on 01/27/11 18:43:
>> On 01/27/2011 09:38 AM, Stephen Colebourne wrote:
>>> As I said before, removing this method is the best option now. Get it
>>> right in v8.
>>> Stephen
>>
>> I think we can't.
>> This method is already used at many place in the JDK.
>
> I think we can. Those usages will have to be modified anyway. If it is really the wrong decision 
> to add this now, and if we really can't get some consensus on the best name for the exception 
> throwing method, then we should remove it.
>
> I'm not saying we're in that position, just that if we were there's no reason we could not undo this.
>
> I think the utility and significance of this method is vastly over-estimated, and certainly not 
> worth the level of activity it has caused.
>

+1

If I understand right, please correct me, the motivation of this method was to force a better 
exception with shorter stacktrace in fail case, for easier to find the error's reason.
So this method is a kind of debug helper, which in real world doesn't help the program flow. but 
returns better error messages for support. In any case the software should be revised, so that the 
not-allowed nullity of an argument (1) can't occur or (2) invokes a well defined handling instead 
throwing a meaningless RuntimeException.

Can I see an example, where "assert x != null" wont help?

IMHO, we better introduce a debug helper class, which could contain things like "assertNotNull(x)".
Another idea is a language change:
Make "assert" to return the LHS argument.

-Ulf