<p>In my recent endeavor to learn Scala, reading the Scala book by Martin Odersky et al. I remember being struck by the emphasis placed by the authors on the difficulty of properly overriding the <code>equals</code> and <code>hashCode</code> methods of our user-defined types. In particular, I remember that failing to define <code>equals</code> and <code>hashCode</code> consistently may lead to subtle bugs in code which handle hash-maps and dictionaries. Now the <code>ECKey</code> class of <code>bitcoinj</code> seems to suffer from such inconsistency. I was wondering if anyone knew the background to this, whether this is an oversight or a deliberate choice, or if there is a fundamental reason why equality between keys should take creation time into account (for example) while <code>hashCode</code> should ignore it. Am I being pedantic or should <code>equals</code> and <code>hashCode</code> be consistent?</p>

<pre><code>import org.bitcoinj.core.ECKey;

public class Test {

  public static void main(String[] args){

  // random compressed key
  ECKey k1 = new ECKey(); 

  // same key, but creation time is different
  ECKey k2 = ECKey.fromPrivate(k1.getPrivKey());

  // The two keys are deemed different, due to creation time
  System.out.println(k1.equals(k2));  // false

  // yet hashCode ignores time of creation
  System.out.println(k1.hashCode() == k2.hashCode()); // true

  }
}
</code></pre>

CC BY-SA 3.0
2016-08-21T16:11:33.070Z
This is a side note, but if you are interested in Scala & bitcoin feel free to look at / contribute to bitcoin-s https://github.com/bitcoin-s/bitcoin-s-core . We are trying to fix some of the warts bitcoinj has such as what you mentioned above
Chris Stewart
CC BY-SA 3.0
2016-08-21T16:57:34.503Z
Thank you Chris, yes I am definitely interested in a Scala bitcoin library. I am still in a learning phase, but I will definitely look at this.
Sven Williamson
<bitcoinj>
Java bitcoinj: ECKey hashCode() and equals() overrides inconsistent
Sven Williamson
# Java bitcoinj: ECKey hashCode() and equals() overrides inconsistent

(Asked by: username_0 on 2016-08-21)

In my recent endeavor to learn Scala, reading the Scala book by Martin Odersky et al. I remember being struck by the emphasis placed by the authors on the difficulty of properly overriding the equals and hashCode methods of our user-defined types. In particular, I remember that failing to define equals and hashCode consistently may lead to subtle bugs in code which handle hash-maps and dictionaries. Now the ECKey class of bitcoinj seems to suffer from such inconsistency. I was wondering if anyone knew the background to this, whether this is an oversight or a deliberate choice, or if there is a fundamental reason why equality between keys should take creation time into account (for example) while hashCode should ignore it. Am I being pedantic or should equals and hashCode be consistent?
import org.bitcoinj.core.ECKey;

public class Test {

  public static void main(String[] args){

  // random compressed key
  ECKey k1 = new ECKey(); 

  // same key, but creation time is different
  ECKey k2 = ECKey.fromPrivate(k1.getPrivKey());

  // The two keys are deemed different, due to creation time
  System.out.println(k1.equals(k2));  // false

  // yet hashCode ignores time of creation
  System.out.println(k1.hashCode() == k2.hashCode()); // true

  }
}

**Tags:** bitcoinj

> **Comments:**
> **username_1**: This is a side note, but if you are interested in Scala & bitcoin feel free to look at / contribute to bitcoin-s https://github.com/bitcoin-s/bitcoin-s-core . We are trying to fix some of the warts bitcoinj has such as what you mentioned above  
> **username_0**: Thank you Chris, yes I am definitely interested in a Scala bitcoin library. I am still in a learning phase, but I will definitely look at this.  

---

## 0 answers

