On Feb 28, 2014, at 10:11 PM, John Rose <john.r.r...@oracle.com> wrote: > On Feb 28, 2014, at 1:38 AM, Paul Sandoz <paul.san...@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.
