JDK7 Tackles Java Verbosity

Posted in Java by Dan on August 29th, 2009

The Java Language changes accepted for inclusion in JDK7 have been announced by Joseph Darcy. We already knew that closures were off the menu.  So too, unfortunately, is language support for arbitrary-precision arithmetic. The final list is pretty non-controversial and includes a number of changes that will reduce the verbosity of Java programs (one of the main criticisms of Java from proponents of other languages). Java will never be as terse as Perl or Haskell, but that’s no bad thing. One of the strengths of Java is its readability. There are however some areas where the language is needlessly verbose and that’s what these changes are addressing.

Simplified Generics

The last major revision of the Java language was Java 5.0, which introduced generics, auto-boxing, enums, varargs and annotations. Despite the compromises of type erasure, generics have been a major improvement to the language. They have also contributed to the verbosity of Java code. The necessity to specify, in full, both the reference type and value type of a field or variable has led to some very long declarations:

Map<String, List<BigDecimal>> numberMap = new TreeMap<String, List<BigDecimal>>();

JDK7’s proposed diamond notation allows the programmer to omit the generic parameters on the righthand side if they are the same as the left:

Map<String, List<BigDecimal>> numberMap = new TreeMap<>();

Collection Literals

The long overdue addition of collection literals will help to reduce the size of Java code and make it more readable. Lists, sets and maps can be created and populated without the need for cumbersome instance initialisers:

List<Integer> powersOf2 = {1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024};
Map<String, Integer> ages = {"John" : 35, "Mary" : 28, "Steve" : 42};

Automatic Resource Management

Josh Bloch’s proposal for automatic resource management gives Java an alternative to C++’s RAII and C#’s using. It eliminates much of the boiler-plate exception handling that surrounds the proper creation and disposal of resources, such as IO streams, in Java code. The proposal introduces a new interface, Disposable, that resources will implement. The syntax of try/catch/finally is extended to allow resources to be specified at the start. These resources are then automatically disposed upon completion. Here’s an example of the new syntax in action (taken from the proposal):

static String readFirstLineFromFile2(String path) throws IOException
{
    try (BufferedReader reader = new BufferedReader(new FileReader(path))
    {
        return reader.readLine();
    }
}

Other Changes

As well as the above changes to tackle verbosity, JDK7 adds binary integer literals and the ability use String literals in switch statements.  JDK7 will also fix the problem of mixing varargs parameters with generic types.

Java 6 for 32-bit Macs…finally?

Posted in Java, Mac by Dan on August 25th, 2009

Apple’s OS X 10.6, code-named Snow Leopard, is released on Friday.  There is some suggestion that this will finally deliver Java 6 for 32-bit Intel Macs (more than two-and-a-half years after it debuted on other platforms). The news reaches me via James at DZone, who cites Axel’s blog, which in turn links to this 2-month-old post as evidence. There’s no primary source identified and, given Apple’s legendary pre-release silence, this is unlikely to be confirmed until some Java developer with a 32-bit Mac actually tries the Snow Leopard upgrade.

At present there are two not-entirely-satisfactory options for Java 6 development on 32-bit Mac hardware. The first is to use SoyLatte, which is fine for non-GUI work but only supports Swing under X11. The other option is to run the JVM under another OS via the magic of Parallels or VirtualBox.

Assuming that this rumour is true (and I remain sceptical), the key question is will this update be made available to Tiger and Leopard users via Software Update, or is an OS upgrade necessary? The Leopard-to-Snow-Leopard upgrade is reasonably priced but Apple’s site implies that if you are upgrading from an earlier version your only option is the more expensive Mac Box Set (which also includes the latest versions of iLife and iWork).

UPDATE (28th August): It seems that the Snow Leopard “upgrade” is actually a full version of the Operating System and can be used to upgrade machines running Tiger. However, to do so might be a breach of the End User Licence Agreement.

UPDATE (29th August): I asked on Stack Overflow whether anybody could confirm the presence of Java 6 on 32-bit Macs.  The question got bounced to the new Super User site, but I did get a couple of positive responses.  So it seems that yes, Java 6 is finally available to owners of 32-bit Macs, but only if you upgrade to Snow Leopard.

Watchmaker Framework for Evolutionary Computation – Version 0.6.1: Terracotta Clustering and more…

Posted in Evolutionary Computation, Java by Dan on August 3rd, 2009

I’ve just uploaded version 0.6.1 of the Watchmaker Framework for Evolutionary Computation.  If you’re not already familiar with the project, it is a library for implementing evolutionary/genetic algorithms in Java.  It’s multi-threaded, cross-platform, fast and has a modern, unobtrusive and flexible API.

API Improvements

One user-requested addition to the API in this release is the getSatisfiedTerminationCondtions method.  This makes it easy to determine which termination condition (elapsed time, generation count, stagnation, etc.) caused the evolution to terminate when you are using multiple termination conditions.

The API documentation has also been improved in a few places to make things clearer. Firstly, the framework does not support negative fitness scores.  In previous releases it may have worked under some circumstances, but it was undefined behaviour.  In this release you will get an IllegalArgumentException if you try it.

Secondly, if you are using an EvolutionObserver to update a Swing GUI, be careful not to overwhelm the AWT thread with updates (this can happen if you are processing dozens or hundreds of generations per second). It appears that the framework is so fast that AWT can’t keep up.  If this happens (it’s more likely with small population sizes), the GUI will become sluggish and unresponsive.  This problem is mitigated by minimising the work that your EvolutionObserver does on the AWT thread or by only updating the GUI every nth generation.

Distributed Fitness Evaluations with Terracotta

There have also been some internal modifications to make the framework more amenable to clustering with Terracotta.  Terracotta can now be used to distribute the workload across multiple machines.  It’s only at the proof-of-concept stage at the moment – there is no support for handling node failures.  It’s also only really worthwhile for evolutionary programs that have expensive fitness functions.  The fitness function has to be expensive enough to justify the cost of transferring the candidate across the network for evaluation on another machine, otherwise clustering just makes things slower.

I will likely provide more detail on how to use Watchmaker with Terracotta in a future article, but for now here’s what to do if you want to try it out.  The field that you need to configure Terracotta to share is the  private workQueue field in the org.uncommons.watchmaker.framework.FitnessEvaluationWorker class. Run your unmodified program using Terracotta then run extra instances of the FitnessEvaluationWorker on other nodes.

Remember, you also have the option of using Hadoop with Watchmaker (via the Apache Mahout project).

See the changelog for full details of changes in this release.