LOGIN | REGISTER NOW | SUBSCRIBE
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 7/1/2009 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
Is the mystery Borland suitor Serena?
Borland software is considering an offer from another company after a preliminary deal with MicroFocus. Is Serena the new company?
06/30/2009 01:55 PM EST

Windows 7 - An eBayer's dream product?
Windows 7 pre-orders can make people money on eBay.
06/29/2009 03:48 PM EST

Know thine cloud provider
Cloud computing require companies to understand compliance and regulation. Third parties will play a big role in regulated industries.
06/29/2009 02:58 PM EST

 

Microsoft Worldwide Partner Conf.
7/13/2009 to 7/16/2009
New Orleans
Microsoft

OSCON (Open Source Convention)
7/20/2009 to 7/24/2009
San Jose
O'Reilly Media

XBRL Technology Workshop & Summit
7/28/2009 to 7/30/2009
Santa Clara
XBRL US

ACM SIGGRAPH
8/3/2009 to 8/7/2009
New Orleans
ACM SIGGRAPH

OpenSource World (formerly LinuxWorld)
8/12/2009 to 8/13/2009
San Francisco
IDG World Expo


 
print Printable version 
Most Read Latest News Blog Resources
Kapow automates website data retrieval
Kapow Technology's Web Data Server 7.0 can be used to create modules that navigate through...

Oracle's Fusion 11g lays groundwork for ERP platform
Fusion's components are standards-based and integrated, but some abilities are lost if non...

COBOL’s future lies in the clouds
After 50 years of use in businesses, COBOL is still lingering around mainframes. But the s...

Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter

Coordinating the Evolution of Java


Java Watch

By Allen Holub
November 15, 2005 — 
It’s interesting that the release of Java 5, with all of its new language extensions and library updates, seems to have had little or no impact on the Java world. Though I’m sure that some shops have embraced the new version of the language wholeheartedly, most programmers are simply ignoring the new language. Just look through any of the Java magazines, and you’ll be hard-pressed to find a generic class or an example of the new loop syntax outside of an article that’s describing how that feature works.

Part of the problem is the huge teetering edifice of open source. One side effect of 100 programmers working on the same project with little or no real coordination is that none of the contributors knows how the whole program works. Consequently, when it comes to something as significant as a major rewrite to bring a project in line with the current language spec, nobody has either the will or the knowledge to do it. The result is stasis. (Truth to tell, some of the open-source code is so bad that it would have to be discarded completely and rewritten from scratch.)

The nobody-understands-the-code problem isn’t limited to open-source projects, of course, but when our own code is based on one or more open-source frameworks that aren’t Java 5-compatible, the impetus to moving our own code to Java 5 is not exactly overwhelming.

Meanwhile, however, Sun has been diligently moving forward to a new Java release scheduled for early next year, and many of the new standards that will be incorporated into the language leverage these new features. Eventually, it will simply be impossible to ignore the new language, if for no other reason than the new versions of libraries that many of us use on a regular basis, such as EJB and JDBC, not only leverage new language features—primarily annotations and generics—but are also much easier to use as a consequence. That is, there will be a compelling argument—easier construction and maintenance—for making the move.

There’s a new version of Java (called Mustang) due out in a few months, and it can’t hurt to get prepared for what it will offer. The best way to track these changes is to monitor the various Java Community Process initiatives that will be part of the new release. The Umbrella Java Specification Request is JSR 270 (jcp.org/en/jsr/detail?id=270), which has pointers to the other JSRs that constitute the new-version specification. You’ll also want to monitor the “communities” on java.net (community.java.net), particularly The Java Specification Requests Community (community.java.net/jsr).

Unfortunately, some of the JSRs that have the most impact on our actual work are not part of the Mustang JSR.

Consider annotations. Though the word from Sun is that there will be new language changes in Mustang, that’s true only in the sense that there will be no syntax changes that affect the compiler. Annotations—introduced in Java 5—effectively provide a way of adding keywords to the language without impacting Java’s syntax. For the most part, annotations improve your code. It’s vastly simpler to declare a method as @remote than it is to manually supply all the infrastructure needed to support RMI. However, @remote is now effectively a keyword in the language—a new sort of access privilege, and we need to know about it to write effective Java.

Though almost every new JSR introduces some sort of annotation, there is no one place where all of the new annotations are gathered; rather, they’re defined in the individual JSRs that introduce them. The one glimmer of sanity is JSR 250 (Common Annotation for the Java Platform), which defines “a small set of common annotations that will be available for use within other specifications. It is hoped that this will help to avoid unnecessary redundancy or duplication between annotations defined in different Java Specification Requests.”

The problem with this approach is that JSR 250 is far from a complete compendium of the annotations scattered through the other JSRs. More to the point, cataloging and coordinating annotations is a process, not a specification. The Java Community Process is not set up for this sort of thing. We don’t need an initial-draft, final-draft, released-standard process; we need a perpetual committee to which annotations are submitted, which must approve those annotations before they can be incorporated into the language. We need a clearinghouse, not a standard. We also need a catalog that collects all the annotations, but a catalog is not a specification—it’s a living thing that constantly evolves.

Let’s hope, then, that an annotation-management process is set up within the JCP before Java annotations descend into the same chaos as business-related XML. This early we have a chance, but if we wait too long, that chance will slip away.

Allen Holub is an architect, consultant and instructor in C/C++, Java and OO Design. Reach him at www.holub.com.


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

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading