RFR: JDK-8013900: More warnings compiling jaxp. (original) (raw)

Daniel Fuchs daniel.fuchs at oracle.com
Mon May 13 14:36:40 UTC 2013

This is a fix for JDK-8013900: More warnings compiling jaxp.

<http://cr.openjdk.java.net/~dfuchs/JDK-8013900/webrev.00/>

Although the title might suggest a trivial fix, it goes a bit beyond a simple warning fix because the root cause of those warnings is that some classes redefine equals without redefining hashCode() - and devising a hashCode() method that respects its contract with equals() is not always trivial.

The proposed fix adds hashCode() methods where necessary, ensuring that:

if (o1.equals(o2) == true), then (o1.hashCode() == o2.hashCode())

The fix also contains some cosmetic/sanity changes - like:

  1. adding @Override wherever NetBeans complained they were missing - and
  2. replacing StringBuffer with StringBuilder when possible.
  3. In one instance, AbstractDateTimeDV.java I also had to reformat the whole file (due to its weird original formatting)
  1. I also removed a couple of private isEqual(obj1, obj2) methods replacing them by calls to Objects.equals(obj1, obj2) which did the same thing.
  2. finally I refactored some of the existing equals (e.g. replacing try { (Sometype) other.... } catch (ClassCastException x) { return false; } with use of 'other instanceof Sometype'...)

There are however a couple of more serious changes that could deserve to be reviewed in more details:

a. The new implementation of hashCode() in AbstractDateTimeDV.DateTimeData, where I had to figure out a way to convert the date to UTC so that the hashCode() would match equals:

AbstractDateTimeDV.java: lines 972-992

and b. in PrecisionDecimalDV.XPrecisionDecimal - where I had to invent a canonical string representation to devise a hashCode that would match equals:

PrecisionDecimalDV.java: lines 147-237

For this last one - I have added a new test in jdk/test to check the implementation of the new canonical String representation for hashCode() - since the code of that is not trivial.

best regards,

-- daniel

More information about the core-libs-dev mailing list