2015/11/24 1:32 -0800, paul.san...@oracle.com:
>> On 24 Nov 2015, at 01:31, mark.reinh...@oracle.com 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
abandoned?
- 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
[1]
http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/atomic/Fences.html
