Newsletter sign-up

View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Year in Review: What to expect in Java SE 7

An overview of features in and out of the next Java specification

By Alex Miller, JavaWorld.com, 12/16/08

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.

 

XpoLog Center Correlate application logs with server metrics - XpoLog

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.