Since early 2007, Alex Miller has been diligently tracking and sharing information about the JSRs proposed for inclusion in Java SE 7. In this Year in Review feature, he shares the fruits of his labor: a plausible picture of the forthcoming platform specification, including some of the most recent announcements from Sun Microsystems. Get an overview of the key improvements we're likely to see in Java SE 7, and find out which promising JSRs might not make it in after all.

Almost immediately after Java SE 6 was released in December 2006, developers began to cast an eye toward which JSRs might be included in Java SE 7. In January 2007 I started tracking these ideas and cataloging the conversations about them, many of which take place in the blogosphere. As time has passed, some ideas have sprouted JSRs, specifications, and prototypes, while others have withered and dropped out of sight.

A good picture has emerged of which JSRs and language changes are likely to be included because of their maturity, importance, and acceptance by the community. However, the final decision will not be made until Sun's chief architect of Java SE, Danny Coward, submits the Java SE 7 platform JSR and an expert group forms. All Java library and language changes will be approved as part of this platform JSR, which will link together existing JSRs to form the full feature set. The current target for Java SE 7 is early 2010. We can expect a platform JSR to arrive in the first quarter of 2009.

The remainder of this article focuses on the features I believe are most likely to be included in Java SE 7, with code samples to demonstrate related changes to how we code today. All of the JSRs I'll discuss here have specifications and working prototypes and so are reasonably mature.

Better dependency management

For a long time now, Java developers (indeed all developers) have struggled with managing the dependencies within an ever-growing set of open source and commercial libraries. A typical enterprise application today relies on dozens of external JAR files and can itself comprise dozens of smaller internal projects worked on by different teams. We continue to search for better ways to manage this ever-increasing tangle of dependencies to make our builds repeatable and our deployments sane. The rise of dependency-handling build systems such as Maven and runtime deployment systems such as OSGi reflect this trend.

Early in the Java SE 7 cycle, two important JSRs attempting to tackle dependency management progressed: JSR 294: Improved Modularity Support in the Java Programming Language and JSR 277: Java Module System. Both focused on the development and deployment aspects, respectively, of the notion of Java modules. A module is a set of interrelated classes usually serving some common purpose, similar to a JAR that would commonly be produced by an open source project or an internal project managed in an IDE. However, a module's scope could potentially be a portion of a JAR or a set of several JARs, depending on development and deployment needs. In mid-2008, JSR 294 was simplified and merged into JSR 277 so that the same expert group could work on the two aspects in tandem.

In December 2008, Sun overhauled this plan yet again, announcing that Java SE 7 will focus solely on modularizing the JDK as Project Jigsaw in the OpenJDK. JSR 277 and the Java Module System will be put on hold until after Java SE 7. JSR 294 will be resurrected for the purpose of modularizing the JDK. Sun has stated its intention to work closely with the OSGi Alliance so that JSR 294 modules can be used by OSGi.

Information is still emerging about this new day for Java modularity, and it's a little early to parse the current wave of announcements for what they will actually mean to Java SE 7. Sun seems to set the minimum bar as breaking the JDK itself into modules and supporting those modules in the Sun virtual machine directly (but not as part of a new platform standard).