On 6/30/2020 7:44 PM, Stuart Marks wrote:
An unconventional patch over an unusual hashcode/equals
implementation is a bit too controversial. I'd like to propose a new
patch that focus on the problem at hand, that is re-setting the
opcode causes the item in HashSet to get lost because of th
An unconventional patch over an unusual hashcode/equals implementation is a bit
too controversial. I'd like to propose a new patch that focus on the problem at
hand, that is re-setting the opcode causes the item in HashSet to get lost
because of the changed hash bucket. This patch therefore s
Hi all,
(had a nice hike today, and asked the beautiful Lake 22 ;-))
An unconventional patch over an unusual hashcode/equals implementation
is a bit too controversial. I'd like to propose a new patch that focus
on the problem at hand, that is re-setting the opcode causes the item in
HashSet t
ckenfels ; Core-Libs-Dev
*Betreff:* Re: RFR [16/java.xml] 8248348: Regression caused by the
update to BCEL 6.0
On 6/25/2020 5:14 PM, Bernd Eckenfels wrote:
> Hello,
>
> What is the advantage of having such a narrow hashcode value space
compared to the built in idendity hashcode?
On 6/26/2020 12:46 PM, Stuart Marks wrote:
On 6/25/20 4:53 PM, Joe Wang wrote:
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
unfortuna
)
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: Joe Wang
Gesendet: Friday, June 26, 2020 8:29:41 AM
An: Bernd Eckenfels ; Core-Libs-Dev
Betreff: Re: RFR [16/java.xml] 8248348: Regression caused by the update to BCEL
6.0
On 6/25/2020 5:14 PM, Bernd Eckenfels wrote
On 6/25/20 4:53 PM, Joe Wang wrote:
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
Hi Peter,
Yes, they must agree: o1.equals(o2) => o1.hashCode() == o2.hashCode(). I
think that was the original motivation in BCEL 6.0 to add the hashCode()
method since before that, the Instruction class overrode equals() but
not hashCode(), so two Instructions that were equal had different
h
Hi Joe,
For an object to correctly function as an element of a HashSet, its
hashCode() and equals() methods must agree: o1.equals(o2) => o1.hashCode()
== o2.hashCode(). I see equals() method delegates to a global
InstructionComparator instance which can even change. Suppose it does not
change. But
ttp://bernd.eckenfels.net
Von: core-libs-dev im Auftrag von Joe Wang
Gesendet: Friday, June 26, 2020 1:53:08 AM
An: Core-Libs-Dev
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
://bernd.eckenfels.net
Von: core-libs-dev im Auftrag von Joe
Wang
Gesendet: Friday, June 26, 2020 1:53:08 AM
An: Core-Libs-Dev
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
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
12 matches
Mail list logo
