This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 253612 - Provide hint for missing hashCode/equals of Map keys
Summary: Provide hint for missing hashCode/equals of Map keys
Status: NEW
Alias: None
Product: java
Classification: Unclassified
Component: Hints (show other bugs)
Version: 8.1
Hardware: PC Windows 8 x64
: P3 normal (vote)
Assignee: Svata Dedic
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-07-21 11:00 UTC by pieterpaul
Modified: 2015-10-02 14:31 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description pieterpaul 2015-07-21 11:00:03 UTC
Feature suggestion:

Using an object as a key in a (Hash)Map that has no hashCode/equals method can lead to bugs that are hard to find. What would happen is that if two objects are created that should be equal (such as some custom index or identifier type), they will not refer to the same value in the Map because Object.equals checks for object identity. Such bugs can be hard to find because simple unit tests (that reuse key objects) will not find them.

If Netbeans would give a hint that a class that derives its equals/hashCode methods from Object is used as a Map key, such bugs would be discovered much more easily. If this hint is shown at the declaration of the Map type it will not lead to many extra hints even if the user intends to use a class as key that does not define hashCode/equals.

Possible disadvantages/caveats:

1. Users intend to use such a class as key. I am not sure how common this scenario is, but I think it's already possible to suppress warnings for that declaration? In any case, for many inexperienced programmers it would be wise to advise them of the 'danger' of the construct anyway.

2. Users use a class as map key that itself does not implement hashCode/equals, but only actually use subtypes that do. This scenario seems unlikely to me.

I cannot think of other disadvantages to which this
Comment 1 Svata Dedic 2015-10-02 14:31:29 UTC
I can - performance :)
If implemented, the hint should respect @SuppressWarning on the type-parametrized Map declaration or the key type and offer a fix to suppress itself on these places (not just for a method). Annotating variable/field decl with the @SuppressWarning should indicate the programmer is aware of that.