What methods should go into a java.util.Objects class in JDK 7?

[Osvaldo Pinali Doederlein]

+1 for Elvis operator, +1000 for [non-]nullability support in the 
typesystem like Fan. Ideally, the latter featutre should be supported at 
the bytecode level (not sugar) so a big number of variables would be 
hard-tagged as never null, which I suppose would result in faster code 
without dependency on nullcheck removal optimizations that are not 
always feasible and even when possible, have costs like code bloat.
+0.5 for the two Objects.nonNull() methods. They are useful at least 
because they avoid double evaluation. I'd prefer all Objects methods to 
live in the global namespace - just static-import Objects.* by default - 
but I understand the issues. And I'd prefer to rename these methods to 
nvl(), identical to SQL so it's a good name even if terse, and I prefer 
terse names in functions that are likely to be used multiple times in 
complex expressions (many people prefer a operator like Elvis because 
even nvl() may be too cumbersome).
-1000 for automatic swallowing of nulls like JavaFX Script, that I 
reported as a bug (http://javafx-jira.kenai.com/browse/JFXC-3447).

Just my 2c.

Em 16/11/2009 14:28, Marek Kozieł escreveu:
> 2009/11/16 Stephen Colebourne<scolebourne at joda.org>:
>    
>> 2009/11/16 David Holmes - Sun Microsystems<David.Holmes at sun.com>:
>>      
>>>> In this specific case, the question was "why include it when you can
>>>> use a?b:c". Well, I've seen resistance by developers to that language
>>>> feature, and I know some places outright block it in coding standards.
>>>> For many, a method call is preferred, and "overhead" isn't what
>>>> matters.
>>>>          
>>> I find such a mentality to programming to be utterly incomprehensible. Who
>>> are these people? And what motivates them?
>>>
>>> I say let these people define their own libraries to support their
>>> pathologies - don't lumber it on the rest of the general population of
>>> programmers.
>>>        
>> This is where things can get very heated, so please take this as just
>> my take on what I see.
>>
>> The community that defines Java - Sun, Google, Open Source, Bloggers -
>> are, in general, the experts and gurus in the field. Most people
>> reading this list have no problem with the ternary statement. Most of
>> us realise that null avoidance is better than null-handling. However,
>> we are, by far, the *minority* of Java developers, not the majority.
>>
>> My call is not to let the majority rule, but to understand that the
>> quality code and standards of Sun/Google/SiliconValley are far, far
>> rarer everywhere else. Sometimes as leaders it is necessary to accept
>> that not everyone is going to do things the 'right' way, and sometimes
>> it is better to help mitigate the 'wrong' way (hence Elvis and
>> friends). In other words, what do you do when telling people to do the
>> right thing fails?
>>
>> As I say, this is as much about opinion and what you have experienced
>> as hard facts. For example, I know that nulls and null-handling is
>> everywhere in the codebase I work on, and I don't consider that to be
>> especially wrong or broken, nor do my colleagues.
>>
>> BTW, for the future I'd remind everyone of Fan - http://fandev.org -
>> where all variable references are non-null by default, something which
>> we should all support.
>>
>> Stephen
>>
>>      
> I agree with Stephen.
>
> In real word you have to deal with "pathologies" which are made by others.
> When you deal with muck you need pitchfork not a white gloves.
>
> I discuses a lot about Elvis null-safe operator and conclusion was always same:
> Java without it is better, but there is a lot of cases when we need it
> to deal with crappy code.
>
>