@T(a=3, b=@D(12))
@U(@T(a=14, b=@D()))
class X {
}

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.

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’.

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

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.

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).