Update on Coin futures from JavaOne

[Joe Darcy]

Hi Neal,

On 11/12/2011 11:35 PM, Neal Gafter wrote:
> On Sat, Nov 12, 2011 at 5:33 PM, Joe Darcy <joe.darcy at oracle.com 
> <mailto:joe.darcy at oracle.com>> wrote:
>
>     Above a maintenance threshold, other small language changes will
>     have to
>     go through the JEP processes.  For example, IMO changing the
>     try-with-resources statement to accept an effectively final
>     variable as
>     a resource to manage (as opposed to requiring a new variable to be
>     declared as done in Java SE 7) would *not* require a JEP.
>
>
> That's interesting, since a resource, for the purpose 
> of try-with-resources, was defined as a value that cannot be used 
> again once closed.  Are you imagining that the definite assignment 
> rules would be modified to produce an error if the variable were 
> referenced after the try-with-resources statement?  Or is this issue 
> too trivial to even discuss?

Well the compiler isn't required to do any alias analysis to make sure 
someone doesn't stash a reference to the resource object such that it 
can be referenced outside of the scope of the try-with-resource block.  
So I wouldn't quite characterize the semantics of the resource handling 
as you have above.

The general expression support in try-with-resources was dropped earlier 
this year for several reasons, including semantic problems if the 
resource was modified in the block. [1]  [2] However, from using the 
feature, it would be handy if one didn't always have to introduce a new 
variable when a perfectly good effective final variable was around; 
having the variable be effectively final avoids semantic problems of the 
block calling close on your behalf.

So, in short, I don't expect the DU/DA rules to be changed to account 
for this tweak to try-with-resources.

-Joe

[1] "Project Coin: JSR 334 Expert Group Update,"
http://blogs.oracle.com/darcy/entry/jsr_334_eg_update

[2] http://mail.openjdk.java.net/pipermail/coin-dev/2011-January/002972.html