eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
With 67 Java specification requests at the stage of final release and 31 more in earlier stages of review, the Java platform is still very much a work in progress—mostly in a positive sense. The JavaOne conference in June showed encouraging signs, moreover, that the vigor of continued Java platform evolution is being tempered by a welcome maturity—in particular, with growing attention to predictability and clarity of process for current and would-be Java adopters and greater productivity for Java software developers.
At the same time, however, the strengths that used to distinguish the Java platform from other choices have not gone unnoticed: Providers such as Microsoft Corp. have responded in ways that enrich developers options.
|
The designers of the Java language reacted, initially, to the complexity of established programming languages (especially C++) by deliberately excluding language features—such as the use of unrestricted pointers to arbitrary memory locations—that opened at least as many doors to programmer error as they did to software efficiency.
In eWEEK Labs experience, these decisions paid off: Like others whove measured developer performance, weve found it typical for a simple development task to take one-half or even one-fourth the time to complete in Java than it does in C++, even when its done right the first time in both languages.
The likelihood of requiring additional debugging time for a C++ effort (with measurements suggesting two to three times as many bugs per line of code and more lines of code per task) tilts the productivity balance even more in Javas favor for development tasks involving the writing of code rather than the exploitation of highly leveraged APIs such as those of Windows—an important qualification.
The flip side of that caveat is that developers also saw the rapid growth of a component marketplace for Microsofts Visual Basic and for other tools using Microsofts Component Object Model. The most productive coding is not needed to write code at all because a high-function component is already at hand and well-supported by high-level tools.
The productivity pendulum swung even farther in the direction of Windows technologies with Microsofts introduction of the Common Language model and supporting run-time environment for .Net Framework. In many ways, Microsofts C# language is Java with an “off” switch for the air bags, allowing programmers to take a deep breath and write intentionally unsafe code where they believe that the benefits are worth the extra scrutiny required.
The security features and other support provided by the .Net environment have addressed many of the arguments that Java developers had previously offered for the superiority of their choice.
Now, Javas designers restate their argument with developer productivity aids such as JavaServer Faces, JSR 127. Developers can anticipate that this technology will greatly ease the connection of server-side state and function to the appearance and behavior of client-side user interface components.
Fewer lines of Java code will also yield more results with the advent of a metadata facility for the Java language, as contemplated by JSR 175. Rather than different Java tools devising unique notations for common Java idioms, a standard mechanism for associating attributes with application elements will encourage judicious mix-and-match choices by developers who prefer to assemble their own portfolios of tools.
JSR 223 aspires to bring Java up to par with .Net in making software objects accessible from scripting languages, emphasizing the Webs popular PHP but also supporting such enterprise mainstays as REXX.
In the rapidly expanding realm of Web services, JSR 224 proposes a Java API for XML-based remote procedure calls, responding (if none too quickly) to .Nets ease of exposing Web services with minimal added code.
In 1997, among the most innovative of the early Java tools were two products from Sun Microsystems Inc., the elegant browser-based Java WorkShop and the innovatively component-oriented Java Studio. What put them ahead of their time, unfortunately, was their early and aggressive commitment to being “Java in Java”—that is, the tools themselves were implemented as Java applications at a time when the Java platform wasnt quite up to the task of competing with native tools with smooth and immediate response to developers commands.
Today, solving Java developers problems with Java technologies is a far more plausible goal, and its a heartening emphasis among the current crop of Java improvements in progress.
Technology Editor Peter Coffee can be reached at peter_coffee@ziffdavis.com.