JDK7 java.util.Objects Utility Methods

In recent weeks, there has been news of various features once proposed for JDK 7 that no longer are slated for this release. Although it is not unusual to reduce the scope of a major software project (including a new version of the Java programming language) as its formal release nears, it can still be somewhat disappointing as the current poll results in Java.net's poll emphasizes.

Fortunately, it is not all bad news in terms of features being dropped from JDK 7. Joe Darcy's recent post What methods should go into a java.util.Objects class in JDK 7? could be the beginning of bringing back some enthusiasm regarding JDK 7. Although the addition of these methods may seem like a minor addition, I have found great benefit in using similar utility-heavy classes such as Collections, Arrays, and even the ubiquitous java.lang.System class.

Darcy's post begins with the sentence:

For JDK 7, I think it is high-time the platform included a class like
java.util.Objects to hold commonly-written utility methods.

I couldn't agree more! I have used several other languages that have similar utility methods collected in a class like this one and I miss these when using Java. It would be a welcome addition.

After listing three ideas (two-argument static equals method, static hash code method that handles null, and compareTo for primitives), Darcy concludes the post with this sentence:

What other utility methods would have broad enough use and applicability to go into a common java.util class?

The last quote implies that we could see some handy utility methods added to a java.util.Objects class that would be generally beneficial to a wide number of Java developers.

It is not difficult to come up with useful methods for a class like this. In fact, the difficulty will be constraining what is added and avoiding abuse of utility classes. We have all probably found ourselves writing certain functions routinely or adding projects such as Apache Commons to our system to provide extremely common functionality not provided by the SDK itself. Adding these most-used methods to a central class within the JDK would be beneficial because we could have standardly available well-tested methods for these most common of functions.

Besides our own experience developing homegrown methods, the most obvious sources of ideas for good candidates for a java.util.Objects class can be gleaned from third-party Java libraries fulfilling the same need (such as Apache Commons and OstermillerUtils). For example, I have blogged previously on some common methods provided by Apache Commons that I really like such as ToStringBuilder and EqualsBuilder and HashBuilder. The Apache Commons class ObjectUtils seems to be particularly useful in providing ideas for a java.util.Objects class.

Another obvious source of ideas includes experience with other languages that support similar functionality in a common object. For example, I have regularly appreciated ActionScript's ObjectUtil class that provides methods such as the toString(Object) method (pretty prints an object's representation even when the provided class does not have its own toString implementation).

Stephen Colebourne has provided a lengthy list of Apache Commons Lang-inspired utility methods in his blog post JDK 7 - Method suggestions. Some other responses to Darcy's original request for ideas include toString, a lessons learned response from developing Google Collections's Objects class, a debug utility class, and another version of Colebourne's post.

Not everyone wants to see this java.util.Objects class added as demonstrated by this post. If you would like to see this utility class added and have some ideas for it, now is your opportunity to recommend generic utility classes that you would like to see in a standard central location.