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) - apologies for the noise it causes in the webrev. 4. 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. 5. 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
