[Top][All Lists]

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

Re: [GNU Crypto] RFC: merging GNU Crypto and Jessie

From: Casey Marshall
Subject: Re: [GNU Crypto] RFC: merging GNU Crypto and Jessie
Date: Wed, 7 Dec 2005 13:21:48 -0800

On Dec 6, 2005, at 11:57 PM, Raif S. Naffah wrote:

On Wednesday 07 December 2005 04:49, Casey Marshall wrote:
On Dec 6, 2005, at 1:14 AM, Raif S. Naffah wrote:
On Tuesday 06 December 2005 18:42, Casey Marshall wrote:
A few of us have been throwing around the idea of merging GNU
Crypto and Jessie into GNU Classpath, so Classpath will have full
support for crypto and SSL "out of the box." We've proposed this
before, and I think this idea was mostly approved by the group,
but no-one ever got around to doing it.

I'd like to propose again that we do this. I'll try to get to this
myself, but if I can't get this done, we'll at least have a plan
of action. I propose that we

   - Rename the root package 'gnu.crypto' to 'gnu.javax.crypto' in
GNU Crypto, and merge the current CVS sources into Classpath (not
under external/). We then put GNU Crypto into a kind of "stasis"
mode, and continue to develop these sources in Classpath.
   - Rename the root package 'org.metastatic.jessie' to
'' in Jessie, and merge the current sources.
Then, I'll stop developing that branch on its own.

does this mean that Classpath's crypto classes will be using the
GNU Crypto "assembly, cipher, hash, key, mac, mode, pad, prng and
"sig" sub-packages with the "jce" wrappers?

Basically yes. The goal is to merge "everything with a JCE wrapper,"
because that will fill in many algorithms present in proprietary VMs,
but currently missing in Classpath.

cool.  i can help with this task  --can spend ~2hrs/day on this until
it's done.

Great! School's out for me right now, so I have my weekends back :-)

Things without JCE wrappers don't really make sense for Classpath,
because they aren't portably accessible.

dont know exactly what you mean by this but i'll have a closer look at
the Classpath classes; it may become evident then.

By this I mean that if something can't be used through J2SE classes, then it probably shouldn't be merged, because otherwise we'd be introducing private, non-portable APIs into Classpath. Exceptions are things we know we'll need to use privately (e.g., if Jessie needs it).

The assembly package is a good example: it's a neat, advanced API, but doesn't have any analogue in the J2SE spec.


reply via email to

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