At JavaOne, closures were still a hot topic of debate. But comparing the different proposals can be tricky, especially as JavaOne only had BGGA based sessions.
Once again, I will be comparing the three key proposals in the 'closure' space - BGGA from Neal Gafter et al, CICE from Josh Bloch et al, and FCM from Stefan and myself, with the optional extension JCA extension. In addition I'm including the BGGA restricted variant, which is intended to safeguard developers when the closure is to be run asynchronously, and the ARM proposal for resource management.
In this comparison, I want to compare the behaviour of key program elements in each of the main proposals with regards the lexical scope. With lexical scoping here I am referring to what features of the surrounding method and class are available to code within the 'closure'.
Neal Gafter analysed the lexical scoped semantic language constructs in Java. The concept is that 'full closures' should not impact on the lexical scope. Thus any block of code can be surrounded by a closure without changing its meaning. The proposals differ on how far to follow this rule, as I hope to show in the table (without showing every last detail):
|Is the language construct lexically scoped when surrounded by a 'closure'?|
|variable names||Part (1)||Part (1)||Yes||Yes||Yes||Part (7)||Yes|
|methods||Part (2)||Part (2)||Yes||Yes||Yes||Yes||Yes|
|type (class) names||Part (3)||Part (3)||Yes||Yes||Yes||Yes||Yes|
|checked exceptions||-||-||Yes||Yes (4)||Yes (4)||Yes (4)||Yes (4)|
|labels||-||-||Yes||- (5)||Yes||- (5)||Yes|
|break||-||-||Yes||- (5)||Yes||- (5)||Yes|
|continue||-||-||Yes||- (5)||Yes||- (5)||Yes|
|return||-||-||Yes||- (6)||Yes||- (8)||Yes|
(1) Variable names from the inner class hide those from the lexical scope
(2) Method names from the inner class hide those from the lexical scope
(3) Type names from the inner class hide those from the lexical scope
(4) Assumes exception transparency
(5) Labels, break and continue are constrained within the 'closure'
(6) The return keyword returns to the invoker of the inner method
(7) The RestrictedClosure interface forces local variables to be declared final
(8) The RestrictedClosure interface prevents return from compiling within the 'closure'
BTW, if this is inaccurate in any way, I'll happily adjust.
So more 'Yes' markers means the proposal is better right? Well not necessarily. In fact, I really don't want you to get that impression from this blog.
What I'm trying to get across is the kind of problems that are being tackled. Beyond that you need to look at the proposals in more detail with examples in order to understand the impact of the Yes/No and the comments.
Let me know if this was helpful (or innaccurate), or if you'd like any other comparisons.