[External] : Re: SoV-2: weak references

[Dan Heidinga]

> * For WeakHashMap use cases, I would expect that any attempts to actually design something "good" that does what users really "want" would end up at some different library entirely. This is something that Caffeine probably does well (disclosure, I worked on the thing that became that).
>
>
> Yes, probably.  We're worried about existing applications that are built around WHM, and trying to give them something reasonable that will keep them going, since many of these are legacy applications with limited room for rearchitecting.  So we're asking "what's the least we have to do", and the simple set of policies I outlined for WHM is a candidate.

I think Kevin's hit on the key point here - WHM as a cache is often
used incorrectly and we'd be better off designing something different
entirely to solve that use case.  This matches the feedback I've
gotten when polling Red Hat developers.

Breaking the "values as WHM keys" issue into use cases:

Single maintenance domain:
(A) Migrates its own classes to values and uses them as WHM keys
(B) Uses value-based classes as WHM keys and breaks in Valhalla when
these become values

Cross maintenance domain:
(C) Other library changes its classes to be values, our library uses
them as WHM keys
(D) Our library changes its classes to be values, Other library uses
them as WHM keys

Both (A) and (D) are very similar and are essentially a consequence of
not understanding how users (self, others) are using your classes.
This is a consequence of migrating existing classes, and just like
with synchronization, users should expect it to fail with an
exception.  Don't like the exception?  Don't migrate the class to be a
value.

Cases (B) and (C) are very similar if we treat the JDK as "another
library".  And this is probably the hardest case as it intersects with
supported JDK versions.  Running on a JDK that supports Valhalla
doesn't guarantee that all the maintenance domains were compiled on
new enough JDKs.

If the library is supported on both pre-Valhalla JDK and Valhalla-JDK,
then it can't easily take advantage of the new WHM models being
proposed. (caveats: MR jars, reflection related workarounds, ...)  And
if the domain is only on post-Valhalla JDKs, then the user is in a
place to put explicit checks for values into their code (or better,
stop using WHM all together).

 Trying to keep WHM working for values is encouraging the ecosystem to
throw good money (effort) after bad.  The "keep it working" attempts
just shift the problem from a clear exception to an on-call nightmare
when the leaking WHM causes the service to go down.  I know which I'd
prefer.

--Dan