Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom key classes for HashMap should implement Comparable [SPR-14017] #18589

Closed
spring-projects-issues opened this issue Mar 3, 2016 · 2 comments
Assignees
Labels
type: enhancement A general enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

Juergen Hoeller opened SPR-14017 and commented

According to http://www.javaspecialists.eu/archive/Issue235.html...

Since Java 8 it is VERY IMPORTANT to always make your custom keys for HashMap implement Comparable. HashMap now puts your entries into a tree to avoid degradation to O(n) when the entries map to the same bucket. It somehow needs to know the relative order of the keys. If they are strings, then comparing them is trivial. Otherwise, if the key class implements Comparable it uses the compareTo() function. If not, it will eventually use System.identityHashCode() to determine the sort order.


No further details from SPR-14017

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

All custom cache key classes within the core codebase (there aren't that many, actually) implement Comparable in a reasonably efficient way now, and also consistently provide a toString representation (primarily for debugging views).

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

Due to the rather involved nature of efficient compareTo handling and our focus on consistent toString support, it also makes more sense to reuse key classes now, rather than individual inner classes as before. As a consequence, I've introduced org.springframework.core.MethodClassKey which gets reused across our cache and transaction attribute sources now; it is basically what the transaction attribute source was using before, now identically used for our two cache attribute sources instead of the more generic AnnotatedElementKey (with a less sophisticated compareTo implementation). As a side bonus, this also reduces our dependencies on the context.expression package (where AnnotatedElementKey is defined) to places already using context.expression for other reasons.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants