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
that
this 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.
_______________________________________________
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
