Responding to Recent Java 7 Blog Post Comments

There have been several interesting comments posted on my blog in response to recent blog postings on Java 7 that I more fully want to address in this post. I tried to quickly respond to the comments close to the time they were made, but want to use this post to more fully elaborate on some of those responses in this post. The advantage of this is that I can provide more detail and include images. One overarching theme of each of these responses is the value of community and the responses to my previous posts are further evidence that the Java and JVM communities are large and helpful.

Comparing Two Comparable Objects for Minimum

In response to JDK 7: The New Objects Class, Eric Jablow pointed out that it'd be nice if the Objects class or some other general Java class supported a method for comparing two Comparable objects to determine which was the minimum of the two. I responded that I was not aware of such a utilitarian method. It seems to me that it'd be nice to have and could be implemented something like shown in the following Groovy code listing.

/**
 * Determine the minimum value of the two provided Comparable parameters.
 *
 * @param a First Comparable parameter to be compared for minimum; should be
 *    non-null and of same type as other ('b') parameter.
 * @param b Second Comparable parameter to be compared for minimum; should be
 *    non-null and of same type as other ('a') parameter.
 * @return Minimum of two provided parameters.
 * @throws ClassCastException Exception thrown in the two provided parameters
 *   are not of the same types (or at least cannot be cast to same type).
 * @throws NullPointerException Exception thrown if either provided parameter
 *   is null.
 */
public static <T extends Comparable<? super T>> T min(T a, T b)
{
   return a.compareTo(b) < 0 ? a : b;
}

I included the above code in my response, but it has a nicer appearance here in a full blog post with color syntax, better formatting of white space, and more "screen real estate" for presentation.

Adam Rabung wrote a response in which he recommended use of Google Guava's Ordering.min(E,E). Although this recommended class and method are not part of the standard development kit, it still is often preferable to use "more common" code such as that provided by Apache Commons and Google Guava (superset of deprecated Google Collections).

I used "T" for "Type" in my example and Guava uses "E" for "Element" in their API. These and other "commonly used type parameters names" are documented in the "Type Parameter Naming Conventions" section of Generic Types.


Enhanced Groovy Script for Determining JDK 1.7 Updates in Javadoc

kellyrob responded to my post JDK 7: New Interfaces, Classes, Enums, and Methods with a reference to an improved version of the script that kellyrob99 made available at https://gist.github.com/899826. There are several improvements that were made to make this script more efficient and more self-contained.

I think the most important improvement the enhanced script provides is significantly improved performance via use of GPars (Groovy Parallel Systems). The enhanced script specifically demonstrates use of groovyx.gpars.GParsPool's withPool method. Because concurrency was in play, it was important that the script was changed from using Groovy's default (implicitly typed) BigInteger to explicitly typed AtomicInteger counters. This is an excellent real-life example of using gpars to parallelize a Groovy script for dramatically improved performance.

There are other nice improvements. The enhanced script uses TagSoup in conjunction with Groovy's handy XmlParser to parse the source file listing the various Javadoc pages for classes, enums, and interfaces. I took advantage of the fact that the tags were really all the same in that page, but this approach is a little more flexible for potential future changes.

Another nice feature of this enhanced script is the use of Grape-provided @Grab to nicely package dependencies on added dependencies (TagSoup and Gpars).

Finally, this is a fine example of how a community can build better tools and learn together. Although I've been aware of Gpars for some time, I still don't think to use it by default because I have not used it in the past. This example should help remind me to consider it in other appropriate situations in the future. It is also nice to have a more performant script available for mining new 1.7 features from the JDK 7 Javadoc.


Synergistic Seven: NetBeans 7.0 and Java 7

Martijn Verburg stated in his response to my blog post JDK 7: The New Objects Class:

You'll probably get more joy out of using Netbeans 7.0 Beta 2 with the JDK 7 preview build or later (builds). We've been running our experiments on there successfully, it seems quite stable etc.

I had been thinking about upgrading to NetBeans 7.0 and hearing that it's fairly stable was encouraging. When I worked on the code examples for the blog post JDK 7: Reflection Exception Handling with ReflectiveOperationException and Multi-Catch, I noted that NetBeans 6.9 did not handle the multi-catch exception clauses well. Although the code compiled correctly when its project properties were configured to have Source/Binary Format set to JDK 7 and Java Platform set to JDK 1.7 in Libaries, NetBeans 6.9 code editor was unable to correctly process the multi-exception catch clauses. The next three screen snapshots demonstrate this with the first two images indicating the NetBeans 6.9 settings for Java 7 and the third image demonstrating the misleading code editor view.

I downloaded and installed the "All" (244 MB of Java SE, Java EE, Java ME, C/C++, Groovy, PHP, GlassFish Open Source Edition 3.1, Tomcat 7.0.11, but no Ruby) NetBeans IDE 7.0 Release Candidate 1 Release. I was pleased to see that JUnit was included (it had its own License Agreement to accept) given that it once looked like it might not be.

I was pleased to see none of the same orneriness in NetBeans 7.0 RC1's treatment of the multi-exception catch code that I saw demonstrated by NetBeans 6.9. The next screen snapshot shows how much happier NetBeans 7.0 RC1 is with this new JDK 7 feature.

That's nicer!

Martijn also presented an "exercise for the reader": "What will an IDE present when you are looking for all of the methods on e in a multi-catch catch block?" When I tried this in NetBeans, the only methods presented by the IDE in a multi-exception catch clause were the method available to Throwable and its parent Object. Because catch blocks can catch both Throwable types [exceptions (common) and errors (not common)], it makes sense that the IDE would only present what all of these have in common (Object and Throwable methods). To call any method specific to one of the exception classes in a catch block, one would need to do an instanceof and cast to the relevant exception. It seems better to simply catch those specific exceptions in their own catch block if functionality specific to a particular exception is desired.


Conclusion

I received some excellent and helpful feedback related to my late-March posts on JDK 7 and highlighted some of those in this post. Not only did I learn some new things, but it was once again demonstrated to me the power and importance of an active and enthusiastic community when using a language, framework, or other tool in software development.