Saturday, July 7, 2007

Inconvenient Truth of Java Annotation

The Inconvenient Truth of Java annotation is that it promotes bad programming practices and create unmanageable Java programs.

The first problem of Java annotation is that it must be embedded into the Java source codes. Mixing source code and meta information is not a good programming practice.

The second problem is that it indirectly forces programmer to put totally unrelated Java annotations into the same Java source file. The programmer may need to put the JPA annotation, Validation annotation , GUI annotation, etc into a Java POJO class. It is a really messy bad practice.

The third problem is that Java annotations are unmanageable and untraceable if there are large number of annotations being embedded into many different source files. It is a really difficult task to find where an annotation is placed or trace how the annotations work together.

The fourth problem is that other scripting languages that are implemented in Java, like JRuby, Jhython, etc,,, cannot leverage the benefits of Java annotation feature.

I think the best solution to the above problems is to put the annotations into a separate annotation file. What do you think?

4 comments:

Unknown said...

Actually I agree that mixing source code and meta information is not a good programming practice in some situations.

IMHO, annoations as @Override and @SuppressWarnings well placed well as these deal directly with their target - and more important only with them.

However, I agree when it is referring to different entities. Although it is more convenient to link properties to database columns via annotations, it has a huge disadvantage: The code has to be altered and recompiled if the database tables layout changes. Of course, with the linkage defined separated, one has to edit it too, however one can reuse existing compiled beans.

Notice that with separated I don't say the linkage must be defined outside (e.g. xml). It can be in a java source file, but one should be able to maintain it apart (e.g. class/.jar files).

In principle, that is why I almost never implement the Comparable interface, but have plenty of Comparators :-)

Anonymous said...

Wow - I couldn't agree less. Putting metadata in the code came about because it turned out separate external configuration files is a big headache. For very large, complex systems the cost of it is justified, but for more typical systems, annotations is a lighter, more flexible way to go.

Putting "unrelated annotations" together is not necessarily a bad thing. In fact, it is usually very beneficial to do so to get a better picture of what your code is doing. In fact, it is so helpful, that your third point doesn't even make sense. Having the annotations right there in the code makes it really easy to understand what is going on and how the pieces of your system work together.

As to the final point, I don't see why the limitations and shortcomings of other languages make any difference in determining what is right for Java. Should we say that the features of those languages are bad because we cannot "leverage the benefits" of them in Java? If the annotations capabilities of the language you are using are insufficient for your needs, perhaps you should consider something like Groovy, which has great annotation support now.

I'll make one last point. If you look at successful technologies that are using annotations now, you will find that most of them provide both inline and external metadata support. Why? For most uses, code-level annotations are best. It's the simplest, most straight-forward way to go most of the time. When you do need external metadata, either to override the class annotations or provide metadata for un-annotated classes, then you have that option. In practice, this dual-approach works very, very well.

cltam96 said...
This comment has been removed by the author.
cltam96 said...

I agree that the dual approach works best but the current Java annotation does not support the dual approach. I want to show the pitfalls of current Java annotation. I can't see the benefit of mixing Java annotation in general cases unless these Java annotations are related. If mixing is good, we should mix all the code in one program file and modularization is bad and OO is bad and etc...