How about those annotations? Haven’t they made the once simple and elegant Java language into a unintelligible mixed-up mess of code and metadata? These are just two outcries of despair about annotations that I found on the Internet, both written by able and experienced Java developers:
“We have been seeing this for awhile via XDoclet, and the .NET community is definitely seeing it. I dunno, maybe it is just me, but it scares me. We need to get out some practices for what should be in annotations, and really hope specs will not do crazy things which have you nesting them 5 times.”
techno.blog(”Dion”)
“While the advantages of annotating the code (JSR 175 - Metadata Facility for Java) are somewhat clear to me, I have been wondering what the drawbacks could be. I don’t deny that being able to specify auxiliary information for classes, interfaces, fields and methods is a good thing. What I question is the means we will supposedly use to achieve this, namely, we will be putting the whole stuff directly within the code. If not used with care, annotations could (and most certainly will) massively contribute to code pollution [...]“
Val’s Blog
Next, take a look at this code sample and see if you can make sense of it.
@C1(C=2) @C2(C=3) @C3(C=4) @Private(access=PUBLIC) public class c {
@X1(Y=1) @Y2(Z=2) @Z3(X=3) @Public(access=NONE) private int i;
@A1(X="A") @A2(X="B") @A3(X="C") @A4(X="D") public void f() {
}
}
This is what happens if you unleash a new language feature like annotations into the coding community. All sorts of people start using them to create the worst kind of code you could imagine. Do we really want to enable exoting programming styles like these? Would you want to maintain code like this, with annotations in them?
Of course I’m not serious here. Josh Bloch however, was very serious when he used the exact same arguments against the BGGA closure proposal, in his presentation at JavaPolis the other week. Not that he’s completely against closures, but he did fall back on fallacies like these to scare the audience before coming up with some real arguments against the BGGA proposal. And even those where carefully constructed to discuss only the most complex examples from the BGGA proposal. He “forgot” to show some examples of how closures might actually make life (and coding) a lot easier. Which one do you think is easier to understand and maintain, and is less error-prone?
With closures:
doTransaction(entityManager, {=>
Person p = new Person("Last name");
entityManager.persist(p);
});
Without closures:
EntityTransaction tx = entityManager.getTransaction();
try {
tx.begin();
Person p = new Person("Last name");
entityManager.persist(p);
tx.commit();
finally {
if (tx.isActive()) {
tx.rollback();
}
}
The one thing I agreed upon with Bloch in his presentation, is that there already is a Java-like language that has closures (among other things) incorporated from the start, and that is completely compatible with Java. That language is Scala. It is tempting to leave Java be and turn our attention to the next step in the evolution. Tempting. However, Java is not dead, not even nearly. The reality is that most of us will be coding in Java for many years to come. Our communal knowledge base and level of understanding of the language will only grow, allowing for more complex features to gradually be built into it–and at the same time, make our code clearer and our lives easier.
Neal Gafter (black hat) watching Josh Bloch’s presentation at JavaPolis 2007
