Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods

John Rose john.r.rose at oracle.com
Fri Feb 28 21:11:00 UTC 2014

On Feb 28, 2014, at 1:38 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

>> 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.

The dice in your analogy are *too* useless; nobody can prove tryLock or isLocked useless, just in bad taste.

It's more like a spare tire, maybe just for snow, which is really hard to access, as in "break glass in case of emergency".

I threw it in, way back when, knowing the operation is portable and natural, and expected that folks would break the glass if they needed it.  Despite the barrier to entry, a couple folks did.

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

I think the j.u.c library removed most needs to break the glass (connect to Unsafe).  The users went to the standard API, and JVM native object monitors went out of fashion.

But we are not ready to deprecate them, maybe never, so we should consider whether they need additional modernizations like tryLock or isLocked.

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

I second Paul's suggestion here.  If you like it, buy the unlocked version!  The cost includes working the JEP process, and persuading someone to engineer it.

Since JMM++ is proposing some.field.volatile.readVolatile(), can someObject.synchronized.isLocked() be far behind?  (OK, ugly bikeshed; System.getObjectMonitor(someObject).isLocked().)

Part of the cost of working the JEP conversation will be convincing people that the proposed APIs cannot be subverted somehow or will somehow lead the unwary to write bad code.  The Unsafe API sidesteps such conversations.  Maybe that is its permanent niche:  A locker to store those power tools which we can't figure out how to make safely usable by everybody.

(Yes, I used "permanent" and "sun.misc.Unsafe" in a single thought, along with "maybe".  But let's try to wean ourselves away from it, at least bit by bit.)

— John

More information about the core-libs-dev mailing list