Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods

[David M. Lloyd]

A "Monitors" class could possibly be introduced which simply has three 
(intrinsic) static methods: void lock(Object obj), void unlock(Object 
obj), boolean tryLock(Object obj).

Could even add a void lockInterruptibly(Object obj) throws 
InterruptedException.

Why not?  Monitors are not going anywhere, and they're considerably 
lighter than ReentrantLock in terms of memory usage and allocations in 
the (pretty common) case where you only need zero or one conditions. 
Avoiding something like this out of loyalty to new APIs is probably 
pretty misguided.

On 02/27/2014 08:51 AM, Dr Heinz M. Kabutz wrote:
> I have never used this "in the wild", but rather have moved over to the
> ReentrantLock when I needed that particular functionality.
>
> However, I do see a place for this ability.  As I wrote in here:
> http://www.javaspecialists.eu/archive/Issue194.html - sometimes you need
> to modify code that is already using a particular locking mechanism.  To
> then redo everything with ReentrantLock can introduce errors.
>
> If I had a say, I would vote to either keep that method in Unsafe (which
> is where I think it belongs) or provide an alternative way to make the
> tryMonitorEnter() mechanism available to those that might end up needing
> it.
>
> Since I bought my Suzuki Jimny 7 years ago, I have not needed my spare
> wheel even once.  So yeah, I could take it off and drive around without
> it.  But chances are, the day after I take it off, I will need it.
>
> tryMonitorEnter() does no harm and it is out of reach of most programmers.
>
> Regards
>
> Heinz


-- 
- DML