Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods

[David M. Lloyd]

Making the language Kindergarten-friendly at the cost of general 
usefulness is a mistake, IMO.  And anyway there's nothing that is less 
safe about a Monitors class than ReentrantLock; on the other hand, 
monitors continue to be considerably lighter (size and (for most of the 
history of JUC) speed) by every measurement I've ever made.  I would 
advise monitors over ReentrantLock 9 times out of 10 in any of our code.

I just don't think your metaphors - neither of monitor methods being 
dangerous, nor of Java developers being infants - are really apt.

On 03/02/2014 02:51 AM, Dr Heinz M. Kabutz wrote:
> With a curious 9 months old crawling around the house, I've just moved
> the sharp knives to the top draw in the kitchen - out of reach.  I don't
> think we should be encouraging people to use monitor.tryLock() for
> various reasons:
>
> 1. We have a richer interface with Lock/ReentrantLock, including better
> Condition that allow easier timed wait idioms.
>
> 2. It is just too easy to get the idioms wrong for Lock.lock() and
> Lock.unlock().  Every time I show this idiom some people in the audience
> start arguing with me:
>
> lock.lock();
> try {
>   // do something
> } finally {
>   lock.unlock();
> }
>
> IMHO, this is really an edge case that might be useful to have
> semi-accessible at some point, but not something that should generally
> be done.  It belongs in the same draw as the sharp knives and the
> ability to cause arbitrary asynchronous exceptions (which has been made
> more difficult to do in Java 8).
>
> Brian Goetz wrote:
>> Except that Lock has features that are not supported by intrinsic
>> locks (timed wait, interruptible wait.)  So the Lock returned would
>> not conform to Lock's contract, and attempting to call these methods
>> would probably throw UOE.
>>
>> On 2/27/2014 6:12 AM, Stephen Colebourne wrote:
>>> On 26 February 2014 20:54, Martin Buchholz <martinrb at google.com> wrote:
>>>> It does seem that being able to tell whether a java object monitor is
>>>> currently locked is useful for debugging and monitoring - there
>>>> should be a
>>>> way to do that.
>>>
>>> Perhaps it would be useful to be able to expose a java object monitor
>>> as an instance of Lock?
>>>
>>> Lock lk = Lock.ofMonitor(object)
>>> if (lk.tryLock()) {
>>>    ...
>>> }
>>>
>>> Such a method feels like it would be a useful missing link between
>>> synchronized and locks.
>>>
>>> Stephen
>>>
>>


-- 
- DML