Abstract: In this newsletter we discuss why we unfortunately will not be able to use the try-with-resource mechanism to automatically unlock in Java 7.
Welcome to the follow-up newsletter to the 190th issue of The Java(tm) Specialists' Newsletter, sent to you from the beautiful Island of Crete. Greek Easter is around the corner, so the lambs are already starting to get mildly concerned. Everything works in a rhythm in Crete. We have certain festivals, parades, religious holidays, then the 14 week summer holiday. On the 15th of August, there is a nationwide party, after which a lot of people go back to work. We then have a big day on the 28th October as the entire country celebrates my wife's birthday. At least I think that is what is going on. Then of course we have Christmas, New Year, the throwing of the cross into the harbour, a party before lent, then lent, and then we get back to where we are today. It almost seems like we are caught in an infinite loop as many of these festivals have been celebrated for thousands of years. And at the end of lent, the lambs are set upon by ten million ravenous and meat deprived Greeks. Poor critters. The Greek word to describe them is "nostimo".
javaspecialists.teachable.com: Please visit our new self-study course catalog to see how you can upskill your Java knowledge.
In this newsletter we look at some of the objections raised regarding my previous Automatically Unlocking with Java 7 article.
The first person to write was Brian Goetz, pointing out that we will probably not be able to use the expression form with try-with-resource. It is possible to fudge it by using a declaration, but the result is so ugly that I'd rather not show it. Bruce Chapman then sent me a link to the discussion on Joe Darcy's blog where he talks about this. I will explain in a bit why they disallowed expressions.
Several people contacted me to let me know that you
can now have a semicolon after the
try
declaration. I have an older Java 7
build on my Mac that did not allow this.
After pointing to my newsletter on the coin-dev mailing list, several people pointed out that the cost of constructing the additional lock objects would be unacceptable with critical code. However, based on my initial results, escape analysis in the Server Hotspot compiler seems to eradicate that cost completely. Worrying about the costs of object construction is thus a premature optimization.
Programmers are notoriously bad at coding concurrency correctly. We should thus rather encourage them to use higher-level, thread-safe classes, rather than trying to use locks explicitly.
Reinier Zwitserloot published a nice explanation why we cannot allow expressions in the new try-with-resource construct. He kindly gave permission for me to republish it here:
To summarize the log, you can't tell the difference between generics on the type of a variable declaration and the lesser than operator:
try (x < y ? resourceA : resourceB) {}
vs:
try (x<y> z = resourceA) {}
An LL(k) parser can't tell the difference until its too late. A packrat/rd parser could, but both javac and ecj are LL(k) parsers so changing this would require both to be rewritten from scratch.
Re-introducing the ability to use just an expression here would require some sort of keyword or symbol that is unambiguous. This could work:
try (= expression) {}
but it breaks the principle of least surprise, in that without knowing a heck of a lot about the capabilities of LL(k) parsers, the need for the = sign is a mystery.
I gather from this discussion as well as the reaction to the fine work by Heinz Kabutz that the primary use case for expressions in ARM statements is locks, and this use case is not good enough, even if it is actually fast enough at least on server mode VMs.
Thank you very much Reinier for that excellent explanation. It is easy to forget the reasons why computer languages need to have a certain syntax.
Heinz
We are always happy to receive comments from our readers. Feel free to send me a comment via email or discuss the newsletter in our JavaSpecialists Slack Channel (Get an invite here)
We deliver relevant courses, by top Java developers to produce more resourceful and efficient programmers within their organisations.