Java 7: Sun's good grooming
Stories Columns Opinions Resources
Sun extends Groovy, PHP support to NetBeans
Version 6.5 of the IDE will see complete support for those two languages along with comple...
|
Sun reorganizes its software production infrastructure
Facing economic hardships, lost revenue and loss of employees, Sun has split its software ...
|
Adobe steers Flash toward RIA implementation
At this year's Adobe MAX Conference, the focus was on Flash, this time making Flash more o...
|
BigLever builds a bridge to SCM with Gears
The Gears Universal Configuration Management Bridge allows CM systems to integrate with Ge...
|
SOA Watch: New economic realities
In the current economic downturn, agile programming and SOA are attractive options that bu...
|
Integration Watch: A new twist on threads
The key to raising the efficiency of multiprocessors is to shrink the overall workload by ...
|
Integration Watch: The Return of NetRexx?
Java scripting languages are seeing a surge in popularity, with NetRexx looking particular...
|
Windows & .NET Watch: Transaction crowd gets a boost
With multicore chips becoming the standard for processors, the need for a flexible, usable...
|
From the Editors: Election should shake up JCP
Rod Johnson has the right ideas for opening up the Java Community Process, and he may be a...
|
Letters to the Editor: Sun gives REST, SOAP choice
A reader takes issue with a headline on our story about Sun working with REST along with S...
|
Guest View: Be smart and lazy
The optimal solution for problems is the simplest one, so always aim to streamline your ap...
|
Zeichick's Take: From EXEC to EXEC 2 to REXX to NetRexx
Andrew Binstock's column last week, "The Return of NetRexx," brought back some fond memori...
|
Practical tips for saving money on code maintenance
If software design is expensive, well, code maintenance is even more so. When you look...
|
Transform your app-dev quality by involving the whole community in testing
As the saying goes, the more eyes you have on software, the shallower the bugs. That’...
|
Build your dev and test labs for less – a lot less – with virtualization
You don’t have the budget to equip developers and software test teams with all the har...
|
Software Common Hacks and Counterattacks: A Guide to Protecting Software Products against the Top 7 Piracy Threats
Software piracy continues to be a growing epidemic. This white paper examines prevalen...
|
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): Java, Sun
Share this link: http://www.sdtimes.com/link/32737