Annotations are a major kludge on the landscape. They don't fit and we don't need them; but you just know that they'll be picked up by framework junkies and abused horribly.
Every so often Sun appears to let out a really big howler. Take EJB 1 and 2. The justification for distributed object transactions was an aberration brought about by the influence of the CORBA object framework-geeks. It’s taken them years to even start to recover from that mistake. The success of Hibernate was needed to show that the folks at Sun got it wrong. EJB cost the industry many billions of pounds in lost development time. However, like Dorothy’s Ruby slippers, the solution was right under their nose all along, in the form of JavaBeans, local O-R mapping, remote sessions and XA transactions.
They now appear to have made another really big howler in the form of annotations. Given the strong dependency EJB 3 has on annotations, I guess the EJB design mentality has been allowed to pollute the core Java language. Am I the only one to notice? It’s so obvious. In fact it’s so obvious that you may have some time adjusting to the idea.
Sun talks of annotations as being an extension to the existing metadata in Java. I disagree. Let’s define metadata. Metadata is data about data. I consider the reflection API as something that expresses metadata. It tells you about classes and their methods. It tells you about the types of arguments in your methods. It tells you about the structure of your pre-existing Java code.
Annotations tell you nothing about your Java code, they tell you nothing about the instances of your Java classes, methods or fields. However they supply additional properties about your Java classes, methods or fields. They're meant to supply additional data about how the software is to be compiled, deployed or executed. This is not metadata, it’s decorative data.
It’s so pervasive that I hardly need repeat it. How many times have you had to make that extra push to ensure that a parameter is not hard coded? It’s such an important principle that we sometimes overdo it.
However, when I look at an annotation like this it makes me shake my head: -
@Resource(name="myDB", type="javax.sql.DataSource.class") @Table(name="CUST", schema="RECORDS")We have all had to live with the problem in the previous versions of EJB of having to rebuild and re-deploy an application just to change the JDBC configuration. In the large corporate projects I work on, there are multiple database vendors and multiple schemas being used. It’s a long, slow painful process having to edit the XML and re-deploy. The annotation solution appears to have worsened these problems because the JDBC configuration is now embedded in the Java code itself. Ask yourself this simple question: I have two stubborn clients with different table names for the same beans... is the deployment solution elegant?
Annotations were supposed to be a replacement to XML. The reason was that XML re-introduced all those knives and daggers, that Gosling rightly disliked about C++. But the XML in Enterprise Beans has not gone away. Now we’ve got configuration in the Java code as well.
This is a weaker point but it allows me to introduce an analogy. Annotations are litter and will eventually litter our code. I can see some kind of annotation folding being introduced into the Java development environments in double quick time.
Even in the most favourable light you have to admit that the implementation of annotations is a kludge. I don’t blame the people that designed the implementation, because annotations are not a natural fit into the Java architecture. As hard as Sun's engineers tried, you can’t call the @interface code elegant. Kludges in code are like kludges in theories: they reveal an underlying mismatch between human artefacts and the nature of things.
Annotations are primarily a response to .NET annotations. They are a solution looking for an problem. I think the folks at Sun meant Java 5 to be a response to .NET, along with the introduction of generics, the enumeration type and boxed types. I’m not knocking the other new language constructs; I think they are a great addition and well implemented.
In the book The Design and Evolution of C++, it's clear that Stroustrup was careful not to introduce features into C++ that could be open to abuse. Stroustrup was over cautious, not introducing metadata because he thought it would be abused. I think he’s been proved wrong about that. Annotations are, however, a different case because they are so open in scope. I don’t think I’ll be proved wrong about annotations. Their one saving grace is that they are a kludge, difficult to implement, and hopefully won’t become ubiquitous in application code. But I expect the same framework-geeks that drove to be thoughtlessly expecting application developers to pick their litter up.
Lets suppose that annotations do become abused, as I expect. How are we going to control them? As annotations evolve and best practices appear, I expect somebody will come up with a more formal enforcement.
I’d see a case for replacing XML, and annotations. Annotations will be seen as litter on the Java landscape. One thing that strikes me about the move from XML to annotations is the shift from having a many-one relationship between code and XML to a one-one relationship between code and annotations, as well as the move from weakly-typed to more strongly-typed enforced configuration. I believe that there is a better intermediate solution that keeps a many-one relationship between code and XML as well as strongly typed configuration.
A better solution for Sun would have been to come up with an XML-like structure that could be coded into Java. This would give all the benefits of rigorous type enforcement, and the benefits of a many-one relationship between code and configuration, and the benefits of separating the configuration data out of business objects.
I would see these XML structures as being defined by something with similar semantics to XML schemas, but they would be implemented something like nested static classes containing defaults. When I look at the XML schema semantics and extended Java nested static classes, they do seem like they have similar semantics.
Extended nested static classes would provide type safety. They could be overridden by specific implementations. They could be available to introspection. Configuration would be kept in Java. I believe it would be worth exploring extending the semantics of Java nested static classes to do the job of XML configurations in a more rigorous manner than annotations provide.
When the folks at Sun start looking over the garden fence at their rivals, they get sucked into playing them at their game, and not their own. It happened with EJB and it’s happened with annotations. This is not leadership and it is not innovation. It’s not what Java developers need.
http://www.softwarereality.com/programming/annotations.jsp