Hello Johannes, Thank you very much for the effort! I can confirm you have spotted an issue - attached is a quick test case that verifies the problem. If the revision is null, equals() will return true if the other revision is null as well, regardless of the key's name.
Kind regards, Olaf -----Original Message----- From: Johannes Birgmeier [mailto:[email protected]] Sent: Donnerstag, 22. Januar 2015 06:56 To: [email protected] Subject: Bug acknowledgement Dear Jackrabbit/Oak developers, to keep this very short: 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 Apache Jackrabbit-Oak, in the following class: https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/UpdateOp.java in the equals method, somebody wrote: return name.equals(other.name) && revision != null ? revision.equals(other.revision) : other.revision == null; However, the ternary operator has lower precedence than "&&". Therefore, to maintain the hashCode/equals contract, this should be: return name.equals(other.name) && (revision != null ? revision.equals(other.revision) : other.revision == null); 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
