Skip to main content

Read My Mind

Posted by editor on September 11, 2008 at 4:25 AM PDT

New annotations to make your code more toolable

One funny thing about annotations is that after they were added to Java SE 5, they were just sort of left there to be used as third parties saw fit, without a lot of significant use within Java itself. You could mark that a method was an @Override, to get the compiler to check that your class hierarchy was really set up like you thought, and @Deprecated, to move responsibility for marking deprecation out of realm of Javadoc. But that was about it.

Other tools adopted annotations quickly, notably Hibernate and JUnit, but Java itself continued to not really do much with them, even in Java 6.

However, in Java 7, things are gonna change. This is the topic of today's Feature Article, The Open Road: javax.annotation. This latest installment of Elliotte Rusty Harold's ongoing column about upcoming Java 7 features, takes a comprehensive look at all the standard annotations that may be coming in Java 7, and how they'll help your development process:

The JSR 305 effort being led by Bill Pugh of the University of Maryland plans to change this in Java 7, and dramatically increase the number of annotations used in standard Java code. By adding annotations to classes, methods, fields, and variables, you'll be able to tell static and dynamic analysis tools how you think the code is supposed to behave. Then the tools can warn you when they suspect the code will behave in some other fashion. This improves on the current situation, where static analysis tools need to guess not only what the code does, but what it's supposed to do. Such tools will still generate many false positives; but they'll find many more true positives -- that is, genuine errors -- in annotated code than in non-annotated code.

In Java Today, the Education Community has re-launched at The site is aimed at "students, educators, developers, parents, and anyone else interested in tools or curriculum for teaching Information and Communication Technology," with separate starting points for students, educators, and developers.

The latest edition, issue 180, of the JavaTools Community Newsletter is out, with tool-related news from around the web, including new releases from JT Harness and AppTale, new tool projects in the community, and a Tool Tip on using JavaNCSS to measure code complexity.

Robert J. Miller compares Java to Ruby on Rails from the point of view of technology entrepreneurs and, tallying up their respective features, declares it a dead heat. "In a nutshell, Java is not good for entrepreneurs because it is too complex and too slow to develop, configure, and deploy your web application. Ruby on Rails will get you off to fast start because it excels at time to market and low costs but leaves you hanging when it comes to scalability. Here is my entrepreneurial web technologies report card." By coincidence, Java and RoR get the exact same score, 3.07, when Robert tallies up the grades.

Terrence Barr passes along evidence that phoneME performance rocks! in today's Weblogs. "The folks over at BugLabs have been one of the earliest and most serious adopters of phoneME - they are using phoneME as the basis for their core product. Lately, they have done a series of performance tests to compare phoneME with other open source VMs such as Cacao and jamVM. They just published their second round of results after some tuning and turning on the phoneME JIT compiler."

In GlassFish V3 Prelude Update Tool, Ludovic Champenois notes a nice surprise when he rebooted his computer. "Yesterday, I was happily surprised by the ease of use of the GlassFish Update Center... For some reasons (installing iTunes 8.0 and QuickTime), I had to reboot my MacBookPro, and on reboot, I noticed a nice "Update Tool Notifier" on my desktop."

Fabrizio Giudici is disappointed that one of the best Java conferences has been forced to change its name again, as he explains in JavaPolis -> Javoxx -> Devoxx. "This morning I've been really surprised when I read the newsletter from Javoxx (former JavaPolis) and learnt that the belgian guys had to change again their name, because even Javoxx was a trademark problem for Sun lawyers. Boys, this is unbelievable."

Come to think of it, Fabrizio, isn't that the same reason that Slashdot rips on Java so much?

In today's Forums, whartung considers the strange status of Timers in EJB, in Re: How to stop EJB timers being deleted upon app undeployment. "Yea, the timers do kind of exist in a "no mans" land. On the one hand being applications state (and not just application state, but persistent applications state), but on the other being a container artifact that the container is somewhat responsible for (thus dumping them on undeploy). I think it would be a fair RFE to make Timers persistent across redeploys as a deployment (or, perhaps, undeployment) option."

hansr complains about
Losing hardware accelleration depending on configuration. "I'm currently writing a little test application using swing + scenegraph effects. I'm using the Decora-D3D.jar and Decora-HW.jars from the JFX preview release, and get HW accellerated effects when Decora-D3D.dll is also present. However, when I make the app's JFrame transparent using AWTUtilities.setWindowOpacity(), the HW accelleration no longer works. Is that intended behaviour, a bug or do I need to set something else too?"

Continuing a discussion we featured yesterday, jwenting bemoans bloat in
Re: Has Java lost its way? "Java has in part lost its way. That's however not because of all the frameworks (it's after all not Sun putting out a new web framework every day for example...) but because Sun's become convinced that the "Me2!!!!!" approach to platform design is the best one. By which I mean that they're trying to make Java do everything any other language or platform does, and have every language construct ever imagined for any other language. Function pointers are just the latest, 1.6 saw a full http server and web service stack as part of the core language."

Current and upcoming Java

Registered users can submit event listings for the href=""> Events Page using our href="">events submission form.
All submissions go through an editorial review before being posted to the

Archives and Subscriptions: This blog is delivered weekdays as
the Java
Today RSS feed
. Also, once this page is no longer featured as the
front page of it will be
archived along with other past issues in the href=""> Archive.

New annotations to make your code more toolable


Annotation can be inherited. They need to be marked with the @Inherited meta-annotation.

"Come to think of it, Fabrizio, isn't that the same reason that Slashdot rips on Java so much? " Well, not really. :-) A reasonable reaction is to complain, and then keep using the Java technology if you used to think it is great. Or stop using it if you change your mind, but for some other good reason. Slashdot's just acted as a histeric "prima donna". For what concerns annotations, I think they are great. You're not serving the code analyser, you're just better documenting your code (in a formal way), and as a consequence the tool analyser works better. Of course you can misuse them, as for any other software tool. I don't think there will be ever the Automatic Perfect Code Generator, being the man with the keyboard the ultimate responsible or quality, but now he can work better.

Annotations for the sake of making the job of a code analyser easier are bad. Tooling should serve the programmer, not the other way around.

SuppressWarnings can have a place, specifically to make it known to a compiler (or other tool) that you are aware of a potentially risky construct and don't want to be reminded of that, but that's about as far as should go (and it does also make your job easier by acting as a filter for compiler output).

Of course annotations in general often make code look bad and hard to read. The mechanism is also extremely limited as it doesn't support OO principles like inheritance. An annotation to one class isn't inherited by its children, making for a lot of extra typing to have those children have the same annotations as their parent.

Some would say annotations makes your code more terrible, not toolable. You left out SuppressWarnings which very well demonstrates the problem with annotations, how they can never replace proper language constructs like marker interfaces and modifiers to name a few.