I was at JavaOne again this year, and this time I found time to go to a surprising number of talks. I started writing a summary of them but it grew to about six screenfuls, so I decided to post it in installments. Here's the first installment, covering the talks about Java futures.

The titles here are not always the ones that appear in the conference programme. I tried to undo the mangling that the Trademark Police typically impose on talk titles, so let me just state up front that Java, JMX, and JVM are trademarks of Sun Microsystems, Inc., and any other abbreviation beginning with J has a sporting chance of being one too.

Here are the talks summarized here:

Upcoming Java Programming-Language Changes
Closures Cookbook
Modularity in the Java Platform

In the later installments, I'll cover Java programming practice, Concurrency, JMX, and Miscellaneous others.

TS-5581, Upcoming Java Programming-Language Changes, Alex Buckley, Michael Ernst, Neal Gafter. I was one of the reviewers of this talk so I already knew what would be in it, but I went anyway and was not disappointed. The presenters started with an excellent presentation of principles to apply to language evolution. These argue for a conservative approach to new language features; since I'm a Language Reactionary I was happy about that.

They followed with two proposals for exception handling. With multi-catch, you could write...

try {
    ...
} catch (IOException, IllegalAccessException e) {
    handle(e);
}

...instead of having to duplicate the handle(e) logic in two different catch clauses. (The syntax with a comma mirrors the throws clause but a syntax with a | is also a possibility.)

With rethrow the compiler's logic for determining the type of the variable in a catch clause is refined when that variable is final, so you can write...

void m() throws IOException, IllegalAccessException {
    try {
	// code that can throw IOException or IllegalAccessException
    } catch (final Throwable e) {
	handle(e);
	throw e;
    }
}

...and the compiler is smart enough to know that throw e can throw an unchecked exception or IOException or IllegalAccessException, but not any other Throwable, so you don't need to declare m() throws Throwable.

Either of these changes would be great for code that has to work with APIs (like the JMX API) that go a bit overboard with checked exceptions. I think it might be a bit redundant to have both, though.

After discussing module-related changes (about which more later), they discussed the extensions planned to annotation syntax via JSR 308. Many examples of what these extensions will allow were presented. (JSR 308 itself does not define these annotations but JSR 305 will, or others like them.)...

List<@NonNull String> strings;

class UnmodifiableList<T>
    implements @Readonly List<@Readonly T> {

These annotations can be processed by compiler plugins ("annotation procesors"), which can implement complex analysis of program logic to check, at compile time, that the assertions implied by the annotations must be true. So for example...

Graph g = new Graph();
// ...add nodes and edges...
// now g will no longer change:
g = (@Immutable Graph) g;

If the compiler (with its plugins) cannot prove that g will indeed no longer change at the point of the cast, no matter what happens afterwards, then it will produce an error.

Finally, the presenters listed some other areas where the language might evolve in the longer term, such as better support for delegation (forwarding) and for parallel algorithms; and some areas where it probably won't, such as operator overloading and dynamic types. Here as in many other places it was emphasised that the Java language is just one way of using the JVM and of course other languages can target the JVM with their own feature sets.

TS-5579, Closures Cookbook, Neal Gafter. Neal gave a very good exposition of what closures are about before narrowing down on one particular application in a great deal of detail. From that example you could certainly see why closures might be useful. But as I mentioned, I'm a Language Reactionary, and I felt that Josh Bloch captured the issues admirably in his JavaPolis talk. Plus, I don't think the Closurists are doing themselves any favours with the Syntax From Mars.

TS-6185, Modularity in the Java Platform, Alex Buckley, Stanley Ho. Probably every Java programmer who's worked on non-trivial projects has encountered the problems mentioned here. First, if a module contains more than one package then there's no way for those packages to share classes and methods without making them visible to everybody else as well. Second, if your application needs two different versions of the same module because of dependencies from other modules, you are in trouble.

These problems are being addressed by JSRs 277 (for the runtime module system) and 294 (for the Java language changes), though as I understand it the two Expert Groups have merged so there's really only one JSR.

The language will acquire a new module keyword, although through cleverness it is not a reserved word and existing programs that use module as an identifier will continue to compile. The module keyword has two purposes: first, you can put a module declaration before the package declaration in a source file, to say what module the package is in; and second, you can declare the access of a class, module, or field to be module, which means it is accessible from any package in the module but not from outside the module. public continues to mean accessible from anywhere. An example from the talk illustrates this...

module  org.netbeans.core;
package org.netbeans.core.utils;
module class ErrorTracker {
    module int getErrorLine() {...}
}
  

Information about modules can be expressed using annotations like @Version and @ImportModule in a new module-info.java file.

The runtime module system will include a module file format (JAM), that captures this information; a new ClassLoader model that knows about modules (and is not fazed by the same classname appearing in different module versions); and a framework for module repositories, where there can be different implementations of repositories, such as a directory containing JAM files or an OSGi container.

My perception of JSR 277 was fairly confused until recently, and I think that might have been because the JSR itself was confused; but the JSR and I now feel much better, thank you.

I also went to the associated BOF, where among other things we got to see a demo that used the new JMX model for modules, designed by my JMX team-mate Shanliang Jiang.

In the next installment I'll cover the talks on Java programming practice.

Update: the PDF slides for the various sessions have begun to appear on developers.sun.com so I've updated the links here to point to that site.

[Tags: javaone javaone2008 closures java jsr277 effective+java.]