Java 7.0 (Dolphin): Evolving in the Ecosystem

Sun developer Danny Coward says "Compatibility is king", but Sun is not standing still in the Java space. At last week's JavaOne conference he unveiled some projects that R&D is working on for the upcoming "Dolphin" release of Java, due out in 2008. The proposed changes are in three areas: languages, packaging, and ease of development.
Languages
Dolphin developers are working on changes to the Java language but have to be careful. "Language changes can have benefits like productivity and maintainability," says Danny, "but they affect everybody". He mentioned Annotations as a good example of a language change (in Tiger) that other products layered on top of.
Some possible language changes being considered for Dolphin include:

• property support (for getFoo()/setFoo() pattern)
• method references (a quick way to write an event notification pattern)
• block closures (collection of statements within a statement)
• native XML support

According to Danny, "Java developers like to experiment with other languages, especially dynamic languages," for prototyping, or in spaces that require frequent changing such as user interfaces and tests. New languages can sometimes let you be more innovative without having to worry about backwards compatiibility with an old languege.
Dolphin is expected to contain some changes in the JVM that organize the way dynamic interpreters can be plugged into the platform, to help them be written more efficiently. Currently, Java byte code requires type codes, so today dynamic languages have to concoct a large number of fake types just to get the code to compile. Danny says "The number of interfaces grows exponentially with the size of the application." JSR 292 describes a new bytecode for dynamic method dispatch that would help aleviate that. "Also we'd like to bundle more scripting engines, like BeanShell."
Packaging
Two expert groups in the JCP are currently working on packaging related projects:

• Super-jars (modules): Jar files, originally created to bundle up class files used by applets, are slated to be replaced with "modules" in Dolphin. This is to address some problems in larger applications, such as versioning. Old jar files will continue to be supported. The expert group has been working for about a year, mostly in secret, and should have something to share with the community before too long.
• Super-packages: If two different packages need to access implementation classes in a third package, currently there's no way to hide that third package from consumers. By declaring all three to be part of a larger super-package, the developer will have finer control over what is visible.

There is some overlap here with the OSGi project, which now has its own JSR. Some of the same people are involved both with OSGi and with super-jars/packages so hopefully they can work out a common solution despite the political bickering that plagues many JCP proposals.
Ease of Development
Swing is a very powerful toolkit for desktop application development, says Danny, but many developers are put off by the framework. It's not just a tools issue. "EE5 has given us all a lesson here," according to Danny, and Sun would like to apply this kind of transformation to the Swing development model. So they looked at what goes into a typical desktop application. A lot of Swing application code does basic tasks like "maintaining the integrity of the view vs. the model, synchronizing the data, translating the types, doing validation," and so forth. There is much code that has to be written over and over again for each application, like preferences and resource handling. Some new work has just started to simplify both of these: Beans binding (JSR295), and Swing Application Framework (JSR296).
For more information on Dolphin progress you can read Danny's blog. The slides from the talk are also available.