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


   

 
 
Download Current Issue
ISSUE 2/1/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Visual Studio 2010 Release Candidate Available Today
A Visual Studio 2010 release candidate is available on MSDN.
02/09/2010 09:45 AM EST

Is Microsoft eyeing Office subscription pricing?
Microsoft may be preparing to offer a new Office pricing option called "union," which charges the same for cloud as on-premises.
02/01/2010 09:38 AM EST

Facebook rewrites PHP runtime
Facebook is about to open source its own PHP runtime, written from scratch for speed.
01/30/2010 08:53 PM EST

 

Events calendar tab
Macworld 2010
2/9/2010 to 2/13/2010
San Francisco
IDG World Expo

SPTechCon 2010
2/10/2010 to 2/12/2010
San Francisco
BZ Media

PyCon 2010 (Python Conf.)
2/17/2010 to 2/25/2010
Atlanta
Python Software Foundation

Southern Calif. Linux Expo
2/19/2010 to 2/20/2010
Los Angeles
SCALE

IBM Pulse
2/21/2010 to 2/24/2010
Las Vegas
IBM


 
print Printable version 
Most Read Latest News Blog Resources
Facebook brings HipHop to PHP
HipHop compiles PHP to speed up the Web layer at world's most popular social networking si...

Adobe moves LiveCycle application platform to the cloud
Release gives developers just what they need to create targeted business process-oriented ...

Oracle acquires AmberPoint
Today's merger will probably affect most of AmberPoint's existing partnerships with other ...

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

What’s Not Coming in Mustang


By Allen Holub
April 15, 2005 — 
Java’s next “Mustang” (Java 6) release has finally entered the JSR process (JSR 270: www.jcp.org/en/jsr/detail?id=270). This column is the first of several that will look at the proposed changes.

Rather than providing an integrated approach to the new release, Mustang is just a collection of 11 existing JSRs, each with its own expert group. These groups are essentially autonomous. The reality is that there’s no overall architecture, and more to the point, there’s no architect coordinating the Mustang work.

This lack of guidance is a significant problem. Here’s an example.

I talked recently about my concerns with Sun’s documentation for the annotation-processing tool (apt) that ships with Java 5. The apt APIs aren’t even part of Java; they’re in a com.sun package. JSR 269 (part of Mustang) defines a Pluggable Annotation Processing API, and will presumably fix this last problem. JSR 269 will probably break your existing code, though; it “is targeting the same general functionality as the apt tool...[but] it is expected the API included in this JSR will resemble but not necessarily be compatible with the existing apt API.”

It gets worse: “Users of apt have identified several limitations to the API; this feedback should be considered by the expert group.” Note the phrase “should be considered,” not “will be incorporated into the standard.”

Even if JSR 269 miraculously does improve the quality of the API, it doesn’t solve the real problem: apt is a kludge. To effectively perform compile-time annotation-processing, you need hooks into the compiler itself, not a preprocessor that mimics a compiler by giving you partial access to a limited set of syntactic elements. As it stands, apt can’t be used to actually modify the behavior of the compiler.

Consider an @property attribute, used to simplify a class that will be used in a program that requires the existing JavaBeans-style getter/setter idiom. The compiler should automatically generate get/set functions for you when it sees an @property applied to some field. The best you can do with apt, however, is create a brand-new java-source-code file for a class that wraps the one you’re actually processing, and then compile that file externally. The wrapper class must have a different class name than the class you wrote, and it won’t integrate cleanly with your program. As it stands, apt just doesn’t do the job.

To solve this problem, you need hooks into the compiler that let you effectively modify the source code (or the generated bytecode) to reflect the needs of the annotation. To do that, you need access to, and the ability to modify the structure of, the program. Technically, you need access to the abstract syntax tree (AST) that’s used internally by the compiler.

Mustang includes a compiler API, but the JSR 199 and JSR 269 folks are not integrating their efforts. The compiler APIs will do nothing but let you run the compiler from within a Java program. This way a program can extend itself by writing Java source code, which it compiles and executes internally. You can also use the compiler APIs to compile and run customer-supplied “scripts” written in Java, saving you the trouble of inventing and implementing a custom scripting language. This ability is useful but not sufficient.

Coming back to the problems of annotation processing: The apt preprocessor is “based on javac,” which is to say that it’s a hacked-up version of the compiler. JSR 269 and 199 are both working on modifications of the same, javac, source code. Why are they separate JSRs at all?

The ability to modify the AST is essential in an annotation processor, and apt cannot provide this ability unless it replaces the compiler altogether. Moreover, the JSR 199 effort is concerned with exactly what’s needed to solve the annotation problem—exposing APIs that let you access the internal workings of javac. The apt effort should be abandoned entirely, and access to the AST should be provided in the Java 6 version of JSR 199, not in some “future version” (something that the JSR promises).

This wholesale restructuring of the JSR process is unlikely, though. Sun seems unwilling (or unable) to provide the architectural guidance needed to bring the anarchic JSR process under control. Instead of an orderly evolution, we get a bunch of uncoordinated projects tacked onto the language as an afterthought. Java needs an architect (or a committee that serves this purpose) who can direct the various JSR expert groups so that they can work toward a common goal.

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/28542
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading