Hi Kris,
On Friday, September 2, 2016, Krystal Mok <rednaxel...@gmail.com> wrote:
> Hi core-libs developers,
>
> I mostly live down in the VM world, but recently I've been playing with
> j.u.c.locks a bit, and saw that there's an opportunity to retrofit the API
> with the try-with-resources syntax. I wonder if anybody has brought this
> topic up before; apologies if there had been.
>
> From the JavaDoc of j.u.c.l.ReentrantLock, the following is a typical
> usage:
>
> class X {
> private final ReentrantLock lock = new ReentrantLock();
> // ...
>
> public void m() {
> lock.lock(); // block until condition holds
> try {
> // ... method body
> } finally {
> lock.unlock()
> }
> }
> }
>
> The try...finally construction really pops out as a try-with-resources
> candidate.
>
> So what if we retrofit that with something like:
>
> class X {
> private final ReentrantLock lock = new ReentrantLock();
> // ...
>
> public void m() {
> try (lock.lock()) { // block until condition holds
> // ... method body
> } // automatic unlock at the end
> }
> }
This is Java 9 syntax right? Java 7-8 require an assignment to a local in
the TWR block.
>
> Assuming lock.lock() returns a temporary wrapper object (let's call it a
> "Locker" for this discussion), where Locker implements AutoCloseable, and
> its close() method calls lock.unlock().
> That'll make the API look and feel quite similar to the built-in
> "synchronized () { ... }" syntax. With escape analysis and scalar
> replacement implemented correctly in the VM, this temporary Locker object
> wouldn't incur much (or any) runtime cost after optimized JIT'ing, so it
> feels like a pure win to me.
>
> What do you think?
So using TWR with scoped objects, such as this, is used quite a bit; I've
seen this idiom many times, and have used it myself.
Now, what's the value add to have this in the JDK? One can write such a
Locker themselves quite easily.
I also don't hold as much confidence in EA as you, apparently - it's too
brittle and unpredictable in its current form, IMHO. Of course when the
allocation doesn't matter, that part isn't a big deal.
My $.02.
>
> Best regards,
> Kris (OpenJDK username: kmo)
>
--
Sent from my phone
