Deprecate ObjectUtils.hashCode for primitives in favor of JDK 8's hashCode methods [SPR-15395]

[spring-projects-issues]

Christoph Dreis opened SPR-15395 and commented

Hey,

just noticed that the hashCode() variants for primitive types in ObjectUtils could be using the JDK 8 calls now that we're on it.

Please find the corresponding PR attached.

Cheers,
Christoph

---

Affects: 5.0 M5

Referenced from: pull request #1368, and commits e9627a1

[spring-projects-issues]

Juergen Hoeller commented

I'm rather leaning towards deprecating those methods altogether, in favor of direct usage of the JDK 8 equivalents. Within the core framework, those methods are only really used within ObjectUtils itself anyway, except for one lonely case in the HttpRange class...

So technically, we'd still let those ObjectUtils methods delegate to the JDK 8 equivalents (as you suggest) but we'd replace all calls to our variants with direct calls to the JDK 8 methods, suggesting the same to third-party code through deprecation.

[spring-projects-issues]

Christoph Dreis commented

Also fine with that. I already had the feeling in spring-projects/spring-boot#8768 that this might be the way to go. Maybe looks a bit weird though if several types are used (like in the following example), but I guess people can (and probably should) live with that:

	@Override
	public int hashCode() {
		int hashCode = ObjectUtils.nullSafeHashCode(this.someNonPrimitive);
		hashCode = 31 * hashCode + Boolean.hashCode(this.someBoolean);
		hashCode = 31 * hashCode + Long.hashCode(this.someLong);
		hashCode = 31 * hashCode + Double.hashCode(this.someDouble);
		return hashCode;
}

[spring-projects-issues]

Juergen Hoeller commented

I guess such code could use Objects.hashCode(this.someNonPrimitive), then it would consistently rely on JDK API there.

[spring-projects-issues]

Christoph Dreis commented

Yeah, I guess so. Could eventually lead to boxing the primitives if Objects.hashCode() is used for every field, but I guess people need to be aware of that anyhow. As said, I'm fine with using the JDK ones for primitives directly :-)