Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods

[Paul Sandoz]

On Feb 28, 2014, at 10:11 PM, John Rose <john.r.rose at oracle.com> wrote:
> 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.
> 

I did qualify with "mostly" :-)


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

Although the only external dep. i can currently find is required just for Java 6 (which Oracle no longer supports).


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

All the data so far suggests we don't need them; are they to be treated any differently to other methods we have also removed from other non-public API classes?

We could always add them back in the unlikely event of a new requirement,  or are you indicating that these should also be retained in case code outside of the JDK needs to break the glass?

Paul.