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-r...@openjdk.java.net> im Auftrag von Joe Wang <huizhe.w...@oracle.com> Gesendet: Friday, June 26, 2020 1:53:08 AM An: Core-Libs-Dev <core-libs-dev@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
