And not the other way around.
Currently Monitor is the base class, and Mutex inherits from it in order to hide the notify and wait functions. This is easily defeated by having a Mutex downcast to Monitor implicitly, and then it can call notify or wait. So the Mutex class doesn't strongly serve the purpose of encapsulation.
It seems worth keeping the distinction between Monitor and Mutex since most code mostly deals with Mutex in locking code (eg MutexLocker) and commentary.
Lastly, PlatformMonitor inherits from PlatformMutex, so it made sense for the higher level runtime classes to do the same. Note that I didn't change Mutex underlying lock. That could be a further enhancement.
Currently Monitor is the base class, and Mutex inherits from it in order to hide the notify and wait functions. This is easily defeated by having a Mutex downcast to Monitor implicitly, and then it can call notify or wait. So the Mutex class doesn't strongly serve the purpose of encapsulation.
It seems worth keeping the distinction between Monitor and Mutex since most code mostly deals with Mutex in locking code (eg MutexLocker) and commentary.
Lastly, PlatformMonitor inherits from PlatformMutex, so it made sense for the higher level runtime classes to do the same. Note that I didn't change Mutex underlying lock. That could be a further enhancement.
- relates to
-
JDK-8230046 Build failure after JDK-8230003
-
- Resolved
-
-
JDK-8230215 MacOS debug build is broken after JDK-8230003
-
- Resolved
-