Atom Feed SITE FEED   ADD TO GOOGLE READER

Coding in the small with Google Collections: Objects.nonNull

Part 6 in a Series by Robert Konigsberg, Guest blogger...

In the first episode, Jesse talked about the Preconditions class. That's not the only mechanism supplied by the Google Collections library for data validation. We're going to look at Objects.nonNull(T) and, by association, Objects.nonNull(T, String).

Objects.nonNull accepts an object, and throws a NullPointerException if it is null. Otherwise it returns the value passed into the method.

Objects.nonNull is wonderfully useful in constructors. Since any use of super in a constructor must be the first statement in the method body, Preconditions can't be used. before the superclass initialization. The Precondition can be used after the superclass initialization, but that doesn't work very well; it forces initialization prior to validation, and besides, Preconditions have a semantic inference; they're meant to be used as pre-conditions, not post-conditions.

Before:

public ConnectAction extends Action {
private final Connector connector;
public ConnectAction(ContextManager mgr, Connector connector) {
super(mgr);
Preconditions.checkNotNull(mgr);
this.connector = connector;
}
public void run(ActionArguments args) { ... }
}

After:

public ConnectAction extends Action {
private final Connector connector;
public ConnectAction(ContextManager mgr, Connector connector) {
super(Objects.nonNull(mgr));
this.connector = connector;
}
public void run(ActionArguments args) { ... }
}
See? Objects.nonNull operate like a filter within an expression, whereas Preconditions do not.

Objects.nonNull also works well when supplying a large number of arguments:

Before:

public Person(String givenName, String familyName, Address address, Phone phone, String email) {
Preconditions.checkNotNull(givenName);
Preconditions.checkNotNull(familyName);
Preconditions.checkNotNull(address);
Preconditions.checkNotNull(phone);
Preconditions.checkNotNull(email);

this.givenName = givenName;
this.familyName = familyName;
this.address = address;
this.phone = phone;
this.email = email;
}

After:

public Person(String givenName, String familyName, Address address, Phone phone, String email) {
this.givenName = Objects.nonNull(givenName);
this.familyName = Objects.nonNull(familyName);
this.address = Objects.nonNull(address);
this.phone = Objects.nonNull(phone);
this.email = Objects.nonNull(email);
}

Another interesting use of Objects.nonNull is as a post-condition operator:

Before:

public V get(K key) {
V value = map.get(key);
if (value == null) {
throw new NullPointerException();
} else {
return value;
}
}

After:

public V get(K key) {
return Objects.nonNull(map.get(key));
}

So, when should you use Preconditions.checkNotNull and Objects.nonNull? There's a soft answer: see what feels right. You're a smart programmer, I'm sure.

Part 7
erm.... actually.... we're probably going to change Preconditions.checkNotNull() so that it returns its argument like Objects.nonNull() does, and then I don't know whether Objects.nonNull() will survive after that.

The split would probably never have happened in the first place, except that I was out on leave when it did (I think).
Quite funny - finally now I'm reading this. I've been coding this for my 50 developers company a year ago as well.
It is named ConstraintUtils, performs null, range and Collection checks, creates readable IllegalArgumentException messages for easier debugging and returns the checked argument on success (for initialization and super-construction).

For a previous company I coded utils implementing your Objects.equals methods.

I cannot believe such company toolkits still need to be coded in Java. ^^ I'm only at page 7 as of now and I'm really curious what useful things you guys are producing on the other pages that some others seem to have coded as well because these things are actually missing in Java.
Kevin's post seems to have come to pass. Objects.nonNull has been removed from Google collections. At least as of RC1.