<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4" face="monospace">Indeed, many hours of discussion
went into this decision. <br>
<br>
The basic problem is that all of the obvious answers are either
surprising or surprisingly expensive. We considered the following
four approaches:<br>
<br>
1. Allow `new WR(value)`, which is cleared on birth. <br>
2. Allow `new WR(value)`, which is never cleared.<br>
3. Allow `new WR(value)`, which is cleared when all identities
reachable through the value are become weakly reachable.<br>
4. Throw, and encourage implementations that are built on WR
(such as WHM) to offer their own ways of dealing with values. <br>
<br>
You can readily see how (1) would not be what anyone expects. <br>
<br>
You are arguing for (2). While this initially seems credible, its
primary appeal is "yeah it's useless, but it won't break things
that just throw everything in a WHM". But it is actually worse
than useless! The purposes of WRs is to not unnecessarily pin
things in memory. But a WR that is never cleared does exactly
that; if the referent holds identities, then it effectively
becomes a strong reference. <br>
<br>
(3) is a more principled answer, but is very expensive to
implement, and its still not clear that this is what people will
expect.<br>
<br>
(4) is honest, if inconvenient. Given that the majority of uses
of WR are through higher-level constructs like WHM, which have
more flexibility to choose the semantics that is right for their
more restricted domain, it made sense to make this a WHM (and
friends) problem than a WR problem (given that there were no good
answers at the WR level.)<br>
</font><br>
<div class="moz-cite-prefix">On 12/12/2025 10:02 AM, Glavo wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAJL5A3mE7VNvGwQGGV_7EkG-560yCB8HTn59Gfz0CAsUBBAV1w@mail.gmail.com">
<div dir="ltr">Hi,
<div><br>
In the current draft of JEP 401, I saw the following
statement:</div>
<div><br>
</div>
<div>> The garbage collection APIs in java.lang.ref and
java.util.WeakHashMap do not allow developers to manually
manage value objects in the heap.</div>
<div>> Attempts to create Reference objects for value objects
throw IdentityException at run time.</div>
<div><br>
</div>
<div>We could clearly have pretended that all value objects
exist forever and are never collected, so that Reference or
WeakHashMap would still work with value objects.</div>
<div>Obviously, doing so would break far fewer existing codes,
whereas having them directly throw IdentityException would
break a lot more code.</div>
<div><br>
</div>
<div>As an analogy, I think this is very similar to ThreadLocal
on virtual threads. Although virtual threads make many use
cases of ThreadLocal low-performance and high-memory, </div>
<div>Project Loom did not outright forbid users from using
ThreadLocal on virtual threads, yet Project Valhalla chose to
break this (admittedly inefficient) writing style.</div>
<div><br>
I don’t understand why Project Valhalla made this choice. Has
there been any related discussion in the past? I’m really
eager to know the reasoning behind this decision.</div>
<div><br>
</div>
<div>Glavo</div>
</div>
</blockquote>
<br>
</body>
</html>