[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: java.security.KeyPairGenerator oddity
From: |
Casey Marshall |
Subject: |
Re: java.security.KeyPairGenerator oddity |
Date: |
Thu, 10 Jun 2004 10:20:50 -0700 |
User-agent: |
Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) |
>>>>> "Chris" == Chris Gray <address@hidden> writes:
Chris> Looking at KeyPairGenrator I see that one of the initialize()
Chris> methods is defined as follows:
Chris> public void initialize(int keysize, SecureRandom random) {
Chris> initialize(keysize, random);
Chris> }
Chris> Either I'm missing something or this is a case of recursion:
Chris> see recursion. ;->
Chris> Sun's API docs are maddeningly vague as usual, but I _think_
Chris> that the default implementation should just throw an
Chris> UnsupportedOperationException.
Chris> BTW if anyone knows where to find a more useful description of
Chris> how this stuff is supposed to work I'd be grateful for a
Chris> pointer ...
KeyPairGenerator is one of the classes that were born broken when Sun
wrote them (MessageDigest suffers from a similar brain damage). I
think the point is that either (a) service providers write their own
`initialize' method when they extend the class, or (b) they implement
KeyPairGeneratorSpi and the getInstance method returns an "adapter"
class. See DummyKeyPairGenerator.
Throwing UnsupportedOperationException in this case sounds like a
better behavior. This is probably a case where it pays to emulate
Sun's behavior, but I don't think this will cause problems, since
service providers should extend KeyPairGeneratorSpi.
--
Casey Marshall || address@hidden