I would say that spec does not tell you anything about the blocking contract for try-with-resources, so as far as you are OK with the semantics outlined in JLS 14.20.3, you are good to go either way. Another example of blocking close() would be releasing the object in question to synchronized cache, which is potentially blocking.
BTW, while awaiting shutdown looks cleaner, there are some nasty complications if the workers in thread pool are ignoring interrupts, in which case you can block indefinitely. Not waiting for termination may silently leave some of threads running (I find it enlightening to find stale threads burning the CPU for days on production systems, while application thinks they are stopped.) Hence, either way of implementing TPE.close() as the standard method has its drawbacks, the users have to choose either one that fits their use case. -Aleksey. On 10/05/2012 01:56 PM, Alan Bateman wrote: > > Forwarding Kasper's mail to the right list. > > -------- Original Message -------- > Subject: AutoCloseable blocking or not > Date: Fri, 5 Oct 2012 11:42:35 +0200 > From: Kasper Nielsen <kaspe...@gmail.com> > To: nio-disc...@openjdk.java.net > > > > Hi, > > I have a question about the AutoCloseable interface. Since I cannot > find any mention about how asynchronously closeable resources should > be handled. > > Say I wanted juc.ThreadPoolExecutorService to implement AutoCloseable. > When close() returned should the executor be in the shutdown phase or > in the terminated phase? > > In other words should I implement close() like this (which I believe) > > public void close() { > executor.shutdown(); > executor.awaitTermination(Long.MAX_VALUE, TimeUnit.SECONDS); //ignore > any interrupted exceptions > } > > or like this > > public void close() { > executor.shutdown(); > } > > - Kasper >