Really? You envision that the majority of Cipher users would want to pass a Key in for every invocation?
If we're talking about simplicity, then I don't think that is the case. I think that the large majority of users of a Cipher would want this to happen: 1. Choose an algorithm implementation 2. Set their key somewhere (once) 3. call encrypt/decrypt whenever they feel like it on that instance. Of course, under the hood, the encryption/decryption operation is stateless because the JDK API is written that way, but the 'state' held in the implementation would be the key only, and then we pass it to the JDK API for each call. I'm assuming there would be a much smaller percentage of Cipher end-users that actually want to specify the key each time. In fact, I think it would be an extremely rare case that most Cipher end-users of the world would ever do that. Every encryption-enabled application I've ever come across usually stores this stuff (public key, etc) in file that is read once at startup, or more often (unfortunately), as constants in a Java class. This means, from my own gathering of course, that most people want to 'set and forget' this stuff. If you're configuring a Cipher instance in a DI framework, I think it would make much more sense to set the key as a property for the large majority of end users. You don't feel the same? On Thu, Dec 11, 2008 at 12:04 PM, Jeremy Haile <[EMAIL PROTECTED]> wrote: > I always found the storing of the key inside of the cipher object to feel > strange. I guess Cipher's just "feel" stateless to me. So - having two > interfaces for this feels like it'd be more confusing to a new user and > over-engineering. > > If anything, seems like the default implementation should be stateless with > a subclass that is stateful - not the reverse. It feels more natural to > have a Cipher interface with a subinterface called StatefulCipher or > KeyStoringCipher rather than the other way around. > > Just my opinion... > > > On Dec 11, 2008, at 11:57 AM, Les Hazlewood wrote: > >> I just created this issue: https://issues.apache.org/jira/browse/JSEC-36 >> >> Any objections? Thoughts? > >
