Project Coin: Try out try-with-resources

As of build 105 of JDK 7, the compiler and libraries have support for Project Coin's try-with-resources statement (ARM blocks).

We're curious to get feedback on how try-with-resources works in practice, so please download the build, use the feature to on your favorite Closeable type, and report back on how it goes.

Comments:

This is really interesting. I think automatic resource management must be one of the best additions to Java 7. The programming style this allows is well over a decade old (see C++ raii), but better late than never ;)

I do wonder btw if there are any (open JDK) builds for OS X. Would love to try this on my Mac, but the hassle of building the whole thing keeps me back a little.

Posted by Robert Hugh on August 23, 2010 at 06:41 PM PDT #

I really like this feature, but what would make it even more useful would be if it was possible for the managed resource to be notified about whether the ARM block was exited normally or exceptionally. Something like having the close method accept a single argument: an Exception, and let that argument be null if the block exits normally. A prime use case for this is for when the managed resource is a transaction, then close with exception would mean "roll back the transaction", while close with no exception would mean "commit". The Python Programming Language has ARM blocks that work like this: http://www.python.org/dev/peps/pep-0343/

Has the ship sailed on adding support for something like this in the try-with-resource feature for Java?

Posted by Tobias Ivarsson on August 24, 2010 at 01:16 AM PDT #

@Robert,

Dalibor suggests Mac users look at
http://wikis.sun.com/display/OpenJDK/BSDPort
for assistance with getting the bits built.

Posted by Joe Darcy on August 24, 2010 at 03:31 AM PDT #

@Tobias,

Since the predominant use of a "finish up" method in Java thus far has been the zero-argument "close" method from java.io.Closeable, Project Coin in JDK 7 will not include any support for a 1-argument close method as you've outlined since the current libraries don't support this.

I would expect future expansions of try-with-resources to possibly support methods with names like "dispose" before supporting arguments to the finish up method.

Posted by Joe Darcy on August 24, 2010 at 03:48 AM PDT #

One of the first lessons we as parents teach to our children is: Learn from others.
Why does this not apply to programming languages?

Try-catch-finally is about error handling and not about ARM.
I wanna see you guys explaining the extended try-catch-finally to a Java newbie in a single sentence...

My first thought on starting using Java again was: Where is my "using"?

Please, don't be reluctant and simply introduce .NET's "using" (http://msdn.microsoft.com/en-us/library/yh598w02%28VS.80%29.aspx)?
It's straight forward, easy to understand and does not mix up things.
You can then even rename "java.lang.AutoCloseable" to "java.lang.Closeable" as it's not about auto-closing but about a clearly programmed/stated behavior being part of "using".

Please don't start a debate about .NET vs. Java - it's all about taking advantage of the fillets of each language.
C# clearly learned a lot of Java, so why shouldn't Java do the same...

Posted by Patrick Dreyer on August 24, 2010 at 04:16 PM PDT #

"I would expect future expansions of try-with-resources to possibly support methods with names like "dispose" before supporting arguments to the finish up method."

Crap.

Oh well, this is marginally useful.

The lack of ability to handle transactions or other resources that have to 'close' differently depending on whether the block exited normally or via exception is a major oversight. In fact, the resources that need to do this tend to be the most difficult ones to manage with the worst bugs when done incorrectly. So this feature is helping out the less important use cases and neglecting the most critical ones.

Using bytecode rewriting frameworks to deal with the above will remain the best practice to cover up the language weakness. Annotations leveraged for bytecode manipulation to the rescue again.

Posted by Scott Carey on August 26, 2010 at 04:15 AM PDT #

no comment

Posted by guest on August 29, 2010 at 02:59 PM PDT #

Yes, an ability to distinguish normal and exceptional completion would be a major advantage, almost a must.

Posted by al0 on August 30, 2010 at 10:44 PM PDT #

I don't think this should be added. I just don't see the cost/benefit if there is a plan for closures still in place. I think, it would be better to work on closures, put a "using" method in the IO library and go that route.

To me, this only made sense when they killed closures the first time.

Posted by Brian on September 08, 2010 at 03:11 AM PDT #

I hardly see how it is related to closures.

Posted by al0 on September 08, 2010 at 05:05 AM PDT #

@al0,

If closures with control abstraction were being added to the language, then a new control structure like try-with-resources could be implemented as a library method. However, since lambdas with that property are \*not\* being added, a library method is not a viable implementation route for try-with-resources.

Posted by Joe Darcy on September 08, 2010 at 05:29 AM PDT #

Probably I misunderstood Brian's comment - I assumed that it is related to an ability to distinguish "normal" and "exceptional" completion in try-with-resource.

Posted by al0 on September 08, 2010 at 05:54 AM PDT #

Post a Comment:
Comments are closed for this entry.
About

darcy

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
News

No bookmarks in folder

Blogroll