classpath
[Top][All Lists]
Advanced

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

Re: proposed plan for moving GNU Crypto to Classpath


From: Dalibor Topic
Subject: Re: proposed plan for moving GNU Crypto to Classpath
Date: Wed, 28 Dec 2005 21:19:39 +0100
User-agent: Debian Thunderbird 1.0.7 (X11/20051117)

Casey Marshall wrote:
> On Dec 27, 2005, at 8:49 AM, Raif S. Naffah wrote:
> 

> I'd prefer to keep ".in" files to a minimum. We could attain the same 
> thing by using reflection for the parts that may or may not be 
> available or are disabled at compile time.

Yes, please. I'd also like to avoid having more *.java.in files than
absolutely necessary.

>> * when classes from GNU Crypto, rely on AWT or Swing, they will be
>> re-written as templates conditioned by existing Classpath  configuration
>> option(s).
>>
> 
> Why is that needed? Aren't AWT and Swing still available, even if no 
> native peers are compiled?

Yes, they are still available. The AWTCallbackHandler may not work
properly without a peer implementation, but that should be the concern
of the person disabling the native peers. For example, the user may want
to supply their own peer implementation, instead of GNU classpath's
implementations.

> Are there any opinions about adding test suites to Classpath? It  seems
> to me like that had been abandoned in favor of an external test  suite
> (Mauve).

I'd prefer to see all tests go into Mauve. It is much easier to use than
 runtime/library specific test suites, as anyone who has tried to run
kaffe with libgcj's test suite or vice versa can confirm, I guess :)

> 
> I had put together my own proposed patch set, and sent a message  about
> it from an address that needs approval for classpath-patches  (I'm
> writing this over a slow VNC connection). It's rather simpler  than
> this, and mostly just involves renaming gnu.crypto to  gnu.javax.crypto,
> and org.metastatic.jessie to gnu.javax.net.ssl, and  adds a configure
> switch to disable compiling crypto classes (I'd  rather avoid doing a
> lot to support export control, because AFAIK  only one person needs it
> (sorry, Anthony ;-) and it is more  infrastructure to maintain). It may
> make sense to "bifurcate" GNU  Crypto into "weak" and "strong"
> eventually, however.
> 
> The patch is at <http://metastatic.org/source/gnu-crypto- jessie.patch>
> and a tarball of new files at <http://metastatic.org/
> source/gnu-crypto-jesise.tar.gz>.
> 

Thanks, Casey!

cheers,
dalibor topic




reply via email to

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