> * 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
