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

Stephen Colebourne scolebourne at joda.org
Mon Nov 16 14:56:28 UTC 2009

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.


More information about the core-libs-dev mailing list