Community
Participate
Working Groups
Using this reports for CheckStyle in Sonar https://dev.eclipse.org/sonar/drilldown/violations/org.eclipse.platform:platform-aggregator?&rule=checkstyle%3Acom.puppycrawl.tools.checkstyle.checks.coding.EqualsHashCodeCheck&rule_sev=CRITICAL&severity=CRITICAL , we can see that some classes are missing a hashCode() method matching the behaviour of the equals() one. Depending on the usage of the class (inside JDT code, or even outside of JDT for classes that are exported), it can cause some performance issues. Indentified classes with this bad small * org.eclipse.jdt.apt.core.internal.type.PrimitiveTypeImpl * org.eclipse.jdt.core.tests.builder.Problem * org.eclipse.jdt.internal.core.builder.ClasspathMultiDirectory * org.eclipse.jdt.internal.compiler.apt.util.ArchiveFileObject * org.eclipse.jdt.internal.compiler.tool.ArchiveFileObject
Suggested fix: https://git.eclipse.org/r/14700
As this issue can cause bad performance, and a patch is provided, I think this can be targeted for next milestone.
Not every class that has an equals method is also stored in a hashed collection. So I just made a test using ClasspathMultiDirectory as my example: I added a stupid hashCode() method and ran all relevant tests (RunModelTests - 7255 tests) in the debugger with a breakpoint in this hashCode() method: result: 0 hits. Also, none of the listed classes are intended for use outside JDT. Do you have a candidate where a hashCode() method actually makes a difference?
This is just a generic Java rule that is IMO beyond and more important than JDT best practices. Maybe it's not used directly in JDT, and shouldn't be used out of JDT, but the fact is that there might be a current or future use-case for putting this into a HashMap or a HashSet, and in such case, not having a hashCode() is a bug.
I've abandoned my patch which was partly covered by fixed of some other bugs surfacing later (such as Bug 521438). But I think this is still all valid. It's a very bad practice to not implement hashCode when classes define an equals, and by ignoring this rule, JDT leaves a door open to performance problems later or in consumer code.
