Любой риск в обертке AutoCloseable для java.util.concurrent.locks.Lock?

С try-with-resource, представленным в Java 7, я был удивлен, увидев, что Lock не был доработан как AutoCloseable. Это казалось довольно простым, поэтому я добавил его следующим образом:

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();
    }
}

Это работает с классом AutoCloseableReentrantReadWiteLock, и использование выглядит следующим образом:

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

Так как это кажется таким простым и каноническим использованием автоматического закрытия RAII Я думаю, что должна быть веская причина, по которой это не должно быть сделано. Кто-нибудь знает?

Ответ 1

Это была большая дискуссия, когда try-with-resources был предложен в феврале/марте 2009 года.

Джош Блох, автор предложения, сказал: "Эта конструкция была разработана только для одного: только для управления ресурсами. Она не предназначена для блокировки."

Было отдельное предложение по закрытию замков по отдельности, но ничего не получилось.

Я думаю, что основные причины блокировок не были покрыты:

невозможно добавить методы к интерфейсу в Java 7
производительность при создании дополнительного объекта-оболочки, который реализовал правильный интерфейс
философские возражения против Lock являются другим видом ресурса из дескрипторов файлов (например, создание Lock не связано с вызовом метода Lock)

Вы можете следить за исторической арги-баргой на странице архива, например этот поток.