Update on Coin futures from JavaOne
joe.darcy at oracle.com
Sun Nov 13 08:49:09 PST 2011
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.   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.
 "Project Coin: JSR 334 Expert Group Update,"
More information about the coin-dev