classpath-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [cp-patches] GNU Crypto and Jessie merge


From: Raif S. Naffah
Subject: Re: [cp-patches] GNU Crypto and Jessie merge
Date: Sat, 7 Jan 2006 13:24:24 +1100
User-agent: KMail/1.9.1

On Saturday 07 January 2006 12:58, Casey Marshall wrote:
> 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.

fair enough.


> 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.

being internal to Classpath, i don't think portability is an issue. 
let's stick with what we have so far: (1) strong and weak hierarchies 
and their factories, and (2) use those internally to Classpath.


cheers;
rsn

Attachment: pgpMvF25ECjeZ.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]