Proposal: Automatic Resource Management

[Xavi Miró]

There is an error in my code:

this part is incorrect, the Lock object to unlock is this.lock:

  public void close throws Exception {
    lock.unlock();
  }

...so:

  public void close throws Exception {
    this.lock.unlock();
  }

Sorry!

   Xavi

Xavi Miró escribió:
> Neal,
>
>    this proposal tries to achieve big benefits with small changes. In 
> my opinion, Streams, Readers, Writers, Formatters, Channels, Sockets, 
> Connections, Statements, ResultSets, or java.awt.Graphics are much 
> more used than Locks. This does not mean that Locks are not important. 
> If the proposal can be applied to the formers it will be a huge 
> benefit, although Locks can't be used directly with it.
>
>    I agree with Bob, adapters can be used for many use cases where 
> "close" methods are incompatible with the Disposable or Resource 
> interface. And although the proposal is not designed to manage Locks, 
> perhaps a kind of "safe unlocker" can be easily made, so this original 
> code:
>
>      myLock.lock();
>      try {
>          // access the resource protected by myLock
>      } finally {
>          myLock.unlock();
>      }
>
> could be written this way:
>
>      try (SafeUnlocker = new SafeUnlocker(myLock)) {
>          // access the resource protected by myLock
>      }
>
> where SafeUnlocker would be more or less like this:
>
> public class SafeUnlocker implements Disposable {
>
>   private final Lock lock;
>
>   public SafeUnlocker(Lock lock){
>     this.lock = lock;
>     lock.lock();
>   }
>
>   public void close throws Exception {
>     lock.unlock();
>   }
> }
>
> The name SafeUnlocker maybe it's not appropriate, but I haven't found 
> a better one. There can be problems in this source code that I haven't 
> seen...this is only an idea.
>
>   Regards,
>
>       Xavi
>
> Neal Gafter escribió:
>> On Fri, Mar 6, 2009 at 4:02 PM, Bob Lee <crazybob at crazybob.org> wrote:
>>   
>>> On Fri, Mar 6, 2009 at 3:19 PM, Neal Gafter <neal at gafter.com> wrote:
>>>     
>>>> If you've already decided which resource-like APIs "count", then you
>>>> don't need to ask us.
>>>>       
>>> Did I unfairly discount some APIs? If so, please speak up.
>>>     
>>
>> I did, and you quoted me just after asking the question (see below,
>> for example).  Apparently, because some other use cases are more
>> problematic, you feel that the ones I brought up are unimportant.
>> I've certainly run into situations where automatic pairing of resource
>> acquisition and release for java.util.concurrent locks would have
>> avoided errors.  I know that supporting resource acquisition and
>> release for all the different resource APIs that exist (or will exist)
>> in Java is difficult to do apriori in a language change (which is why
>> I prefer an API-based solution), but pretending the use cases don't
>> exist seems dishonest.
>>
>>   
>>>> Personally, I'd like java.util.locks.Lock to be
>>>> easier to use, though I understand this proposal doesn't solve that
>