On 20/08/2026 15:38, Pavel Rappo wrote:
I have a quick question on the library side of JEP 401.
In JDK, there are cases where an implementor or client provides an
object to be used as a monitor. I can think of these, but there are
likely more:
* java.util.Collections#synchronizedCollection(java.util.Collection<T>)
* java.io.Reader#lock and java.io.Writer#lock
* java.nio.channels.SelectableChannel#blockingLock
If a value object is provided, any synchronization attempt will fail.
That said, I wonder if there are any plans to be more helpful here so
that any failures are warned about or happen sooner.
This is good topic as there are a number of APIs that might need
clarification.
For synchronizedCollection, it synchronizes on the wrapper so I don't
think there is an issue there.
The Reader/Writer constructors that take a lock object are protected
methods. They could potentially reject a value object but then we see
that the "lock" field is a non-final protected field that the subclass
can change at any time. Guidance in the API docs might avoid bug reports
from people pointing this out.
SelectableChannel::blockingLock returns the lock object, you can't set
it to a value object. (Separately, we should deprecate this method at
some point as it can't be used with channels that support concurrent I/O
operations. It was originally intended for socket adaptors. The JDK
implementation does not use it, except to coordinate changing the
blocking mode.)
Another example that comes to mind is ClassLoader::getClassLoadingLock
where it wouldn't make sense for a custom class loader to override the
method and return a value object. TimeUnit.timedWait is an example where
calling it with a value object will throw IMSE as the caller could not
have synchronized on the monitor, so I think that one is okay.
Can you create an issue in JBS as I think it would be useful to identity
classes where some clarification is required, and maybe where
IdentityException needs to be specified to be thrown.
-Alan
