mark.reinhold at mark.reinhold at
Tue Nov 24 17:08:32 UTC 2015

2015/11/24 1:32 -0800, paul.sandoz at
>> On 24 Nov 2015, at 01:31, mark.reinhold at wrote:
>> This seems eminently reasonable, but why does it belong in the
>> java.lang.ref.Reference class?  It has nothing (directly) to do
>> with reference objects.
>> java.lang.Runtime, perhaps?
> Out of all the places i thought Reference was the least indirect. The
> method documentation refers to the notion of "strongly reachable” in
> the j.l.ref package doc (I should update to link directly to that). In
> effect it’s an operation on potential referents that relates to
> reachability, garbage collection and finalization.
> A further weaker argument is Reference is not commonly used thus there
> may be less chance of this method being misused.
> I do prefer the current location, but i don’t strongly object to
> moving it to Runtime.

Having read through more of the background, I now agree that the
Reference class is a suitable home for this method.  Most anyone who
needs this method will already be thinking about finalization and/or
reference objects.

I do think "keepAlive" is a better name, especially since there are
(at present) no other "*Fence" methods in sight.

A few more questions/suggestions:

  - This method started out (way back in 2009, on concurrency-interest)
    as part of a more general java.util.concurrent.Fences class [1].
    Do we have any expectation that Fences will ever be proposed for
    inclusion in the platform, or is it something that's otherwise

  - The specification, while short, needs some work.  As far as I can
    tell the scope of the guarantee made by this method does not extend
    beyond that of the method that invokes it, yet the specification
    says "regardless of any prior actions of the program", which is
    almost certainly too broad.

  - Is it worth including one or both of the examples from the original
    Fences draft?

- Mark


More information about the core-libs-dev mailing list