Simple Resource Clean-up (original) (raw)

Neal Gafter neal at gafter.com
Tue Mar 3 06:58:36 PST 2009

The problem with addressing this sort of problem as a language change rather than an API is that the solution has to attempt to be a one-size-fits-all: you have to decide which 80% to aim for. An API - or a set of APIs - can instead be tuned to the use cases.

On Tue, Mar 3, 2009 at 12:34 AM, Roger Hernandez <rhvarona at gmail.com> wrote:

On Tue, Mar 3, 2009 at 3:18 AM, Joshua Bloch <jjb at google.com> wrote:

Roger,

On Mon, Mar 2, 2009 at 9:02 PM, Roger Hernandez <rhvarona at gmail.com>wrote:

I saw how the previous Automatic Resource Management proposal got torn to pieces

That's not quite fair.  Only one person objected, and I had good responses to all of his objections.  So I believe the proposal is alive and well.  Others have informed me (off list) that they see Automatic Resource Management as perhaps the most valuable language change that we could introduce for Java 7. Regards, Josh

You are right, I used strong wording but my concern was that the proposal would not be followed up on, and we would have to live with another 4 years of this before JDK 1.8 came out. I think that your proposal, Automatic Resource Management is definitely more thought out and more complete than what I proposed, and handles more complex scenarios and corner cases.   It would be a very valuable feature if it gets into JDK 1.7.  However, I am worried that the extra complexity will cause it to be dropped altogether, so if something gets implemented that takes care of the simpler scenarios that make up 80% of the cases, that would be good enough from my point of view. Thanks, -- Roger Hernandez

More information about the coin-dev mailing list