The typical implementation of the `equals` method for a class, test for object identity using the `== operator` and then compares the state with the other object's state.
In a very small fraction of the comparisons, the other object has the same identity and there is some benefit to the extra `==` comparison. The rest of the time that identity comparison is wasted effort.
This enhancement proposes to drop the un-beneficial use of `==` when followed by calling `equals`.
The `java.util.Objects.equals` utility for comparing two objects, uses the same pattern, testing for identity before delegating to the object's `equals` method. There is even less benefit in this case, since many implementations of `equals` also use `==` as the first condition. The redundant identity comparison should be reduced.
The Valhalla project tested this premise and did not see a performance regression as a result of removing the identity comparison from `Objects.equals`.
In a very small fraction of the comparisons, the other object has the same identity and there is some benefit to the extra `==` comparison. The rest of the time that identity comparison is wasted effort.
This enhancement proposes to drop the un-beneficial use of `==` when followed by calling `equals`.
The `java.util.Objects.equals` utility for comparing two objects, uses the same pattern, testing for identity before delegating to the object's `equals` method. There is even less benefit in this case, since many implementations of `equals` also use `==` as the first condition. The redundant identity comparison should be reduced.
The Valhalla project tested this premise and did not see a performance regression as a result of removing the identity comparison from `Objects.equals`.
- relates to
-
JDK-8366043 [lworld] (LIFE = Legacy Idiom For Equality) causes performance regressions
-
- Open
-
-
JDK-8366214 [lworld] Use Objects.equals in HashMap and ConcurrentHashmap
-
- Resolved
-
-
JDK-8366841 [lworld] Objects.equals without identity comparison
-
- Resolved
-