The Evil of "Evil Annotations"

This blog is a comment to https://dzone.com/articles/evil-annotations

This is an evil article (Sorry I use the word "evil" which is copied from the article). And below is why

1) Annotation, like Java source code, is a way to express developer's intention to runtime environment. And it is a very expressive way of doing that. The author's point of "reducing the reusability of class" makes non-sense because:

• the code with JEE annotation or other annotation is designed to run into a certain container/application server that follow the standard and understand the semantic of the anntoation as per designed
• you can't blame Java source code reduce the reusabilty because it cannot run by a ruby interpreter, right?

2) In the "Evil Annotations Are Sometimes in the Wrong Place" section, the author point out that@ApplicationScoped does not belong to the class "DocumentFormatter" as shown below:

@ApplicationScoped  
public class DocumentFormatter {   
  ...  
}

And my view is: the annotation clearly expressed one important factor of the class: it is an application level singleton object, and container/application does not need to instantiate the instance of that class multiple times. Without using that annotation, you probably will go back to the Singleton pattern, which adds couple lines of code without any additional benefit.

The other example about JPA class is also funny, the point of "which couples the persistence directly to domain objects", should be rephrased into "which reduce the couples between persistence layer and domain object", because any persistence layer that implement the JPA requirement can handle your domain object. I wonder if the author is still thinking of writing his own JDBC code to handle persistence of the domain object. Here I want to mention that "persistence" IS one attribute of a domain object, and it is the system specification of your application, it is unfair to split it out from the domain object just because it doesn't represent the functional specification. If you are doing that, it's kind of like to say a programmer shall not eat because eating is not the domain feature of a programmer, which is just programming.

3) The author gives out the alternative to annotation: "of course good old Java Code", but I couldn't see any real world project/framework/application support that conclusion. And I want to point out the author's affinity to "the Java Language and its Compiler" is not generic in any way. The reason people relies on Java language and it's compiler is because it ONE of the standard of transfer developer's intention (in Java source code) into instructions to be run in a reliable standard environment (JVM). And there are many other "languages and compilers" could be used to do the same thing. On the flip side of the concern, the author looks like ignored the runtime environment which is also a standard part of the system, JVM is no doubt one of them, and JVM itself is not the only example of it. JEE containers and many other stacks are also good example of standard runtime environment, and they do recognized annotations (standard or even non-standard).

In conclusion, the problems of the article are:

1. The author's overlook of system specification while highlighting functional specification. (Found in the JPA and @ApplicationScoped example)
2. The author's overlook of Runtime environment while highlighting the language/compiler. (Found in across the whole article)