Java Performance Services
Training, Seminars, Benchmarking, Tuning

Course Schedule


Java Performance Tuning
Chania Crete, May 18-21

Speaking @

ØREDEV, November 19-21

Devoxx, December 8-12.

JFokus, January 27-28.

Calendar

««Nov 2008»»
SMTWTFS
       1
2345678
9101112131415
16171819202122
23242526272829
30

Performance Anti-Patterns

My Top Tags

                                       

Mailing List

My RSS Feeds








Language Annotations

posted Saturday, 9 September 2006
Last Wednesday I had the pleasure of listening to Mike Aizatsky, product manager for JetBrains, at the Cologne JUG. Mike presented on two topics. The topic of the later talk was JEE features in IDEA 6.0. The first talk featured several annotations in IDEA primarily in support of detecting null pointer exceptions.

Though the discussion surrounding the difficulties determining if code could throw a null pointer exception was interesting, the most interesting aspect of the talk was in regards to language specific annotations.

A language specific annotation is one that would allow IDEA to perform all kinds of tasks similar to those that it performs for Java code. These tasks include syntax high lighting, syntax error checking, code completion and so on. What makes this particular annotation most interesting is in its ability to handle XML, JavaScript, and just about anything else you throw at it. It also implies that we don't need to mix XML literals into Java, the language. Mike's position on XML literals was pretty clear. He didn't see that XML was any more special than SQL or a host of other languages that we may choose to embed into the Java runtime. With annotations we now have the capability to enable the IDE to deal with different langauges. This keeps the various languages decoupled, as it should be.

In this instance I don't really know what would be best, using annotations to allow better support for XML or to use XML literals. What I can say is that it seems that the annotation route is less problematic. The first order that comes up when coupling XML into Java is just that, you are coupling XML and Java. Should XML change then what of Java? Is there a possibility that a change in XML could break backwards compatibility in future versions of Java. Can't say that I know however it would seem that by using annotation we can avoid the question all together! One of my measures of how good any particular solution is, is on it's ability to create opportunities for reductions or to help me avoid ugly situations altogether. Using this measure annotations look like a better option.

Ideally our tools should be supporting our development efforts. Using meta data in the code to help our tools figure out things what would otherwise be almost impossible or messy to achieve seems like a win. In the case of XML enabling the IDE with an annotation seems less messy. Plus it will be easy to switch to XML literals should annotations prove to be ineffective. However it will be impossible to remove XML literals no matter what uglyness may come. Since Java is a production ready language it seems prudent to opt for changes in our tools before we opt for changes in the language.

tags: