[cp-testresults] FAIL: cacao build on Mon Feb 16 11:41:28 UTC 2009
^
../../../cacao/src/classes/gnuclasspath/java/lang/reflect/VMField.java:242:
warning: .
native int getInt(Object o)
^
../../../cacao/src/classes/gnuclasspath/java/lang/reflect/VMMethod.java:243:
error: Class or interface declaration expected.
}
^
../../../cacao/src/classes/gnuclasspath/java/lang/reflect/VMMethod.java:249:
error: syntax error.
private synchronized native MapClass? extends Annotation, Annotation
declaredAnnotations();
^
../../../cacao/src/classes/gnuclasspath/java/lang/reflect/VMField.java:249:
warning: .
* @param o the object to get the value of this Field from
^
../../../cacao/src/classes/gnuclasspath/java/lang/reflect/VMMethod.java:251:
error: Class or interface declaration expected.
}
^
../../../cacao/src/classes/gnuclasspath/sun/misc/Unsafe.java:229: error:
Invalid character '@' in input.
@Deprecated
^
../../../cacao/src/classes/gnuclasspath/java/lang/reflect/Constructor.java:81:
error: '{' expected.
public final class ConstructorT
^
../../../cacao/src/classes/gnuclasspath/java/lang/reflect/Constructor.java:81:
confused by earlier errors, bailing out
make[3]: *** [vm.zip] Error 1
make[3]: Leaving directory `/home/cpdev/Nightly/cacao/build/src/classes'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/cpdev/Nightly/cacao/build/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/cpdev/Nightly/cacao/build'
make: *** [all] Error 2
___
Classpath-testresults mailing list
Classpath-testresults@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-testresults
[cp-testresults] FAIL: regressions for mauve-jamvm on Mon Feb 16 13:18:08 UTC 2009
Baseline from: Mon Feb 16 04:38:07 UTC 2009 Regressions: FAIL: java.lang.Thread.sleep FAIL: javax.net.ssl.SSLEngine.TestHandshake Totals: PASS: 2967 XPASS: 0 FAIL: 216 XFAIL: 0 ___ Classpath-testresults mailing list Classpath-testresults@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-testresults
[cp-testresults] FAIL: regressions for mauve-gij on Mon Feb 16 14:21:42 UTC 2009
Baseline from: Sun Feb 15 12:45:50 UTC 2009 Regressions: FAIL: javax.net.ssl.SSLEngine.TestHandshake Totals: PASS: 2936 XPASS: 0 FAIL: 241 XFAIL: 0 ___ Classpath-testresults mailing list Classpath-testresults@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-testresults
[cp-testresults] FAIL: cacao build on Mon Feb 16 20:18:49 UTC 2009
^
../../../cacao/src/classes/gnuclasspath/java/lang/reflect/VMField.java:242:
warning: .
native int getInt(Object o)
^
../../../cacao/src/classes/gnuclasspath/java/lang/reflect/VMMethod.java:243:
error: Class or interface declaration expected.
}
^
../../../cacao/src/classes/gnuclasspath/java/lang/reflect/VMMethod.java:249:
error: syntax error.
private synchronized native MapClass? extends Annotation, Annotation
declaredAnnotations();
^
../../../cacao/src/classes/gnuclasspath/java/lang/reflect/VMField.java:249:
warning: .
* @param o the object to get the value of this Field from
^
../../../cacao/src/classes/gnuclasspath/java/lang/reflect/VMMethod.java:251:
error: Class or interface declaration expected.
}
^
../../../cacao/src/classes/gnuclasspath/sun/misc/Unsafe.java:229: error:
Invalid character '@' in input.
@Deprecated
^
../../../cacao/src/classes/gnuclasspath/java/lang/reflect/Constructor.java:81:
error: '{' expected.
public final class ConstructorT
^
../../../cacao/src/classes/gnuclasspath/java/lang/reflect/Constructor.java:81:
confused by earlier errors, bailing out
make[3]: *** [vm.zip] Error 1
make[3]: Leaving directory `/home/cpdev/Nightly/cacao/build/src/classes'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/cpdev/Nightly/cacao/build/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/cpdev/Nightly/cacao/build'
make: *** [all] Error 2
___
Classpath-testresults mailing list
Classpath-testresults@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-testresults
[cp-testresults] FAIL: regressions for mauve-jamvm on Mon Feb 16 21:43:38 UTC 2009
Baseline from: Mon Feb 16 04:38:07 UTC 2009 Regressions: FAIL: java.lang.Thread.sleep Totals: PASS: 2968 XPASS: 0 FAIL: 215 XFAIL: 0 ___ Classpath-testresults mailing list Classpath-testresults@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-testresults
[cp-testresults] FAIL: regressions for mauve-gij on Mon Feb 16 22:49:09 UTC 2009
Baseline from: Sun Feb 15 12:45:50 UTC 2009 Regressions: FAIL: gnu.java.security.util.TestOfIntegerUtil FAIL: java.util.logging.SocketHandler.getFilter Totals: PASS: 2935 XPASS: 0 FAIL: 244 XFAIL: 0 ___ Classpath-testresults mailing list Classpath-testresults@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-testresults
[cp-testresults] FAIL: cacao build on Tue Feb 17 04:44:55 UTC 2009
^
../../../cacao/src/classes/gnuclasspath/java/lang/reflect/VMField.java:242:
warning: .
native int getInt(Object o)
^
../../../cacao/src/classes/gnuclasspath/java/lang/reflect/VMMethod.java:243:
error: Class or interface declaration expected.
}
^
../../../cacao/src/classes/gnuclasspath/java/lang/reflect/VMMethod.java:249:
error: syntax error.
private synchronized native MapClass? extends Annotation, Annotation
declaredAnnotations();
^
../../../cacao/src/classes/gnuclasspath/java/lang/reflect/VMField.java:249:
warning: .
* @param o the object to get the value of this Field from
^
../../../cacao/src/classes/gnuclasspath/java/lang/reflect/VMMethod.java:251:
error: Class or interface declaration expected.
}
^
../../../cacao/src/classes/gnuclasspath/sun/misc/Unsafe.java:229: error:
Invalid character '@' in input.
@Deprecated
^
../../../cacao/src/classes/gnuclasspath/java/lang/reflect/Constructor.java:81:
error: '{' expected.
public final class ConstructorT
^
../../../cacao/src/classes/gnuclasspath/java/lang/reflect/Constructor.java:81:
confused by earlier errors, bailing out
make[3]: *** [vm.zip] Error 1
make[3]: Leaving directory `/home/cpdev/Nightly/cacao/build/src/classes'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/cpdev/Nightly/cacao/build/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/cpdev/Nightly/cacao/build'
make: *** [all] Error 2
___
Classpath-testresults mailing list
Classpath-testresults@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-testresults
[cp-testresults] FAIL: regressions for mauve-gij on Tue Feb 17 07:22:39 UTC 2009
Baseline from: Sun Feb 15 12:45:50 UTC 2009 Regressions: FAIL: gnu.java.security.util.TestOfIntegerUtil FAIL: java.lang.Thread.sleep FAIL: java.util.logging.SocketHandler.getFilter Totals: PASS: 2934 XPASS: 0 FAIL: 245 XFAIL: 0 ___ Classpath-testresults mailing list Classpath-testresults@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-testresults
using Smack API with GNU Classpath
Hello everyone, I'm a Java Developer and I'm working mainly with embedded devices. Now I'm running JamVM with GNU Classpath on an ARM processor. This is all working fine, and I didn't had any big problems until now... I'll try to explain my problem as good as possible, but if someone needs some more information, you can contact me ofcourse! So, I'm using the Smack API to get an XMPPConnection with my XMPPServer. This is working, but my CPU is running at 100%! I do have the same problem (CPU at 100%) when I try to run this java program on my desktop computer with JamVM and GNU Classpath. When I run it using Sun's JVM, the CPU load is around 0-1 %. I don't have any clue what this problem could be causing, I'm trying to find out what part of the Smack API is causing the problems, but at the moment I log-in to the server, the CPU jumps to 100%... Could this be caused by some encryption that's been used by Smack? Since the Smack API needs a KeyStoreType, I'm using the gkr type since that's the one supported by GNU Classpath... If anyone had this kind of problems before with GNU Classpath, or could solve my problem, this would be great!! Any help would be welcome since I'm quite stuck with this... Kind regards, Jan
Re: using Smack API with GNU Classpath
Hi Jan, 2009/2/16 Jan Pannecoeck j...@mgb-tech.com: Hello everyone, I'm a Java Developer and I'm working mainly with embedded devices. Now I'm running JamVM with GNU Classpath on an ARM processor. This is all working fine, and I didn't had any big problems until now... I'll try to explain my problem as good as possible, but if someone needs some more information, you can contact me ofcourse! So, I'm using the Smack API to get an XMPPConnection with my XMPPServer. This is working, but my CPU is running at 100%! I do have the same problem (CPU at 100%) when I try to run this java program on my desktop computer with JamVM and GNU Classpath. When I run it using Sun's JVM, the CPU load is around 0-1 %. I don't have any clue what this problem could be causing, I'm trying to find out what part of the Smack API is causing the problems, but at the moment I log-in to the server, the CPU jumps to 100%... Could this be caused by some encryption that's been used by Smack? Since the Smack API needs a KeyStoreType, I'm using the gkr type since that's the one supported by GNU Classpath... If anyone had this kind of problems before with GNU Classpath, or could solve my problem, this would be great!! Any help would be welcome since I'm quite stuck with this... What version of JamVM are you using? It's possible some code you're running is using the new concurrency API (JSR 166). In JamVM 1.5.1, park/unpark was incomplete and could use 100% CPU. This is fixed in 1.5.2. Rob. Kind regards, Jan
Re: using Smack API with GNU Classpath
Hello Robert, I'm using JamVM 1.5.0 at the ARM and JamVM 1.4.5 at my desktop pc. Is the problem you described also in those versions, or only in the 1.5.1 version? Thanks for your reply! Jan Robert Lougher wrote: Hi Jan, 2009/2/16 Jan Pannecoeck j...@mgb-tech.com: Hello everyone, I'm a Java Developer and I'm working mainly with embedded devices. Now I'm running JamVM with GNU Classpath on an ARM processor. This is all working fine, and I didn't had any big problems until now... I'll try to explain my problem as good as possible, but if someone needs some more information, you can contact me ofcourse! So, I'm using the Smack API to get an XMPPConnection with my XMPPServer. This is working, but my CPU is running at 100%! I do have the same problem (CPU at 100%) when I try to run this java program on my desktop computer with JamVM and GNU Classpath. When I run it using Sun's JVM, the CPU load is around 0-1 %. I don't have any clue what this problem could be causing, I'm trying to find out what part of the Smack API is causing the problems, but at the moment I log-in to the server, the CPU jumps to 100%... Could this be caused by some encryption that's been used by Smack? Since the Smack API needs a KeyStoreType, I'm using the gkr type since that's the one supported by GNU Classpath... If anyone had this kind of problems before with GNU Classpath, or could solve my problem, this would be great!! Any help would be welcome since I'm quite stuck with this... What version of JamVM are you using? It's possible some code you're running is using the new concurrency API (JSR 166). In JamVM 1.5.1, park/unpark was incomplete and could use 100% CPU. This is fixed in 1.5.2. Rob. Kind regards, Jan
Re: using Smack API with GNU Classpath
Hi Jan, 2009/2/16 Jan Pannecoeck j...@mgb-tech.com: Hello Robert, I'm using JamVM 1.5.0 at the ARM and JamVM 1.4.5 at my desktop pc. Is the problem you described also in those versions, or only in the 1.5.1 version? Yes, the problem is in both 1.4.5 and 1.5.0 (JSR 166 support was added in 1.4.5, with an inefficient park/unpark implementation -- this has finally been replaced in 1.5.2). Rob. Thanks for your reply! Jan Robert Lougher wrote: Hi Jan, 2009/2/16 Jan Pannecoeck j...@mgb-tech.com: Hello everyone, I'm a Java Developer and I'm working mainly with embedded devices. Now I'm running JamVM with GNU Classpath on an ARM processor. This is all working fine, and I didn't had any big problems until now... I'll try to explain my problem as good as possible, but if someone needs some more information, you can contact me ofcourse! So, I'm using the Smack API to get an XMPPConnection with my XMPPServer. This is working, but my CPU is running at 100%! I do have the same problem (CPU at 100%) when I try to run this java program on my desktop computer with JamVM and GNU Classpath. When I run it using Sun's JVM, the CPU load is around 0-1 %. I don't have any clue what this problem could be causing, I'm trying to find out what part of the Smack API is causing the problems, but at the moment I log-in to the server, the CPU jumps to 100%... Could this be caused by some encryption that's been used by Smack? Since the Smack API needs a KeyStoreType, I'm using the gkr type since that's the one supported by GNU Classpath... If anyone had this kind of problems before with GNU Classpath, or could solve my problem, this would be great!! Any help would be welcome since I'm quite stuck with this... What version of JamVM are you using? It's possible some code you're running is using the new concurrency API (JSR 166). In JamVM 1.5.1, park/unpark was incomplete and could use 100% CPU. This is fixed in 1.5.2. Rob. Kind regards, Jan
Re: using Smack API with GNU Classpath
P.S. Unfortunately, to upgrade to 1.5.2, you'll also need to upgrade GNU Classpath to 0.98... Rob. 2009/2/16 Robert Lougher rob.loug...@gmail.com: Hi Jan, 2009/2/16 Jan Pannecoeck j...@mgb-tech.com: Hello Robert, I'm using JamVM 1.5.0 at the ARM and JamVM 1.4.5 at my desktop pc. Is the problem you described also in those versions, or only in the 1.5.1 version? Yes, the problem is in both 1.4.5 and 1.5.0 (JSR 166 support was added in 1.4.5, with an inefficient park/unpark implementation -- this has finally been replaced in 1.5.2). Rob. Thanks for your reply! Jan Robert Lougher wrote: Hi Jan, 2009/2/16 Jan Pannecoeck j...@mgb-tech.com: Hello everyone, I'm a Java Developer and I'm working mainly with embedded devices. Now I'm running JamVM with GNU Classpath on an ARM processor. This is all working fine, and I didn't had any big problems until now... I'll try to explain my problem as good as possible, but if someone needs some more information, you can contact me ofcourse! So, I'm using the Smack API to get an XMPPConnection with my XMPPServer. This is working, but my CPU is running at 100%! I do have the same problem (CPU at 100%) when I try to run this java program on my desktop computer with JamVM and GNU Classpath. When I run it using Sun's JVM, the CPU load is around 0-1 %. I don't have any clue what this problem could be causing, I'm trying to find out what part of the Smack API is causing the problems, but at the moment I log-in to the server, the CPU jumps to 100%... Could this be caused by some encryption that's been used by Smack? Since the Smack API needs a KeyStoreType, I'm using the gkr type since that's the one supported by GNU Classpath... If anyone had this kind of problems before with GNU Classpath, or could solve my problem, this would be great!! Any help would be welcome since I'm quite stuck with this... What version of JamVM are you using? It's possible some code you're running is using the new concurrency API (JSR 166). In JamVM 1.5.1, park/unpark was incomplete and could use 100% CPU. This is fixed in 1.5.2. Rob. Kind regards, Jan
Re: using Smack API with GNU Classpath
Hi, Thanks for the reply! I'll try that later today to see if I could cross-compile the JamVM 1.5.2 with GNU Classpath 0.98! Since those are both the most recent versions I hope this solves my problem!! Thanks! Jan Robert Lougher wrote: P.S. Unfortunately, to upgrade to 1.5.2, you'll also need to upgrade GNU Classpath to 0.98... Rob. 2009/2/16 Robert Lougher rob.loug...@gmail.com: Hi Jan, 2009/2/16 Jan Pannecoeck j...@mgb-tech.com: Hello Robert, I'm using JamVM 1.5.0 at the ARM and JamVM 1.4.5 at my desktop pc. Is the problem you described also in those versions, or only in the 1.5.1 version? Yes, the problem is in both 1.4.5 and 1.5.0 (JSR 166 support was added in 1.4.5, with an inefficient park/unpark implementation -- this has finally been replaced in 1.5.2). Rob. Thanks for your reply! Jan Robert Lougher wrote: Hi Jan, 2009/2/16 Jan Pannecoeck j...@mgb-tech.com: Hello everyone, I'm a Java Developer and I'm working mainly with embedded devices. Now I'm running JamVM with GNU Classpath on an ARM processor. This is all working fine, and I didn't had any big problems until now... I'll try to explain my problem as good as possible, but if someone needs some more information, you can contact me ofcourse! So, I'm using the Smack API to get an XMPPConnection with my XMPPServer. This is working, but my CPU is running at 100%! I do have the same problem (CPU at 100%) when I try to run this java program on my desktop computer with JamVM and GNU Classpath. When I run it using Sun's JVM, the CPU load is around 0-1 %. I don't have any clue what this problem could be causing, I'm trying to find out what part of the Smack API is causing the problems, but at the moment I log-in to the server, the CPU jumps to 100%... Could this be caused by some encryption that's been used by Smack? Since the Smack API needs a KeyStoreType, I'm using the gkr type since that's the one supported by GNU Classpath... If anyone had this kind of problems before with GNU Classpath, or could solve my problem, this would be great!! Any help would be welcome since I'm quite stuck with this... What version of JamVM are you using? It's possible some code you're running is using the new concurrency API (JSR 166). In JamVM 1.5.1, park/unpark was incomplete and could use 100% CPU. This is fixed in 1.5.2. Rob. Kind regards, Jan
Re: using Smack API with GNU Classpath
Hello, I didn't know I was talking to the builder of JamVM!!! Now I was reading the version details and saw your name behind the copyright!! Nice work with the JamVM!!! I've been testing different vm's and still my favorite one is JamVM! Especially for embedded devices! But to go back on-topic, I've compiled the JamVM 1.5.2 with GNU Classpath 0.98 on my desktop, since the problem also occurred on my desktop I thought it would be easier to compile, since the cross-compilation isn't always that easy... And as you said, that my problems could be solved...Well they are solved! The program that was running at 100% CPU is now running at 0-1% CPU so that's nice! Thanks for your advice about the latest version of JamVM! Kind regards and keep up the great work with JamVM!! Jan Robert Lougher wrote: P.S. Unfortunately, to upgrade to 1.5.2, you'll also need to upgrade GNU Classpath to 0.98... Rob. 2009/2/16 Robert Lougher rob.loug...@gmail.com: Hi Jan, 2009/2/16 Jan Pannecoeck j...@mgb-tech.com: Hello Robert, I'm using JamVM 1.5.0 at the ARM and JamVM 1.4.5 at my desktop pc. Is the problem you described also in those versions, or only in the 1.5.1 version? Yes, the problem is in both 1.4.5 and 1.5.0 (JSR 166 support was added in 1.4.5, with an inefficient park/unpark implementation -- this has finally been replaced in 1.5.2). Rob. Thanks for your reply! Jan Robert Lougher wrote: Hi Jan, 2009/2/16 Jan Pannecoeck j...@mgb-tech.com: Hello everyone, I'm a Java Developer and I'm working mainly with embedded devices. Now I'm running JamVM with GNU Classpath on an ARM processor. This is all working fine, and I didn't had any big problems until now... I'll try to explain my problem as good as possible, but if someone needs some more information, you can contact me ofcourse! So, I'm using the Smack API to get an XMPPConnection with my XMPPServer. This is working, but my CPU is running at 100%! I do have the same problem (CPU at 100%) when I try to run this java program on my desktop computer with JamVM and GNU Classpath. When I run it using Sun's JVM, the CPU load is around 0-1 %. I don't have any clue what this problem could be causing, I'm trying to find out what part of the Smack API is causing the problems, but at the moment I log-in to the server, the CPU jumps to 100%... Could this be caused by some encryption that's been used by Smack? Since the Smack API needs a KeyStoreType, I'm using the gkr type since that's the one supported by GNU Classpath... If anyone had this kind of problems before with GNU Classpath, or could solve my problem, this would be great!! Any help would be welcome since I'm quite stuck with this... What version of JamVM are you using? It's possible some code you're running is using the new concurrency API (JSR 166). In JamVM 1.5.1, park/unpark was incomplete and could use 100% CPU. This is fixed in 1.5.2. Rob. Kind regards, Jan
