RFR: JDK-8013900: More warnings compiling jaxp.
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)
- 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
More information about the core-libs-dev
mailing list