Any risk in a AutoCloseable wrapper for java.util.concurrent.locks.Lock?

Question

With try-with-resource introduced in Java 7, I was surprised to see that that the Lock has not been retrofitted to be an AutoCloseable. It seemed fairly simple, so I have added it myself as follows:

class Lock implements AutoCloseable {
    private final java.util.concurrent.locks.Lock _lock;
    Lock(java.util.concurrent.locks.Lock lock) {
        _lock = lock;
        _lock.lock();
    }
    @Override 
    public void close() {
        _lock.unlock();
    }
}

This works with an AutoCloseableReentrantReadWiteLock class and usage is as follows:

try (AutoCloseableReentrantReadWiteLock.Lock l = _lock.writeLock()) {
    // do something
}        

Since this seems so straightforward and canonical use of auto-closing RAII I am thinking there must be a good reason this should not be done. Anybody know?

Answer 1

This was a big debate when try-with-resources was proposed in February/March 2009.

Josh Bloch, the author of the proposal, said "This construct was designed for one thing and one thing only: resource management. It was not designed for locking."

There was a separate proposal to cover locks separately, but it didn't get anywhere.

I think the main reasons locks were not covered were:

• not possible to add methods to an interface in Java 7
• performance hit of creating an extra wrapper object that implemented the correct interface
• philosophical objections to Lock being a different kind of resource from file handles (e.g. creation of a Lock does not entail invoking the lock method)

You can follow all the historical argy-bargy on the archive page, for example this thread.