Proposal: Automatic Resource Management

[Xavi Miró]

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