

Java 7 : The new java.util.Objects class  - noarchy
http://www.baptiste-wicht.com/2010/04/java-7-the-new-java-util-objects-class/

======
chipsy
I was actually just thinking recently about eliminating unchecked null errors
in my haXe code, went looking through the features and discussions, and came
up with two "today" solutions and one "proposed for the future". In light of
how little Java seems to be doing to eliminate those errors, maybe they will
interest:

-Right now it's possible to use the haXe Enum to implement a form of "Maybe" type: calling some "get" function returns the Maybe, and then you do a switch statement on it. From there the compiler forces you to cover all cases.

Caveat: Enum is quite a slow feature.

-I can force the "get" function to pass in handling code for null and non-null cases as arguments.

Caveat: Requires the handlers to be full functions, not just expressions,
which is bulky and inflexible. This should be doable in Java too, but without
inference, you might have to fight the type system more to get it right.

-Macros are proposed: Then I can turn my "get" function into a "get" macro that forces me to always provide the null handler.

Caveat: It's a bit more involved than a Maybe type, which would do the compile
checks automatically.

Overall, I'm really happy with where haXe is going. It's growing some really
useful features while remaining a cross-target language. If macros get
in(hotly anticipated, but probably not soon) it'll be a very exciting time for
the language.

------
gfunk911
Aren't these just one line utility methods that a user could write themselves?

~~~
brown9-2
Yes and there are a number of libraries (commons-lang, Spring, etc.) which
include Assert classes for things like Assert.notNull(),
Assert.notEmpty(Collection<T>), etc.

This seems like recognition that such commonly used library functionality
might also be useful to be in the base API.

Though I would think it would make more sense for Objects.nonNull() to throw
IllegalArgumentException, not a NPE.

~~~
ShabbyDoo
One could make the "Aren't these just libraries?" argument for the collections
stuff introduced in 1.2, but this standardization served a legitimate purpose
by facilitating rich inter-component/framework interoperability. While I don't
dispute the benefits of using this new Objects class, provides methods used in
implementations, not common API representations. So, I'd argue that the Java
ecosystem isn't much better off for it. This isn't to say that I'm not happy
that it's there, but I don't think it's nearly as noteworthy as new language
features, underlying JVM performance improvements, etc.

As an aside, I was surprised that the article did not take advantage of static
imports to rid the code of the "Objects" references. One could just say:

if (notNull(foo).equals("bar")){...}

~~~
jimbokun
"As an aside, I was surprised that the article did not take advantage of
static imports..."

I also much prefer the readability of static imports, but it won't work for
the "equals," "toString" and "hashCode" methods, obviously.

------
WilliamLP
What are the odds again that we'll _ever_ see widespread adoption of Java 7?

~~~
zmmmmm
The JVM is going to spread quickly as it will (or at least, should) offer
performance advantages for the many various dynamic languages that run on it.
As for Java7 - it will be slower to spread but I think the addition of
closures will be decisive in garnering developer support for it as a wealth of
new APIs (or reworking of old ones) will quickly appear that will have
everyone wanting to upgrade. So it will happen for most server side code
within a couple of years I would expect.

~~~
seunosewa
Java 7 doesn't have closures. Personally, I just want a better syntax for
instantiating anonymous classes. I find that ful closures aren't really
necessary.

~~~
brazzy
Actually, the current status is that Java 7 _will_ have closures.

------
JulianMorrison
Why not fix Java to have compile-time checked not-null types? Given that not-
null is a strict subset of nullable, it wouldn't break code to annotate the
standard library with not-nulls. Then we can avoid these run-time checks
entirely.

Oh and while you're about it, please re-parent InterruptedException onto
RuntimeException, and make Object's default toString method use reflection to
print the contents of all fields in a readable format with recursive toString
calls.

------
jrockway
April fools?

Oh no... it's Java.

~~~
m0th87
I don't see how it could be interpreted as a joke. I've given up Java because
of its verbosity, but anything that reduces it is a win.

~~~
jrockway
I chuckled at the function that takes an object as an argument and returns the
same object as the result.

Yes, I know it throws an exception if it's null... but when your id function
has side effects, it's a sign that your language is Just "not that great".

~~~
jganetsk
The id function in Java has no side effects...

    
    
      public <T> T id(T t) {
        return t;
      } 
    

That's an id function. It works fine with nulls.

Where did anyone say that java.util.Objects was providing an id function
anyway?

------
bensummers
The date on the article is April 2nd. I did check.

Is the inclusion of this monstrosity in a standard library more evidence that
null references are a misfeature? A explicit construction like Maybe<T> seems
so much of a better idea.

~~~
brown9-2
why is this a monstrosity?

~~~
bensummers
It's a monstrosity because the underlying language design makes it necessary.
A whole class of bugs could be eliminated if the language didn't allow you to
have null references, and instead, made you explicitly state your function
might not return an object, for example, the Maybe datatype in Haskell.

~~~
samdk
You can argue that null references are problematic and I'll agree with you.
But they're a part of Java (and a whole host of other languages, too) and
that's not going to change anytime soon.

Saying that this is "a monstrosity" because nulls shouldn't exist in the first
place is completely unhelpful. Whether we like them or not, we're going to be
stuck with them for a long while, and attempts to make them less painful to
deal with aren't a bad thing.

~~~
bensummers
Examining existing languages is useful to advance the art in computer language
design. Being "stuck with them" just means we have the experience of writing
software with these features.

In addition, there's no reason we can't write a language without nulls which
works on the JVM.

~~~
samdk
But we're not talking about advancing language design--we're talking about a
small modification to an existing, widely used language whose basics are not
going to change. There are a lot of problems with Java I'd like to see fixed
before _null_ , and the Java community has dismissed most of those as too
radical (like closures).

There _are_ languages which work (mostly) without nulls on the JVM though.
Scala does something very similar to Haskell's _Maybe_. (Although for
interoperability with Java it can deal with nulls if you insist.)

------
heresy
Over in C#, the implementers decided to give us extension methods so we could
inflict this terror on ourselves in a relatively nice way, and left it out of
the standard library.

------
GrandMasterBirt
12 years in the making.

In Java 8:

java.util.Strings.isBlank(string) -- returns true if the string is null or "",
else returns false.

Its wishful thinking hoping for this in Java 7... So I'll just lower some
standards.

~~~
jcromartie
These days I just treat Java like C. It has a relatively small syntax and
small feature set, but it has a relatively large set of libraries available
(built in and otherwise). The language itself just isn't that interesting.
It's what people are building with it (like Clojure, or Scala, or Hadoop, or
Processing) that are interesting.

~~~
mahmud
These days? Steele's "The Java Programming Language" is where I learned Java
first, and I don't think I have read another book, spec, or library
documentation for java after that. Java as "C with OOP, Unicode, Exception
handling and Threads" is really an excellent language.

I write one small java app every 4 years and that subset of it served me well.

