New mutable hash maps no longer expose elemEquals/elemHashCode extension point

[retronym]

This is a consequence of the change to compose HashTable rather than extend it.

If this is an intentional breaking change, we should go a bit further and inline calls to elemEquals and elemHashCode with calls to == and ##.

[julienrf]

@retronym Do you recommend going back to inheritance?

[retronym]

@julienrf I sort of like the composition approach, but it isn't backwards compatible as it stands. Not sure how often this extension point is used in the wild. If we don't offer it, the workaround is for users to wrap their keys.

[szeiger]

We could offer the same methods with the same names for users to override in order to make it source compatible. In the end it comes down to performance. How expensive are calls to non-final methods in the most performance-critical sections? I'll run some benchmarks.

[szeiger]

No difference in peformance. Apparently the small hot methods always get inlined by HotSpot.

But the class is already marked @deprecatedInheritance because we want to disallow extending concrete collection implementations. Should we revert this decision or recommend wrapping the keys?

[shanielh]

I always liked .net approach to this: passing a trait that has elemHashCode and elemEquals (They called it IEqualityComparer) instead of inherit the collection type with default to ## and ==

I guess it’s too late now :-)

[retronym]

I think we should leave then final for now.

I'm surprised that the benchmark couldn't show a difference. The benchmark would need to take some care to make things realistically hard for HotSpot.