On Tue, 20 Oct 2020 16:35:02 GMT, Mandy Chung <mch...@openjdk.org> wrote:
>>> @kimbarrett your reworded text is okay. I think "if it initially had some >>> other referent value" can be dropped. >>> >>> For a `Reference` constructed with a `null` referent, we can clarify in the >>> spec that such reference object will never >>> get cleared and enqueued. I suggest to file a separate issue to follow up. >> >> I don't think that clause can be dropped, because of explicit clearing (by >> clear() or enqueue()) rather than by the >> GC. If the reference was constructed with a null referent, >> ref.refersTo(null) cannot tell whether ref.clear() has been >> called. > >> Mandy's comment implied that references with a null referent never get >> enqueued. Otherwise when would they get >> enqueued? There would be nothing to trigger it. > > Sorry I should have been clearer. What I try to say is that > `Reference(null)` > will never be cleared and enqueued by GC since its referent is `null`. > > Kim is right that `Reference(null)` can be explicitly cleared and enqueued > via `Reference::enqueue`. `Reference::clear` on such an "empty" reference > object is essentially a no-op. Whoever creates an "empty" reference would > not intend to be cleared. > >> > But the more we discuss this the more I think allowing an initial null >> > referent was a mistake in the first place. :( >> >> I agree, but here we are. Very hard to know what the compatibility impact of >> changing that would be. > > There are existing use cases depending on `Reference(null)` for example as a > special > instance be an empty reference or the head of a doubly-linked list of > references. > This was discussed two years ago [1]. > > [1] > https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-July/054325.html David, Mandy, and I discussed the wording in refersTo javadoc and reached a consensus that is reflected in 3a15b6a. ------------- PR: https://git.openjdk.java.net/jdk/pull/498
