CHANNELS
 
 
 
 
 
 
 
 
ON THE WEB
 
 
 
 
PRINT EDITION
 
 
 
 
BZ MEDIA
 
 
 
 
ADVERTISER LINKS
 
 
 
 
 
 
 
AS OF 11/19/2008 6:39AM EST
Java 7: Sun's good grooming
Stories Columns Opinions Resources

By Andrew Binstock

September 1, 2008 — 

The other day, I heard a technologist exclaim in frustration, “Why have people not yet migrated to Java 5?” I certainly sympathize.

Released in late 2004, Java 5 contains numerous valuable additions that make programming easier and better, especially for the SE and EE editions. The improvements include annotations, generics, enums, autoboxing, variable number of arguments and static imports. I can honestly say that I have used all of these features for years, and they now are an integral part of how I think of Java. And when I look at legacy Java code, I can generally tell that it predates Java 5 because I can see the struggles that went into it to provide the capabilities that shipped in version 5. Java 5 has proven itself; sites should adopt it. Skipping Java 6, however—that I do understand. Its changes were incremental.

The upcoming Java 7 shows all the signs of being a major release, on the order of Java 5. It has numerous features that will make Java easier to develop with, and that will lead to cleaner, better code. Let’s look at some of them.

Better modularity. Java’s package system, while workable, is hardly ideal. For example, despite having hierarchical names, packages are not hierarchical (that is, package a.b.c is not part of package a.b). In addition, there is no way to qualify packages as public or private, or to obtain visibility somewhere between the two. New features called superpackages (JSR 294) and Java modules (JSR 277) provide greater control over how packages are integrated, how modules are versioned, and what access other classes and modules can have. These changes are implemented at the language level.

A higher-level module standard—JSR 291, which is not part of Java 7 but which is gaining wide acceptance—is OSGi. Developed for embedded applications, it has emerged in the past few years as an application framework and is currently the framework for Eclipse. It provides a smooth way of loading and managing plug-ins (“bundles” in OSGi parlance) into a backplane. Interbundle dependencies, hot loading and unloading are all supported. As reported in an earlier issue (“Storm brews over proposed Java spec”), there are still collisions between the OSGi folks and JSR 277 designs. But most parties expect that the two teams will eventually find a solution that gives Java better packaging plus a standardized plug-in framework.

Enhanced parallelism. JSR 166y lets developers spread parallelizable work over multiple threads with ease. Its ForkJoinExecutor will recursively break down the task into parallelizable subtasks and then execute those in parallel. The task must know how to break itself into smaller tasks—generally a straightforward affair if the work has been designed for parallel processing. The proposed fork/join feature uses threads with private queues of work. When they complete their work, they inspect other threads’ queues; if some work remains to be done, the threads steal it from the back of the queues. Nifty, huh?

Improved bug detection via annotations. Developers who do not share the sentiment that Java is too verbose will appreciate that new annotations can be inserted into declarations to tell the compiler and static code analyzers intended constraints, such as @NonNull, @NonEmpty (for a collection), @ReadOnly and so forth.

Better libraries. New I/O will add methods to manipulate file attributes and perform file system-specific operations, and to perform asynchronous I/O operations on files and sockets. Date and Calendar classes will see new methods for handling date without time and vice versa, plus computation of durations and intervals. A new Measure class will let you use standard weights and measures and convert between them as appropriate.

Miscellaneous. Finally, there should be small, handy things added, such as a switch statement that can take strings as parameters, comparisons of enums, and the obscure invokedynamic bytecode that enables dynamic languages to run better.

The one really handy feature we will not get in Java 7 is closures. Because of their great utility, closures would have been an important addition. And they would have addressed one of the key objections to Java, namely its verbosity. But they will have to await a future release. (If you need closures in the meantime, consider another JVM language, such as Groovy.)

The arrival of releases Java 5, 6 and 7 in a span of five years demonstrates an important aspect of the language: It is rapidly revved by Sun. Consider the lags between major releases of other languages are (C, C++ and Python, to name a few), and you’ll see how aggressive—and welcome—Sun’s constant grooming is. Now to get sites to adopt the releases quicker….

Andrew Binstock is the principal analyst at Pacific Data Works. Read his blog at binstock.blogspot.com.



Related Search Term(s): JavaSun


Share this link: http://www.sdtimes.com/link/32737
 


 
 
 
 
 
 
 
 
 
 
SUBSCRIBE TODAY!
 E-Newsletters:
  News on Mon/Thurs.  More info
  Test & QA Report  More info
  EclipseNews  
  SPTech Report  More info
 
 
 
PDF & PRINT EDITION
* Requires Resource Account!  LOGIN or SIGN UP

Download Current Issue!
ISSUE 11/15/2008 PDF

Need Back Issues?
DOWNLOAD HERE

Receive The Print Edition?
SUBSCRIBE HERE
 
REGISTER
 
GET NOTIFIED!
About all of the latest Resources
 
 
SD TIMES 100
It's time once again to
recognize the organizations
or individuals that have
demonstrated leadership in
their markets.