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?

Halfbeak

@Progressionist I am going to revert most of your edit, my surprise wasn't when it was introduced, but recently when I used it for a lock – Halfbeak

No probs, but can you fix the link for AutoCloseable? – Progressionist

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.

Progressionist

Thank you for the info; to me the lock seems like a resource but perhaps there are things I am missing. Working in Spring world, performance hit from wrappers is irrelevant. – Halfbeak

@MiserableVariable: A lock is a resource, at least for me and Dijkstra (:D), see e.g. the Banker's algorithm description. It's not necessary to create a new object each time (you only need something having a close method and can use it multiple times). – Tonjatonjes

@Tonjatonjes I am afraid I don't understand what you are saying. If you have a close method then you also need an open method, which is what the create does for the Lock class. – Halfbeak

@Miserable Variable: You need an "open" method, but it can look like AutoCloseable open() {lock(); return myCloseable;} where myCloseable is a final field (and "closing" it obviously unlocks the lock). – Tonjatonjes

@MiserableVariable: Sorry, I was confused... you're doing it right. – Tonjatonjes

Is this answer still up to date for Java? – Jasisa