Proposal for restructuring JuiCE files - and some new functions

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal for restructuring JuiCE files - and some new functions

Dittmann, Werner
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Proposal for restructuring JuiCE files - and some new functions

dims
+1 from me.

On 3/20/06, Dittmann, Werner <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Davanum Srinivas : http://wso2.com/blogs/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Proposal for restructuring JuiCE files - and some new functions

Raul Benito-2
+1 for me also,
I want to play with NIO buffers...

Regards,
And keep the good job...

Raul

On 3/20/06, Davanum Srinivas <[hidden email]> wrote:

> +1 from me.
>
> On 3/20/06, Dittmann, Werner <[hidden email]> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> --
> Davanum Srinivas : http://wso2.com/blogs/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
http://r-bg.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Proposal for restructuring JuiCE files - and some new functions

Berin Lautenbach
In reply to this post by Dittmann, Werner
+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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

AW: Proposal for restructuring JuiCE files - and some new functions

Dittmann, Werner
In reply to this post by Dittmann, Werner
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:[hidden email]]
> Gesendet: Dienstag, 21. März 2006 09:17
> An: [hidden email]
> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: AW: Proposal for restructuring JuiCE files - and some new functions

Berin Lautenbach
Hmm.  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:[hidden email]]
>>Gesendet: Dienstag, 21. März 2006 09:17
>>An: [hidden email]
>>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: [hidden email]
>>>For additional commands, e-mail: [hidden email]
>>>
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [hidden email]
>>For additional commands, e-mail: [hidden email]
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]