Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods

Paul Sandoz paul.sandoz at oracle.com
Fri Feb 28 09:38:01 UTC 2014

On Feb 27, 2014, at 3:51 PM, Dr Heinz M. Kabutz <heinz at javaspecialists.eu> 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.

I think your analogy to a spare wheel is misleading. Continuing with the car theme i liken this feature to a pair of fluffy dice dangling from the rear view mirror [1]: distracting; mostly useless; and mostly harmless.

All the data so far indicates this is legacy code [2].

My suggestion, if you consider it important enough, is to write and circulate a draft JEP for such a public API [3].


[1] http://en.wikipedia.org/wiki/Fuzzy_dice

[2] The only dependency on "tryMonitorEnter" i have found was very recently introduced in a test for which there are two known alternatives.

[3] It would be interesting to know if some such public API was considered when j.u.c.locks were introduced, which was almost 10 years ago, and yet in all that time this feature is now virtually unused (not just by you but by many other Java developers too). 

More information about the core-libs-dev mailing list