Closures And The Ars Rhetorica
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
2007-12-23. 9 responses.
Your transaction example might not be the best way to debunk Joshs’ arguments… Josh does want to add ARM (automatic resource management) blocks to Java (see here), which would allow you to do something like this:
try (entityManager.getTransaction()) {
… // Perform action transactionally
} catch(AbortException e) {
…
}
Without having the modify the Java syntax to heavily.
Personally I was a bit worried about the non-local return problems which Josh sketched, but mr. Gafter managed to convince me Josh ‘overlooked’ the implicit use of the RestrictedInterface for function types or closers defined using the => sign (see here).
@p3t0r: “without having to modify the syntax”? The abuse of existing keywords (try and protected) is one of the reasons I dislike the CICE proposal.
But my point was primarily to show the fallacies in Bloch’s argument. I added the code as an example of how most closures you’ll encounter in everyday coding will make your code simpler, not more complex–even when following the BGGA proposal.
Danny,
You said:
“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.”
I did not use “the exact same arguments.” You used intentionally obfuscated code and you didn’t provide its provenance. My code examples were not written with intent to obfuscate and their sources were clearly identified: The inscrutable code on slide 30 was test code that comes with the closures prototype. The equally inscrutable code on slide 31 came from Mark Mahieu’s blog, and was endorsed on Neal Gafter’s blog.
The unexpected interactions on slide 33 came from my attempts to use the facility to do some very simple things. The examples on slides 36, 38, and 43 (which I composed) appear straightforward but their appearance belies their behavior. They are, essentially, puzzlers, demonstrating real hazards of the BGGA closures facility as it is currently specified (v0.5).
So I reject your charge of rhetorical trickery. The dangers I discussed are real. Not just unintentional non-local transfer of control and erroneous access to local variables, but the serious risk of harm to the readability of Java code and learnability of the language–of harm to “the feel of Java.” Yes, it’s possible to write nice little examples with BGGA closures, but I suspect that practical uses would have a character more like the code contained in my talk.
Josh
Contrary to what you might think, I do not think Java is dead (nor did I say so). I agree completely that Java should not be left alone just like that. There is too much experience and available stuff that you do not want to leave behind. At the same time I do not agree that Java can be extended over time. Extending a language is a very hard thing to do; the rigid syntax of Java is no longer up to it (except maybe some small things). This is the reason I promoted Scala in my article: keep all the good Java stuff /and/ move on to newer language constructs.
Josh,
Thank you for your detailed clarification. I wanted to show that, even for existing (and by now well-accepted) language features, statements can be found on the Internet about how scary and dangerous these features can be; and that code can be written using these features that may seem inscrutable at first sight (especially if we’re talking about new features) (and any code ripped from its context and put on a slide may seem inscrutable to us but make perfect sense to the people writing and using it). In my opinion, arguments like these should not be used to discuss new language features.
I mean, you could have come on stage and presented your own proposal, showing its strengths and weaknesses, demonstrating its usefulness in various use cases. Much like Neal Gafter did last year. Instead, you chose to start with a full-blown attack on the BGGA proposal, introducing it with two random quotations (from people the audience would identify with), followed by showing some of its most complex examples. I’m certainly not accusing you of trickery, but if you were out to make a nicely constructed plea to the audience against the BGGA proposal, you couldn’t have done much better.
Finally, I hope you’ll agree that “the feel of Java” is a subjective notion. The BGGA proposal has been around for more than a year, and by now, the syntax does not feel alien or un-Java-like to me. I will gladly put up with the dangers and risks you’re talking about–not just to be able to use closures today, but to see a future far beyond where Java will not be left behind as a ‘dead language’.
Erik, I left a reply on your blog.
Wouldn’t the non-closure Java example look like this:
new TransactionTemplate() { protected void withTransaction(EntityManager em) { Person p = new Person("Last name"); entityManager.persist(p); }) } .execute();or with CICE:
new TransactionTemplate(EntityManager em) { Person p = new Person("Last name"); entityManager.persist(p); } .execute();There are arguments for closures in Java, resource management clearly isn’t.
Peace
-stephan
—
Stephan Schmidt :: stephan@reposita.org
Reposita Open Source – Monitor your software development
http://www.reposita.org
Blog at http://stephan.reposita.org – No signal. No noise.
For some obscure annotations code, the compiler test suite has some doozies
@T(a=3, b=@D(12))
@U(@T(a=14, b=@D()))
class X {
}
@admin: I just have to say your website is the first I’ve come across this morning that doesn’t have spelling errors every other sentence. Thanks for taking the time to construct something that doesn’t look like a 5th grader wrote. I apologize, just had to vent.