|
View:
New views
6 Messages
—
Rating Filter:
Alert me
|
|
|
Proposal for restructuring JuiCE files - and some new functionsAll,
after some tests and discussions with the BC guys a first step of the Elliptic Curve (EC) functions is available: - key generation for various key lengths according to X9.62 - EC DSA with SHA1 During the interop tests we got some problems with older versions of BC. Thus to interop with BC you have to use version 1.31 (or greater). While looking at EC and some other security stuff it became clear that a restructuring of the JuiCE files will be necessary. The Java versions 1.3, 1.4, and 1.5 (aka Java 5.0) each provide several enhancements of security both in java.security.* and javax.crypto.* that are _not_ compatible and/or fully upward compatible. To overcome this problem we should introduce a structure similar to BC (similiar problems lead to similar solutions :-) ) Currently we have: JuiCE/java/src/org/... and the classes stored in JuiCE/build/classes/... I propose the following structure: Juice/java/common/src/... the Java source files Juice/java/common/build/classes/... the class files Juice/java/common/build/... other files, dirs, (resources, etc) Juice/java/common/test/... test cases Juice/java/jdk14/src/... Juice/java/jdk14/build/classes/... the class files Juice/java/jdk14/build/... other files (resources, etc) Juice/java/jdk14/test/... test cases Juice/java/java5/src/... Juice/java/java5/build/classes/... the class files Juice/java/java5/build/... other files (resources, etc) Juice/java/java5/test/... test cases Such a structure would also support an Eclipse setup defining common, jdk14, java5, ... as single projects that have dependencies. This is somehow similar to the Axis2 setup with its modules (in our case the modules are "common", "jdk14", "java5", ...). The distribution would then combine "common" and one of the Java version dependent module to build a JuiCE jar. The names of the JuiCE jars would be: juice-jdk14-0.9.jar juice-java5-0.9.jar where 0.9 would be a current JuiCE version number. I don't see any problems for the native code. It would always be a superset of functions required by the various Java JCE classes. Any thoughts, ideas? Regards, Werner --------------------------------------------------------------------- To unsubscribe, e-mail: juice-dev-unsubscribe@... For additional commands, e-mail: juice-dev-help@... |
|
|
Re: Proposal for restructuring JuiCE files - and some new functions+1 from me.
On 3/20/06, Dittmann, Werner <werner.dittmann@...> wrote: > All, > > after some tests and discussions with the BC guys a first step > of the Elliptic Curve (EC) functions is available: > > - key generation for various key lengths according to X9.62 > - EC DSA with SHA1 > > During the interop tests we got some problems with older versions > of BC. Thus to interop with BC you have to use version 1.31 (or > greater). > > While looking at EC and some other security stuff it became clear > that a restructuring of the JuiCE files will be necessary. The > Java versions 1.3, 1.4, and 1.5 (aka Java 5.0) each provide several > enhancements of security both in java.security.* and javax.crypto.* > that are _not_ compatible and/or fully upward compatible. To overcome > this problem we should introduce a structure similar to BC (similiar > problems lead to similar solutions :-) ) > > Currently we have: > > JuiCE/java/src/org/... > and the classes stored in > JuiCE/build/classes/... > > I propose the following structure: > > Juice/java/common/src/... the Java source files > Juice/java/common/build/classes/... the class files > Juice/java/common/build/... other files, dirs, (resources, > etc) > Juice/java/common/test/... test cases > > Juice/java/jdk14/src/... > Juice/java/jdk14/build/classes/... the class files > Juice/java/jdk14/build/... other files (resources, etc) > Juice/java/jdk14/test/... test cases > > Juice/java/java5/src/... > Juice/java/java5/build/classes/... the class files > Juice/java/java5/build/... other files (resources, etc) > Juice/java/java5/test/... test cases > > Such a structure would also support an Eclipse setup defining common, > jdk14, > java5, ... as single projects that have dependencies. This is somehow > similar to the Axis2 setup with its modules (in our case the modules are > "common", "jdk14", "java5", ...). > > The distribution would then combine "common" and one of the Java version > dependent module to build a JuiCE jar. The names of the JuiCE jars would > be: > > juice-jdk14-0.9.jar > juice-java5-0.9.jar > > where 0.9 would be a current JuiCE version number. > > I don't see any problems for the native code. It would always be a > superset > of functions required by the various Java JCE classes. > > Any thoughts, ideas? > > Regards, > Werner > > --------------------------------------------------------------------- > To unsubscribe, e-mail: juice-dev-unsubscribe@... > For additional commands, e-mail: juice-dev-help@... > > -- Davanum Srinivas : http://wso2.com/blogs/ --------------------------------------------------------------------- To unsubscribe, e-mail: juice-dev-unsubscribe@... For additional commands, e-mail: juice-dev-help@... |
|
|
Re: Proposal for restructuring JuiCE files - and some new functions+1 for me also,
I want to play with NIO buffers... Regards, And keep the good job... Raul On 3/20/06, Davanum Srinivas <davanum@...> wrote: > +1 from me. > > On 3/20/06, Dittmann, Werner <werner.dittmann@...> wrote: > > All, > > > > after some tests and discussions with the BC guys a first step > > of the Elliptic Curve (EC) functions is available: > > > > - key generation for various key lengths according to X9.62 > > - EC DSA with SHA1 > > > > During the interop tests we got some problems with older versions > > of BC. Thus to interop with BC you have to use version 1.31 (or > > greater). > > > > While looking at EC and some other security stuff it became clear > > that a restructuring of the JuiCE files will be necessary. The > > Java versions 1.3, 1.4, and 1.5 (aka Java 5.0) each provide several > > enhancements of security both in java.security.* and javax.crypto.* > > that are _not_ compatible and/or fully upward compatible. To overcome > > this problem we should introduce a structure similar to BC (similiar > > problems lead to similar solutions :-) ) > > > > Currently we have: > > > > JuiCE/java/src/org/... > > and the classes stored in > > JuiCE/build/classes/... > > > > I propose the following structure: > > > > Juice/java/common/src/... the Java source files > > Juice/java/common/build/classes/... the class files > > Juice/java/common/build/... other files, dirs, (resources, > > etc) > > Juice/java/common/test/... test cases > > > > Juice/java/jdk14/src/... > > Juice/java/jdk14/build/classes/... the class files > > Juice/java/jdk14/build/... other files (resources, etc) > > Juice/java/jdk14/test/... test cases > > > > Juice/java/java5/src/... > > Juice/java/java5/build/classes/... the class files > > Juice/java/java5/build/... other files (resources, etc) > > Juice/java/java5/test/... test cases > > > > Such a structure would also support an Eclipse setup defining common, > > jdk14, > > java5, ... as single projects that have dependencies. This is somehow > > similar to the Axis2 setup with its modules (in our case the modules are > > "common", "jdk14", "java5", ...). > > > > The distribution would then combine "common" and one of the Java version > > dependent module to build a JuiCE jar. The names of the JuiCE jars would > > be: > > > > juice-jdk14-0.9.jar > > juice-java5-0.9.jar > > > > where 0.9 would be a current JuiCE version number. > > > > I don't see any problems for the native code. It would always be a > > superset > > of functions required by the various Java JCE classes. > > > > Any thoughts, ideas? > > > > Regards, > > Werner > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: juice-dev-unsubscribe@... > > For additional commands, e-mail: juice-dev-help@... > > > > > > > -- > Davanum Srinivas : http://wso2.com/blogs/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: juice-dev-unsubscribe@... > For additional commands, e-mail: juice-dev-help@... > > -- http://r-bg.com --------------------------------------------------------------------- To unsubscribe, e-mail: juice-dev-unsubscribe@... For additional commands, e-mail: juice-dev-help@... |
|
|
Re: Proposal for restructuring JuiCE files - and some new functions+1. I really must get onto the Project files. I've been trying to tie
up some stuff on the xml-security library. Cheers, Berin Dittmann, Werner wrote: > All, > > after some tests and discussions with the BC guys a first step > of the Elliptic Curve (EC) functions is available: > > - key generation for various key lengths according to X9.62 > - EC DSA with SHA1 > > During the interop tests we got some problems with older versions > of BC. Thus to interop with BC you have to use version 1.31 (or > greater). > > While looking at EC and some other security stuff it became clear > that a restructuring of the JuiCE files will be necessary. The > Java versions 1.3, 1.4, and 1.5 (aka Java 5.0) each provide several > enhancements of security both in java.security.* and javax.crypto.* > that are _not_ compatible and/or fully upward compatible. To overcome > this problem we should introduce a structure similar to BC (similiar > problems lead to similar solutions :-) ) > > Currently we have: > > JuiCE/java/src/org/... > and the classes stored in > JuiCE/build/classes/... > > I propose the following structure: > > Juice/java/common/src/... the Java source files > Juice/java/common/build/classes/... the class files > Juice/java/common/build/... other files, dirs, (resources, > etc) > Juice/java/common/test/... test cases > > Juice/java/jdk14/src/... > Juice/java/jdk14/build/classes/... the class files > Juice/java/jdk14/build/... other files (resources, etc) > Juice/java/jdk14/test/... test cases > > Juice/java/java5/src/... > Juice/java/java5/build/classes/... the class files > Juice/java/java5/build/... other files (resources, etc) > Juice/java/java5/test/... test cases > > Such a structure would also support an Eclipse setup defining common, > jdk14, > java5, ... as single projects that have dependencies. This is somehow > similar to the Axis2 setup with its modules (in our case the modules are > "common", "jdk14", "java5", ...). > > The distribution would then combine "common" and one of the Java version > dependent module to build a JuiCE jar. The names of the JuiCE jars would > be: > > juice-jdk14-0.9.jar > juice-java5-0.9.jar > > where 0.9 would be a current JuiCE version number. > > I don't see any problems for the native code. It would always be a > superset > of functions required by the various Java JCE classes. > > Any thoughts, ideas? > > Regards, > Werner > > --------------------------------------------------------------------- > To unsubscribe, e-mail: juice-dev-unsubscribe@... > For additional commands, e-mail: juice-dev-help@... > > > --------------------------------------------------------------------- To unsubscribe, e-mail: juice-dev-unsubscribe@... For additional commands, e-mail: juice-dev-help@... |
|
|
|
|
|
Re: AW: Proposal for restructuring JuiCE files - and some new functionsHmm. What fun! I've never played around with Windows installers.
Might be interesting. Bags that bit :>. cheers, Berin Dittmann, Werner wrote: > Berin, > > don't worry too much :-). I've tried to keep the C files > clean and without compiler warning even in Visual C > (maybe not always the newest ... ) . > > Once we are somehow convinced we can have a first alpha > or beta we need to think about to package the Windows > native library (installer?) > > Regards, > Werner > > >>-----Ursprüngliche Nachricht----- >>Von: Berin Lautenbach [mailto:berin@...] >>Gesendet: Dienstag, 21. März 2006 09:17 >>An: juice-dev@... >>Betreff: Re: Proposal for restructuring JuiCE files - and >>some new functions >> >>+1. I really must get onto the Project files. I've been >>trying to tie >>up some stuff on the xml-security library. >> >>Cheers, >> Berin >> >>Dittmann, Werner wrote: >> >>>All, >>> >>>after some tests and discussions with the BC guys a first step >>>of the Elliptic Curve (EC) functions is available: >>> >>>- key generation for various key lengths according to X9.62 >>>- EC DSA with SHA1 >>> >>>During the interop tests we got some problems with older versions >>>of BC. Thus to interop with BC you have to use version 1.31 (or >>>greater). >>> >>>While looking at EC and some other security stuff it became clear >>>that a restructuring of the JuiCE files will be necessary. The >>>Java versions 1.3, 1.4, and 1.5 (aka Java 5.0) each provide several >>>enhancements of security both in java.security.* and javax.crypto.* >>>that are _not_ compatible and/or fully upward compatible. >> >>To overcome >> >>>this problem we should introduce a structure similar to BC (similiar >>>problems lead to similar solutions :-) ) >>> >>>Currently we have: >>> >>>JuiCE/java/src/org/... >>> and the classes stored in >>>JuiCE/build/classes/... >>> >>>I propose the following structure: >>> >>>Juice/java/common/src/... the Java source files >>>Juice/java/common/build/classes/... the class files >>>Juice/java/common/build/... other files, dirs, (resources, >>>etc) >>>Juice/java/common/test/... test cases >>> >>>Juice/java/jdk14/src/... >>>Juice/java/jdk14/build/classes/... the class files >>>Juice/java/jdk14/build/... other files (resources, etc) >>>Juice/java/jdk14/test/... test cases >>> >>>Juice/java/java5/src/... >>>Juice/java/java5/build/classes/... the class files >>>Juice/java/java5/build/... other files (resources, etc) >>>Juice/java/java5/test/... test cases >>> >>>Such a structure would also support an Eclipse setup >> >>defining common, >> >>>jdk14, >>>java5, ... as single projects that have dependencies. This >> >>is somehow >> >>>similar to the Axis2 setup with its modules (in our case >> >>the modules are >> >>>"common", "jdk14", "java5", ...). >>> >>>The distribution would then combine "common" and one of the >> >>Java version >> >>>dependent module to build a JuiCE jar. The names of the >> >>JuiCE jars would >> >>>be: >>> >>>juice-jdk14-0.9.jar >>>juice-java5-0.9.jar >>> >>>where 0.9 would be a current JuiCE version number. >>> >>>I don't see any problems for the native code. It would always be a >>>superset >>>of functions required by the various Java JCE classes. >>> >>>Any thoughts, ideas? >>> >>>Regards, >>>Werner >>> >>> >> >>--------------------------------------------------------------------- >> >>>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>For additional commands, e-mail: juice-dev-help@... >>> >>> >>> >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>For additional commands, e-mail: juice-dev-help@... >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: juice-dev-unsubscribe@... > For additional commands, e-mail: juice-dev-help@... > > > --------------------------------------------------------------------- To unsubscribe, e-mail: juice-dev-unsubscribe@... For additional commands, e-mail: juice-dev-help@... |
| Free embeddable forum powered by Nabble | Forum Help |