Re: Contributions of work on Jikes RVM with GNU Classpath
Hi, On Fri, 2002-12-13 at 15:35, John Leuner wrote: > Some questions about the other patches to Classpath: > > 1. The patches to VMSystem and System > > http://savannah.gnu.org/patch/?func=detailpatch&patch_id=720&group_id=85 > > In the old code, System.in, out and err were constructed automatically, > but the proposed patch would leave it up to the VM to initialise these. > > How about we add a hook in the System static initializer to call > something like VMSystem.makeStandardStreams() ? > > The downside of this is that VMs that didn't bother with setting these > streams before, would now have to implement methods to do so. But we would provide a standard implementation that just does what the original code does, so when upgrading your VM to the new Classpath version you would automatically get the old behaviour back. But why exactly does a VM need this? A better approach seems to be to abstract java.io.FileDescriptor.in/out/err for the VM. This is the approach that libgcj takes. > 2. To run JRVM with GNU Classpath the native methods in java/io/File, > FileDescriptor, FileInputStream etc have to be replaced with calls to > the JRVM support library. > > How are we going to do this? Before we were thinking of doing > preprocessing of the Classpath java/io/*.java source with JRVM-glue code > being controlled by a compile-time option. > > Is there another way to get around this? I would like to take the same approach as we are doing (or going to do) for the VM glue classes in java.lang (e.g. Throwable and VMThrowable). For every class that contains native methods rewrite them so they call a Helper/State class. But unlike the VM glue classes GNU Classpath comes with a standard JNI based implementation of these Helper/State classes for GNU or POSIX based machines but VMs like libgcj (CNI), IK.VM.NET (Managed C++) or JRVM (Java) can provide a different implementation. It would be a small overhead, but by defining these classes as package private and final VMs should be able to optimize these extra calls away. There are about 20 classes (excluding awt and nio which might need another aproach) that might need to be rewritten this way. Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Contributions of work on Jikes RVM with GNU Classpath
> "John" == John Leuner <[EMAIL PROTECTED]> writes: John> How did you run Eclipse? I assume you were using OTI or Sun awt John> and swing classes? Eclipse comes with its own GUI toolkit called SWT. If you download eclipse you can try it with your VM by just running "eclipse -vm ". Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
GNU Classpath, gcj and Crypto update
Hi all,
Here is a small update on the progress of the security and crypto
classes.
After discussing this a little bit off list with the GNU Crypto,
Classpath and libgcj maintainers we decided to work towards the
following situation:
- GNU Classpath provides a java.security framework and the basic
algorithms needed to implement the core libraries (only MD5/SHA Message
Digests, DSA KeyPairGenerator, SHAwithDSA Signature and a basic
SecureRandom and KeyStore implementation). Everything that is not needed
to implement the core libraries would be pushed into GNU Crypto.
- The GNU Crypto package comes with crypto algorithms and a JCA/JCE
wrapper/provider (build produces gnu-crypto.jar and lib-gnu-crypto.so).
(See http://www.gnu.org/software/gnu-crypto/#status for the supported
algorithms.)
- The JCE framework (javax.crypto package) from BouncyCastle is imported
into the GNU Crypto tree. And developers get a choice (configure option)
to build/install the javax-crypto jar and shared library
(lib-javax-crypto.so) if they want.
- If all the above is installed correctly then a developer only has to
add the GNU Crypto JCE wrapper gnu.crypto.jce.GnuCrypto provider to the
security properties file to automatically use all the new algorithms.
- GNU Classpath and libgcj explicitly point people to GNU Crypto for
full security algorithm support. GNU Crypto comes with implementations
of some of the algorithms that are optimized for gcj ahead of time
compilation. See the following for a speed hit parade:
http://mail.gnu.org/pipermail/gnu-crypto-discuss/2002-December/57.html
The main reason for this setup is that it is best if GNU Crypto comes in
a way that makes it buildable/workable out of the box with any
Classpath/gcj based system. And that it keeps all crypto stuff in one
place so that only the GNU Crypto developers have to worry about US
export stuff.
We hope that this setup will be completed when gcj 3.3 is released. Most
of the necessary work and bug fixing has already been done in the last
couple of weeks/months. The GNU Crypto non-JCE stuff can already be used
with gcj 3.1/3.2 but some bugs (fixed in 3.3) prevent it from being
compiled at -O2 which makes it a lot slower then necessary.
This is what needs to be done:
- There seems to be a bug in java.math.BigInteger.euclidInv which throws
AlgorithmException("not invertable"). Casey Marshall tracked this issue
down and posted about it on the GNU Classpath mailing list, but it seems
to have not shown up in the archives yet.
- java.security startup refs "GNU libgcj.security"
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&database=gcc&pr=7416
Tom Tromey had a suggestion for a bug fix.
- Finalise the GNU Crypto regression tests. Raif Naffah already did most
of the work for this.
- Import the javax.crypto classes into GNU Crypto source/javax
hierarchy. Casey Marshall already has this working outside the GNU
Crypto source tree .
- We are looking for someone to work on a KeyStore implementation. Joerg
Brunsmann suggested to support PKCS12 as standard format and maybe add
read support for the proprietary JKS format (if we can find specs or
reverse engineer it).
Cheers,
Mark
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: Contributions of work on Jikes RVM with GNU Classpath
On Sat, 2002-12-07 at 06:06, Julian Dolby wrote: > The motivation for this fix was that this sorting method was throwing > array out of bounds errors from various places within Eclipse. I looked at > the code, and these fixes seemed appropriate and made the out of bounds > exceptions go away. Ok. I will try to reproduce this myself so that we have a test case for Mauve. How did you run Eclipse? I assume you were using OTI or Sun awt and swing classes? Some questions about the other patches to Classpath: 1. The patches to VMSystem and System http://savannah.gnu.org/patch/?func=detailpatch&patch_id=720&group_id=85 In the old code, System.in, out and err were constructed automatically, but the proposed patch would leave it up to the VM to initialise these. How about we add a hook in the System static initializer to call something like VMSystem.makeStandardStreams() ? The downside of this is that VMs that didn't bother with setting these streams before, would now have to implement methods to do so. 2. To run JRVM with GNU Classpath the native methods in java/io/File, FileDescriptor, FileInputStream etc have to be replaced with calls to the JRVM support library. How are we going to do this? Before we were thinking of doing preprocessing of the Classpath java/io/*.java source with JRVM-glue code being controlled by a compile-time option. Is there another way to get around this? John Leuner signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: java.security.Security bug
Hi,
On Fri, 2002-12-13 at 05:59, Casey Marshall wrote:
> The loadProviders method of java.security.Security has a rather silly
> bug in it:
>
> - --- LINE 92 ---
> ~ while ((name = secprops.getProperty("security.provider." + i++)) !=
> ~null)
> ~ {
> ~ Exception exception = null;
>
> ~ try
> ~ {
>providers.addElement(Class.forName(name).newInstance());
>i++;
>
> (etc.)
> - -
>
> The value `i' is incremented twice in the `while' loop. Remove one of
> them for the correct behavior.
Thanks for spotting this. Fixed by moving the i++ to the end of the
while loop outside the try-catch block (otherwise i would not get
incremented at all when a provider failed to load).
Cheers,
Mark
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: more. was: ...and in classpath. was: bug in libjava
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
(CC to the Classpath list)
Busy night :)
The BigInteger.euclidInv bug has to do with the transition between the
BigInteger-based version of the function to the int-based one. See:
LINE 1104:
~ if (a.words == null)
~{
~ int[] xyInt = euclidInv(b.ival, a.ival % b.ival, a.ival / b.ival);
~ xy = new BigInteger[3];
~ xy[0] = new BigInteger(xyInt[0]);
~ xy[1] = new BigInteger(xyInt[1]);
~}
This conditional does not consider if (b.words == null), which means it
may recurse with a value of `b==1' (not good!). It may be the case that
always `a > b' for this algorithm (is this so?), but it is not the case
right now that `b' is stored as int-only if `a' is.
So a fix involves changing line 1104 to read:
~ if (a.words == null && b.words == null)
Cheers,
- --
Casey Marshall < [EMAIL PROTECTED] > http://metastatic.org/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE9+ZqEgAuWMgRGsWsRAtRAAJ0dUY1T8iZuJK/9LwFddGHU8P5tsQCfYXD0
IAEKvw5BJ31XOLYw7Z6qM0w=
=4N44
-END PGP SIGNATURE-
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
