Dear Jackrabbit developers,
some of you might remember my last hashCode/equals alert email from
Jackrabbit/Oak. I apologize for posting twice with similar issues if the
overlap between Oak and Jackrabbit developers is nontrivial.
I'm a new Stanford computer science PhD student working on verification.
To get started, I've written a program to verify the hashCode/equals
contract in Java. I let this run on Apache projects. In Jackrabbit, I
found bugs in two classes:
1) org.apache.jackrabbit.core.security.authorization.GlobPattern
2) org.apache.jackrabbit.core.security.principal.AdminPrincipal
=== REPORT 1 ===
In GlobPattern.java, in equals(), somebody wrote:
return nodePath.equals(other.nodePath) &&
(restriction == null) ? other.restriction == null :
restriction.equals(other.restriction);
However, the ternary operator has lower precedence than &&, and thus the
hashCode/equals contract might be violated here. What you probably want is
return nodePath.equals(other.nodePath) &&
((restriction == null) ? other.restriction == null :
restriction.equals(other.restriction));
=== REPORT 2 ===
In AdminPrincipal.java, somebody just complelely forgot about the
contract; while equals() returns:
return obj == this || obj instanceof AdminPrincipal;
, hashCode() returns
return adminId.hashCode();
, which breaks the hashCode/equals contract.
=== END REPORTS ===
Could you perhaps get back to me with a very quick acknowledgement if
you think this is sound? I'm going to send my verifier to a conference
on computer aided verification, and bug acknowledgements help a lot to
sell a paper. Thanks a lot in advance for any kind of feedback!
Best regards,
Johannes Birgmeier
