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 <[email protected]> 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.
