You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Johannes Birgmeier <jb...@stanford.edu> on 2015/01/22 06:55:46 UTC
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
RE: Bug acknowledgement
Posted by Olaf Otto <ol...@unic.com>.
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:jbirgmei@stanford.edu]
Sent: Donnerstag, 22. Januar 2015 06:56
To: oak-dev@jackrabbit.apache.org
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
Re: Bug acknowledgement
Posted by Johannes Birgmeier <jb...@stanford.edu>.
Marcel & Olaf, thank you very much for confirming!
Johannes
On 01/22/15 02:16, Marcel Reutegger wrote:
> Hi,
>
> thanks for reporting this. There is indeed a problem with the
> equals implementation. I created an issue:
> https://issues.apache.org/jira/browse/OAK-2435
>
> Regards
> Marcel
>
> On 22/01/15 06:55, "Johannes Birgmeier" <jb...@stanford.edu> wrote:
>
>> 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
>>
>
Re: Bug acknowledgement
Posted by Marcel Reutegger <mr...@adobe.com>.
Hi,
thanks for reporting this. There is indeed a problem with the
equals implementation. I created an issue:
https://issues.apache.org/jira/browse/OAK-2435
Regards
Marcel
On 22/01/15 06:55, "Johannes Birgmeier" <jb...@stanford.edu> wrote:
>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
>