RFR [16/java.xml] 8248348: Regression caused by the update to BCEL 6.0

[Bernd Eckenfels]

Hello,

What is the advantage of having such a narrow hashcode value space compared to the built in idendity hashcode? Would stocking to the object idendity not only reduce the footprint, but also make hash lookups faster? Without the unclear relationship to the op code?

Gruss
Bernd


--
http://bernd.eckenfels.net
________________________________
Von: core-libs-dev <core-libs-dev-retn at openjdk.java.net> im Auftrag von Joe Wang <huizhe.wang at oracle.com>
Gesendet: Friday, June 26, 2020 1:53:08 AM
An: Core-Libs-Dev <core-libs-dev at openjdk.java.net>
Betreff: RFR [16/java.xml] 8248348: Regression caused by the update to BCEL 6.0

Hi,

Please review a fix to a BCEL regression. At issue was the addition of
hashCode() method to Instruction.java in BCEL 6.0. This hashCode()
method was implemented to return the instruction's opcode that
unfortunately is mutable. The problem hasn't showed up until the code
path led to calls to remove from a HashSet a target that has been
changed since it was added to the HashSet. The proposed patch is to make
the hashCode final/immutable.

This patch implies that a target object is considered the same one even
if its field values may have been changed. It therefore may not be
appropriate in other situations (or may cause problems). However, since
it had always had no hashCode() override before BCEL 6.0, thereby
relying on Object's identity hash code, its use case has been limited
and time-tested. It can benefit from this patch in that it provides the
same function as Object's hash code, and then serves as a reminder (to
any who might read the code) how it was used (objects considered to be
the same over the course as far as the hashCode is concerned).

JBS: https://bugs.openjdk.java.net/browse/JDK-8248348
webrevs: http://cr.openjdk.java.net/~joehw/jdk16/8248348/webrev/

Thanks,
Joe