A Bug in AccessControlContext.equals() and hashCode()? (original) (raw)
Frank Ding dingxmin at linux.vnet.ibm.com
Thu Jun 12 06:14:28 UTC 2014
- Previous message (by thread): RFR 7150092: NTLM authentication fail if user specified a different realm
- Next message (by thread): A Bug in AccessControlContext.equals() and hashCode()?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi Guys, Recently, we noticed that JEP-140 has altered the behavior of AccessControlContext equality and comparson semantics. To be more precisely, AccessControlContext.equals() takes fields "DomainCombiner combiner" & "ProtectionDomain[] context" and some others into consideration (both Java 7 & 8) whereas AccessControlContext.hashCode() only cares about "ProtectionDomain[] context". This is weird.
My questions are:
- Though spec doesn't require two objects with same hashcode are equal, what's the particular reason that field "DomainCombiner combiner" are used for equal() but not hashCode()?
- Is it expected that two AccessControlContext objects considered equal via method equals() should return same results for AccessControlContext.checkPermission()?
In addition, current JCK tests (both Java 7 & 8) validate AccessControlContext.hashCode() by calculating only field "ProtectionDomain[] context". Does it make sense to challenge JCK if I would like add more fields for hashCode calculation?
Your insight is appreciated.
Thanks, Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20140612/98ee5223/attachment.htm>
- Previous message (by thread): RFR 7150092: NTLM authentication fail if user specified a different realm
- Next message (by thread): A Bug in AccessControlContext.equals() and hashCode()?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]