Risks for locks in try-with-resources blocks in Java 8

Question

If I do

try(Lock lock = lockProvider.lock()) {
    // some code that doesn't use variable lock
}

Is there a risk that the compiler or the JITer to remove the lock creation because it sees it as unused inside the block?

Later Edit:

A bit of context. I'm coming from a .NET Background where, in C#, it is allowed to do stuff such as:

using(Transaction tx = BeginTransaction())
{
    // code that does things without touching the tx variable, such as SQL connections and stuff
}

in fact it can even be shortened to

using(BeginTransaction())
{
    // code that does things without touching the tx variable, such as SQL connections and stuff
}

The static compiler and the JIT compiler will keep the BeginTransaction call and at runtime it will always happen.

However in Java there seems to be a lot of issues and negativity around using try-with-resources for other things that are resources.

@lexicore: No...it's neither `Closeable` nor `AutoCloseable`, so this would be invalid syntax. — Makoto, Mar 07 '18 at 16:19
What are you trying to achieve? If you don't use the lock, then does it matter whether it's created or not? — assylias, Mar 07 '18 at 16:20
If this could be removed then call to any `void` method could be removed as well (same logic). Which is nonsense so I don't think this will be removed. — lexicore, Mar 07 '18 at 16:20
I am trying to ensure the block of code runs under a lock but I'm not using the lock reference inside the block of code. The lock constructor obtains the lock and closing it releases the lock. — Andrei Rînea, Mar 07 '18 at 16:22
if `lockProvider.lock()` has side effects then the JIT is not supposed to remove it. — assylias, Mar 07 '18 at 16:23
Is this `Lock` your own class? `java.util.concurrent.locks.Lock` does not implement `AutoCloseable`. — Mark Rotteveel, Mar 07 '18 at 16:29
@assylias : That's what I think too but I need a confirmation.. — Andrei Rînea, Mar 07 '18 at 16:31
Actually, `lock` is used in the body of `try`. The last statement of that body *logically* if not physically is `lock.close()`. — , Mar 07 '18 at 16:35
It's not an existing class in JDK or Guava, actually it isn't called like that but I needed to express a short example and avoid disclosing sensitive information. — Andrei Rînea, Mar 07 '18 at 17:12

score 7 · Accepted Answer · answered Mar 07 '18 at 16:47

No, there is no risk of the lock being optimized away, at least assuming its lock() and close() methods are not actually no-ops, but perform synchronization actions.

The "negativity" you cite isn't about correctness, but just about using the tool the way it was intended, and how other tools, like static analyzers, can give you misleading guidance when you use AutoCloseable contrary to that intent.

By the way, if you do this, I recommend calling your wrapper something other than Lock to avoid confusion with java.util.concurrent.Lock.

Risks for locks in try-with-resources blocks in Java 8

1 Answers1