|
From: | Casey Marshall |
Subject: | Re: [cp-patches] GNU Crypto and Jessie merge |
Date: | Fri, 6 Jan 2006 17:58:33 -0800 |
On Jan 6, 2006, at 5:41 PM, Raif S. Naffah wrote:
On Saturday 07 January 2006 11:32, Casey Marshall wrote:You have to do that if you want to present a unified factory interface to (e.g.) all PRNG implementations. But we don't have to do that, here, because there already is a unified factory for PRNGs: java.security.SecureRandom, and that's the one that makes sense for Classpath. The weak provider queries the weak PRNG factory, and the strong provider queries the strong factory.i was under the impression that it would be desirable to have that behind the JCE facade so that internally to Classpath, all crypto-related classes can get what they need without using the JCE mechanism.
Yes, it would be nice to have Classpath's crypto internals (based on GNU Crypto and Jessie) had a decent API for maintainers to use, but it's something I'm willing to sacrifice to more cleanly split weak/ strong crypto packages. I'm saying that since this API is internal, it is OK if it's a little rough in places.
HOWEVER, if we write all Classpath-internal classes to use the JCE whenever possible, the code is a lot more portable, and won't depend on any specific crypto implementation.
I'm talking about GNU-Crypto-in-Classpath, though, so why does a Factory make sense in that context? It seems to me like it's little more than an additional level of indirection (security-getInstance -> wrapper -> factory-getInstance -> class, instead of security- getInstance -> wrapper -> class).is not that what the current JCE Adapters do, or are you suggesting thatthis will change?
I'm saying that the `Factory.getInstance' call is another method call, which isn't strictly necessary. That is, when I need a cipher in an adapter (or anywhere else), if I do
new CipherClass(); instead of Factory.getInstance ("Cipher");I'm saving a method call. Nothing more, since the factory's `getInstance' is itself just calling the constructor (it also calls the `selfTest' method for the algorithm, but I'm less convinced of the utility of that).
This is headed to bikeshed-territory, and this particular issue isn't that big a concern for me.
Thanks.
[Prev in Thread] | Current Thread | [Next in Thread] |