The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

tpeierls (7) [Avatar] Offline
#1
There is no need for a separate "lock" Object field in the ResourceCloser example in 7.2.3. The toClose field is final, so you can mark it @GuardedBy("self") and synchronize on it instead with "synchronized (toClose) {...}". (And toClose should be private.)

--tim
dhanji.prasanna (37) [Avatar] Offline
#2
Re: No need for separate lock object in 7.2.3 Using Java’s Closeable interf
Hi

I thought of this but decided it was clearer in the example to make an explicit lock object named "lock". Is there a good argument for synchronizing on the field itself?

Yes it absolutely should be private! Thanks for catching that =)

Dhanji.
tpeierls (7) [Avatar] Offline
#3
Re: No need for separate lock object in 7.2.3 Using Java’s Closeable interf
> I thought of this but decided it was clearer in the
> example to make an explicit lock object named "lock".
> Is there a good argument for synchronizing on the field itself?

Just that it's more direct: "All access through reference toClose is guarded by the built-in lock associated with the toClose object itself."

If you want to be more vanilla, just use @GuardedBy("this") and "synchronized (this) {...}" -- having a separate lock Object only adds code that you have to explain away.

--tim