Why is it not supported to create References for value objects?

[Brian Goetz]

Indeed, many hours of discussion went into this decision.

The basic problem is that all of the obvious answers are either 
surprising or surprisingly expensive.  We considered the following four 
approaches:

1.  Allow `new WR(value)`, which is cleared on birth.
2.  Allow `new WR(value)`, which is never cleared.
3.  Allow `new WR(value)`, which is cleared when all identities 
reachable through the value are become weakly reachable.
4.  Throw, and encourage implementations that are built on WR (such as 
WHM) to offer their own ways of dealing with values.

You can readily see how (1) would not be what anyone expects.

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.

(3) is a more principled answer, but is very expensive to implement, and 
its still not clear that this is what people will expect.

(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.)

On 12/12/2025 10:02 AM, Glavo wrote:
> Hi,
>
> In the current draft of JEP 401, I saw the following statement:
>
> > The garbage collection APIs in java.lang.ref and 
> java.util.WeakHashMap do not allow developers to manually manage value 
> objects in the heap.
> > Attempts to create Reference objects for value objects throw 
> IdentityException at run time.
>
> 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.
> Obviously, doing so would break far fewer existing codes, whereas 
> having them directly throw IdentityException would break a lot more code.
>
> 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,
> Project Loom did not outright forbid users from using ThreadLocal on 
> virtual threads, yet Project Valhalla chose to break this (admittedly 
> inefficient) writing style.
>
> 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.
>
> Glavo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251212/9bf5c767/attachment-0001.htm>