[kaffe] RefTest.java failure on m68k
Hi, Since I got both m68k/netbsd and m68k/linux working, I restarted to reduce the number of failure in regression test. First test failed for both netbsd and linux is 'RefTest.java', and I noticed it is very simple why it fails. In the source we have Watchdog dog = new Watchdog(1); and changing the number to 100 (wow!) makes this test is passed by both m68k/netbsd and m68k/linux. So, my question, where this magic number come from? Is it ok to increase for slower machine like m68k? Or in long run, aren't there any better way to set these performance specific parameters depends on the machine speed? Kiyo ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] jikes related problems for the SNAP
For the latest snap (051208), I got two problems with jikes. 1) '--with-jikes' option of configure script got slightly different semantic. Until recently, the option can get parameter for the path of jikes, but this snap did not pass parameter for this option to sub configure. This makes detection of jikes fail in configuring classpath. In main configure, log says checking for jikes... no checking whether to use jikes... yes (/home/inaba/bin/jikes +Pno-switchcheck +Pno-shadow +E) checking which java compiler... /home/inaba/bin/jikes +Pno-switchcheck +Pno-shadow +E but in classpath configure, log says checking for gcj... no checking for jikes... no checking for kJC... no checking for gcjx... no checking for ecj... no configure: cannot find javac, try --with-gcj, --with-jikes, --with-kjc, or --with-gcjx and failed for the configure and build. The reason for this error is, when invoking sub configure, it passed two --with-jikes options and the former are with parameter (path for jikes) but the later does not have parameter. Do we change not to allow specifying path for jikes from now on, or is it just a bug? 2) With older version of jikes (1.19) the option 'no-shadow' is not a valid option, and invocation of jikes failed with this SNAP. I hand edit Makefiles (and TestScript) and got proper result. Checking the version of jikes while configure and set proper pedantic warning corresponding to the version of jikes should be very appreciated. Kiyo ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] libraries/javalib/external/classpath/doc/*.info files are missing
Dalibor Topic wrote: >Ito Kazumitsu wrote: >> Sorry for missing your message. I did not think that would be a >> problem to me. > >Same here ;( It's ok. Even I did not have confidence whether this bug is only for *BSD, or more general. Whenever I found a bug for a port, I compare it with RH8.0 or FC3, and this time generating info files are ok on RH8.0 and I guess it should be *BSD specific. I then have to check why I and Kaz have different result on RH8.0. >Sounds fine to me. Do the info files get built during a make dist step? >Then we could simply add a "make dist classpath" step to the resync >script, and untar that over the classpath dir, instead of copying the >files over. ... >In general, GNU Classpath tries to keep generated files out of its CVS, >so no configure scripts, Makefile.in files, and I guess no info files >either. It's a different phiolosophy. ;) > >That's why the resync-classpath script does an autogen.sh call on the >newly checked out GNU Classpath. Then, I'd like not to simply put info files into CVS, and try to find better solution. I think Classpath's people's philosophy is practical from the point of consistency. Kiyo ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Should IllegalAccessException be thrown or not?
From: Ito Kazumitsu <[EMAIL PROTECTED]>
Subject: Re: [kaffe] ecj-compiled kaffe fails in regression tests
Date: Fri, 09 Dec 2005 15:03:16 +0900 (JST)
> Sun's JDK gives this (when DEBUG is set to true):
>
> Generating canonical stream
> Serializing TestSerialFields$Test0001
> Exception: java.lang.IllegalAccessException
> java.lang.IllegalAccessException: Class TestSerialFields can not access a
> member of class TestSerialFields$Test0001 with modifiers "private"
> at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:65)
> at java.lang.Class.newInstance0(Class.java:344)
> at java.lang.Class.newInstance(Class.java:303)
> at TestSerialFields.generateBytes(TestSerialFields.java:529)
> at TestSerialFields.main(TestSerialFields.java:623)
> Exception in thread "main" java.lang.NullPointerException
> at TestSerialFields.checkClass(TestSerialFields.java:604)
> at TestSerialFields.main(TestSerialFields.java:633)
>
> If Sun's JDK is correct, Kaffe fails to detect this IllegalAccessException
> and the regression tests have been depending on such behavour of Kaffe.
I have made a simpler test case.
public class TestPrivateClass {
private static class Test0001 {
}
public static void main(String[] args) {
try {
Object obj = Test0001.class.newInstance();
}
catch (Exception e) {
e.printStackTrace();
}
}
}
This ends normally when run on Kaffe, but when run on Sun's JDK,
java.lang.IllegalAccessException: Class TestPrivateClass can not access a
member of class TestPrivateClass$Test0001 with modifiers "private"
at sun.reflect.Reflection.ensureMemberAccess(Unknown Source)
at java.lang.Class.newInstance0(Unknown Source)
at java.lang.Class.newInstance(Unknown Source)
at TestPrivateClass.main(TestPrivateClass.java:7)
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] CVS kaffe (kaz): FAQ/FAQ.classlibrary-compile: Updated the description of ecj.
PatchSet 6992 Date: 2005/12/10 01:39:14 Author: kaz Branch: HEAD Tag: (none) Log: 2005-12-10 Ito Kazumitsu <[EMAIL PROTECTED]> * FAQ/FAQ.classlibrary-compile: Updated the description of ecj. Members: ChangeLog:1.4513->1.4514 FAQ/FAQ.classlibrary-compile:1.23->1.24 Index: kaffe/ChangeLog diff -u kaffe/ChangeLog:1.4513 kaffe/ChangeLog:1.4514 --- kaffe/ChangeLog:1.4513 Thu Dec 8 21:28:55 2005 +++ kaffe/ChangeLog Sat Dec 10 01:39:14 2005 @@ -1,3 +1,7 @@ +2005-12-10 Ito Kazumitsu <[EMAIL PROTECTED]> + + * FAQ/FAQ.classlibrary-compile: Updated the description of ecj. + 2005-12-08 Guilhem Lavaux <[EMAIL PROTECTED]> * developers/update-vm-list: Sort files before adding them to Index: kaffe/FAQ/FAQ.classlibrary-compile diff -u kaffe/FAQ/FAQ.classlibrary-compile:1.23 kaffe/FAQ/FAQ.classlibrary-compile:1.24 --- kaffe/FAQ/FAQ.classlibrary-compile:1.23 Tue Sep 20 19:53:44 2005 +++ kaffe/FAQ/FAQ.classlibrary-compile Sat Dec 10 01:39:17 2005 @@ -102,13 +102,34 @@ http://www.eclipse.org +If you cannot find ecj in this project site, just download Eclipse SDK +(eclipse-SDK-3.1.1 at the time of this writing), and read the document +"Compiling Java code". Then you will find that the following shell script +will work as ecj. + +#!/bin/sh +exec path_to_a_working_Java_VM \ + -classpath path_to_org.eclipse.jdt.core.jar \ + org.eclipse.jdt.internal.compiler.batch.Main \ + "$@" + +By the way, there is a "distribution" of ecj itself in the debian +repository (ecj-bootstrap). + In order to compile kaffe's class library, you need to set JAVAC_FLAGS to "-source 1.4 -bootclasspath /full/path/to/builddir/libraries/javalib/lib/", with "/full/path/to/builddir" replaced by the full path to the directory where you are building the Kaffe source code. +Now ./configure accepts an option to use ecj: + + --with-ecj=ECJ Define to use ECJ as the java compiler instead of + jikes + +and you do not have to care about JAVAC_FLAGS. + It works with ecj 0.548, pre-3.1.0 milestone-6, and should work with later -versions as well. +versions as well. The wrapping shell script of ecj shown above also works. * kjc ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] ecj-compiled kaffe fails in regression tests
Hi Ito, Ito Kazumitsu wrote: From: Ito Kazumitsu <[EMAIL PROTECTED]> Date: Fri, 09 Dec 2005 13:31:58 +0900 (JST) So the question is whether the assumption that returned test array is consistently sorted is valid or not. If the assumption is valid, then ecj may be wrong. Otherwise we will have to modify the test programs so that it can check the result without depending on the order of array elements. Sun's API document of getDeclaredClasses says nothing about the order of elements in the returned array. So I do not tink it is a good thing to write a program which assumes some special order of elements of the array. So I think Kaffe's TestSerial*.java should be modified. Many thanks for exploring the reason of the bug. :) I am modifying the tests to sort the classes before running the test. However while comparing kaffe's output to sun's jdk I got some annoying differences in the way some exception are thrown. So these tests will remain as broken while someone fixes it (I'll try to do it...) Regards, Guilhem. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
