Adam Messinger Talks to InfoQ About Java 7 and 8
Following on from last week's release of Java 7, InfoQ spoke to Adam Messinger, Vice President of Development in the Fusion Middleware group at Oracle, to get more information about the release and Oracle's plan for Java 8.
InfoQ: Can you give us a sense of the overall "big picture" plans that Oracle has for Java?
Oracle continues to develop Java with the participation of other groups - from large companies like IBM to individuals, through venues like the JCP where the APIs and specs get developed, to the various open source groups that Oracle sponsors, like GlassFish or OpenJDK, or participates in, like Eclipse. And the overall priority: that the Java platform continues to evolve with the times as a productive, reliable, and performant technology for developers of all different kinds.
You only have to look at the breadth of development in products written in Java that Oracle produces to see the level of commitment. Just the fact that Java SE 7 is shipping and plans for Java SE 8 are underway, GlassFish already had a release (3.1) and is planning for another later this year, JavaFX 2.0 is almost done, Java EE 7 is ramping up, and NetBeans 7 also recently shipped, shows you the progress we've been making. And then of course, you have Oracle Fusion Middleware and products like Oracle Exalogic Elastic Cloud that are all based on Java.
InfoQ: What do you think are the most interesting or important features in Java 7?
I think most developers will find the language changes in Project Coin the most immediately useful. These changes, like strings in switch statements, the diamond operator, multi-catch exceptions and the try-with-resources syntax, will be useful to all developers because one of the basic things all the features have in common is that they increase the readability of existing source code. Joe Darcy, the project lead for these changes, has also produced an annotation processor so that developers can scan their existing code for potential candidates to replace older, sometimes error-prone code, with the new try-with-resources, which are much more compact.
I'd also highlight the new Filesystem API, which exposes key features of modern file systems such as file-change notifications and symbolic links and also supports much faster bulk operations like searching a directory tree. Those I'd say are the most important.
But the most interesting feature of all I think is the new Fork/Join API, which helps developers make their applications run concurrently. It used to be the case that only developers who were writing data- or algorithmically-intense applications destined for high end servers would care about whether their application was running concurrently and hence more fully utilizing all the capabilities of a multi-core/processor architecture. But we're now seeing quad core chips becoming commonplace on the desktop and dual-cores in notepads and smartphones. Pretty soon many more developers will need to care about concurrent programming.
InfoQ: NIO 2 introduces a true asynchronous I/O API for Java. Why is this important? What are some of the use cases for it?
Asynchronous I/O is a key tool for writing highly-scalable I/O-intensive applications. It's sort of the dual of non-blocking I/O, which was introduced as part of the original NIO effort in Java SE 1.4. Non-blocking I/O is great for handling large numbers of open network connections but it's not a good match for I/O devices that are accessed randomly, such as disk drives. Asynchronous I/O works well for both sequential and random-access devices, and it fits better into some kinds of application architectures. Like non-blocking I/O, I expect that many developers will never use the asynchronous I/O API directly, but those who do will find it invaluable.
InfoQ: The new filesystem API in NIO 2 looks like it is in violation of the write once-run anywhere principle of Java since it allows Java programs to access file features to a single file system. Is this really a good idea? If so, why not extend it to other areas such as enabling generic system calls from Java?
I'm not sure I agree that this is a violation of the WORA principle, and if so it's hardly the first. Java does a really great job of isolating the developer from most of the details of the underlying architecture and platform, but it cannot hide the fact that some platforms have different capabilities than others. One obvious example is that not all computers have a display, so they wouldn't be able to run Swing code in any meaningful way. Yes, the filesystem API allows access to features like symbolic links, which may not work on all platforms but if you want to be a purist you could argue that not all platforms where Java is run even have a file system!
We believe that the WORA principle is solid, that it is a major reason to why Java has become so successful and we intend to continue to follow it. However, we also believe that Java must allow integration with platform-, device-, and implementation-specific features in order to continue to be useful and successful. There are proven ways to achieve the combination of these requirements, such as with a more or less abstract API in combination with providers that define implementation-specific extensions. This is the architecture used by the Filesystem API as well as many other Java APIs, whether they are part of the standard or found elsewhere.
To answer the specific question, yes I believe it does make sense to make some system calls more easily available for Java. This is a discussion that I expect will happen within the Java community – OpenJDK, JCP and elsewhere.
InfoQ: One of the main arguments for adding lambdas to Java was that they were needed for Fork/Join. Given that why are you shipping Fork/Join first? Doesn't that mean that you'll end up with a broken API when lambdas are done?
Not at all! We're really on a multi-release pathway to help developers write concurrent applications. It started way back in JDK 1.5 when Doug Lea and his JSR 166 expert group added their API level support for breaking up an application into tasks that could be executed in parallel. The Fork/Join framework in JDK 7 is another step towards that goal, but is still in the vein of a manual set of tools that developers can pick up and use when they have some knowledge about how to break up their programming task.
Where we're headed is towards automating more and more of that design and implementation work to make an application concurrent. Project Lambda includes lambda expressions for more concisely encapsulating functional behavior together with platform implementations of concurrent algorithms like filtering or mapping. They might be implemented under the covers with existing concurrency APIs such as Fork/Join, but that’s really just an implementation detail. Lambda will take us another step towards bringing concurrent programming to the masses, though I'm sure there will always be 'power' developers who will use the more manual techniques of Fork/Join.
InfoQ: It has been suggested that Java 8 might define automatically parallelizable bulk-data operations such as filter, map, and reduce. Could you expand a little on these ideas?
These bulk-data operations are important because they enable automatic parallelization via internal iteration. What this means is that rather than write a traditional for loop to filter a collection, which is external iteration, you instead define the filter in a lambda expression and pass that to the collection's filter method, which then does the iteration internally. Since the filter method has control over how the iteration is implemented, it can choose to fork the work out to multiple processor cores if appropriate, but that's completely transparent to the developer.
InfoQ: Java 7 introduces the first new bytecode instruction to the JVM with invokeDynamic. There was a fairly advanced proposal in Project Coin for a Java syntax for invokeDynamic, but it was dropped. Can you give us some background on why it was dropped? Can we expect to see it re-instated in Java 8?
After a pretty thorough analysis we concluded that it doesn't make much sense to extend the Java programming language with a feature that's of use only to the very few people who implement other languages. I doubt this will be reconsidered in Java 8.
InfoQ: In terms of support for other languages on the JVM are there particular languages you think would benefit from further VM-level changes?
InfoQ: What do you see as the next priorities for alternative language support - continuations? tail-calls? interface injection? Can we expect to see any of these in Java 8?
It’s a bit early to say really. How this has tended to work is that John Rose works in close collaboration with many of the language designers and implementers, and they take a pragmatic approach of prototyping some of these features, and seeing which feature will give the biggest bang for the buck. In fact there were many interesting discussions last week at the JVM Language Summit. You can see some of the results here.