Fix DateFormatSymbols.equals()/.hashCode()

DateFormatSymbols was always calculating/loading zoneStrings in its
equals() and hashCode() methods, even when in most cases it wasn't
needed.

Additionally .hashCode() depended only on the values for the first
timezone in zoneNames, which is a poor indicator of similarity (see the
order of field comparisons in equals() for a more useful approach).

hashCode() has been modified to be in sync with the current OpenJDK 8
implementation, as there was no obvious reason to divert from it (we
now cache the calculated hashCode and reset it when necessary).

The only deviation from the OpenJDK code is that the zone strings are
not included in the hashCode() to avoid populating it in the majority
of cases where they are not needed and that equals() tries to avoid
populating them when it knows it to be unnecessary.

This is in preparation of a future commit that should remove the use of
zoneStrings except in cases where user code explicitly sets them with
setZoneStrings().

Note that despite this work, DateFormatSymbols is still not a good
candidate for use as a key in a Map, as it is mutable.

Test: vogar libcore/luni/src/test/java/libcore/java/text/DateFormatSymbolsTest.java
Bug: 20879084
Change-Id: I7f8adc48a21ec394cef5488dd9231807be4f0a4d

0 files changed, 0 insertions, 0 deletions