hi johannes if you find issues in the jackrabbit code base please open jira issues at https://issues.apache.org/jira/browse/JCR
kind regards angela On 28/01/15 20:10, "Johannes Birgmeier" <[email protected]> wrote: >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 >
