Skip to main content

JavaOne report: Java futures

Posted by emcmanus on May 23, 2008 at 10:03 AM PDT

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.


href="http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-5581&yr=2008&track=javase">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 href="http://java.sun.com/javase/6/docs/api/javax/management/MBeanServerConnection.html#createMBean(java.lang.String,%20javax.management.ObjectName,%20javax.management.ObjectName)">overboard
with checked exceptions. I think it might be a bit redundant to
have both, though.

After discussing module-related changes (about which more href="#6185">later), they discussed the extensions planned to
annotation syntax via href="http://jcp.org/en/jsr/detail?id=308">JSR 308. Many
examples of what these extensions will allow were presented. (JSR
308 itself does not define these annotations but href="http://jcp.org/en/jsr/detail?id=305">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.

href="http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-5579&yr=2008&track=javase">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 href="http://www.javac.info/bloch-closures-controversy.ppt">JavaPolis
talk. Plus, I don't think the Closurists are doing
themselves any favours with the href="http://www.javac.info/closures-v05.html">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 href="http://jcp.org/en/jsr/detail?id=277">277 (for the
runtime module system) and href="http://jcp.org/en/jsr/detail?id=294">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 href="http://www.linkedin.com/pub/2/109/383">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: rel="tag">javaone rel="tag">javaone2008 rel="tag">closures rel="tag">java rel="tag">jsr277 rel="tag">effective+java.]

Related Topics >>

Comments

Fabrizio, I made a similar remark during the technical review of this presentation. As elias says, it is not really a magic meaning of "final". The compiler can deduce the actual set of exception types that the variable in the catch clause can be, but this deduction would be invalid if you then assigned another value to the variable.

I'm not sure I completely buy this argument, though. If as you suggest an annotation were used instead, and the variable did not have to be final, then the compiler could check that the compile-time type of any assigned value was compatible with the set of types it had deduced. And the "final" keyword already has two completely different meanings (for methods and fields) as well as special treatment in local classes, so perhaps we don't want to add yet further connotations to it.

'final' will not change its meaning, it's the compiler that will get smarter. When an exception variable, e, is declared final in the catch clause, the compiler can assume that a 'throw e' can only throw exceptions of the same type as the code contained in the try { } block.

While the exception-related changes are fine for me, I'm a bit disappointed with certain forced use of the existing language keywords, such as 'final'. I understand that this has been done to avoid breaking the compatibility by introducing a new specific keyword, but this doesn't contribute to the readability of the source (I mean, in english language the "final" word has nothing to do with the enhancement). In this case, for instance, I don't understand why didn't they choose to use an annotations? Since we have annotations, they appear to be the most elegant and readable way to enhance the language.

PS I don't know whether the current compiler accepts an annotation in the catch clause, but since we're talking of Java 7, the compiler could be extended to allow that.