Java 7で導入されたtry-with-resources構文とLockインタフェースの関係について。
Java標準ライブラリのロック処理ではAutoCloseableインタフェースを利用しないため、try-with-resources構文を利用した「変数スコープにもとづくロック獲得・解放処理（Scoped Locking Pattern*1）」はサポートしない。
Lock lk = /*...*/; // 正しい利用方法 lk.lock(); try { // クリティカルセクション } finally { lk.unlock(); } // Scoped Locking Pattern（未サポート） try (AutoUnlockHolder scopedLock = AutoUnlockHolder.lock(lk)) { // クリティカルセクション }
try-with-resources構文を含む"Automatic Resource Management"*2の提案者Joshua Bloch氏により、あくまでも「リソース管理」を目的とした言語機能であり、ロック処理のためのデザインではない旨が明言されている。とはいえ、提案当時から現在にいたるまで要望が多く議論を呼ぶ話題ではある。*3
A gentle reminder: this construct was designed for one thing and one thing only: resource management. It was not designed for locking. Java already contains a native construct for locking (synchronized). A very small minority of Java programmers use java.util.concurrent.atomic.Locks. Support for them is not a priority. Nearly all Java programmers use resources such as java.io.InputStream, OutputStream, Reader, Writer, Formatter; java.nio.Channel; java.net.socket; java.sql.Connection, Statement, ResultSet, or java.awt.Graphics. That's what this construct is designed for.
http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000157.html
関連URL
