Name: bsC130419 Date: 08/21/2001


java version "1.4.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta-b65)
Java HotSpot(TM) Client VM (build 1.4.0-beta-b65, mixed mode)


In JDK 1.4beta, the javadoc for java.security.Key has blithely added the
following paragraph:

All classes that implement this interface should override the
java.lang.Object.equals method.

This is vague enough that it's pretty useless. To start with, it should at
least mention the normal requirement for a hashCode() method that is
consistent with equals(). More importantly, it should explain what the
users of equals() and hashCode() can expect -- e.g. can you reasonably expect
to use Key values to index a Map/Hashtable? -- and what the implementors of
these methods need to do:

      - if I get DSAPublicKey instances from two different JCA providers
that represent the same DSA Public Key value, should they compare
equal (and hash the same?).

[It is probably unrealistic to expect the authors of all JCA providers
to get in synch on this one, so the answer is probably "no"]

      - if I have an RSAPrivateKey instance and an RSAPrivateCrtKey instance
that represent the "same" key (i.e. will produce the same answers for
RSA decryption and signing, just with different efficiency), should
they compare equal (and hash the same?)

[Normally the answer is that subclasses should not compare equal to
superclasses, but this case is a bit more grey because the distinction
is basically a performance optimization]

JDK 1.2.x and 1.3.x did not say anything about equals() for Key, so I don't see
how this can be retrofitted.

One possibility that might kinda sorta maybe almost work is to define equals()
and hashCode() on the byte[] Key.getEncoded(), with some sort of fallback for
the case where getEncoded() == null.
(Review ID: 130346)
======================================================================