Simple Resource Clean-up

[Neal Gafter]

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
>
>