This question should better be asked on concurrency-interest mailing list [1]. And I'm sure it has been asked there a numerous of times before. I guess one of the reasons it hasn't been done is because of a semantics mismatch. java.util.concurrent.locks.Lock is a reusable object. It can be locked after it's been unlocked. And in general it may have a very peculiar lifecycle and rules about which method should be called when and by which thread. java.lang.AutoCloseable semantics seems to apply to objects associated with some resources that may be closed only once (kind of suggests from close's idempotence requirement). -------------------------------------------------------------------------------- [1] http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

On 20 Apr 2016, at 14:45, kurtymckurt <kurtymckurt@gmail.com> wrote:

Has it been considered to have the Lock interface use AutoCloseable? That way users can lock in a try and not have to worry about a finally?

-- View this message in context: http://openjdk.5641.n7.nabble.com/Locks-implementing-Closable-tp267580.html Sent from the OpenJDK Core Libraries mailing list archive at Nabble.com.