Re: [kaffe] string.c:373: stringInternString: Assertion `temp == string' failed.
Not always but often, the error Assertion `temp == string' failed occurs when runnig h2 database (http://www.h2database.com/). $ kaffe -cp ../h2/bin/h2.jar org.h2.tools.Server -tcp -tcpAllowOthers true -log kaffe-bin: string.c:373: stringInternString: Assertion `temp == string' failed. The condition of the occurrence of this error seems to be very limited. I see this error only on one machine, and never on others. The problematic machine is like this. $ uname -a Linux htk 2.6.9-34.0.2.ELsmp #1 SMP Fri Jun 30 10:33:58 EDT 2006 i686 i686 i386 GNU/Linux $ kaffe -fullversion java full version kaffe-1.4.2 kaffe VM 1.1.10-pre ... Engine: Just-in-time v3 Version: 1.1.10-pre Java Version: 1.4 Heap defaults: minimum size: 5 MB, maximum size: unlimited Stack default size: 256 KB Configuration/Compilation options: ) Compile date : Mon Apr 14 09:08:51 JST 2008 Compile host : xxx Install prefix : /home/ito/work/kaffe Thread system: unix-pthreads Garbage Collector: kaffe-gc CC : gcc -std=gnu99 CFLAGS : -g -O2 -Wall -W -Wextra -fno-strict-aliasing -fno-omit-frame-pointer -pthread LDFLAGS : ChangeLog head : 2008-03-09 Dalibor Topic [EMAIL PROTECTED] $ gcc --version gcc (GCC) 3.4.5 20051201 (Red Hat 3.4.5-2) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] string.c:373: stringInternString: Assertion `temp == string' failed.
Hi, Not always but often, the error Assertion `temp == string' failed occurs when runnig h2 database (http://www.h2database.com/). $ kaffe -cp ../h2/bin/h2.jar org.h2.tools.Server -tcp -tcpAllowOthers true -log true kaffe-bin: string.c:373: stringInternString: Assertion `temp == string' failed. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] libraries/javalib/vmspecific/java/lang/reflect/
Hi,
libraries/javalib/vmspecific/java/lang/reflect/Field.java has these lines.
public String toString()
{
// 64 is a reasonable buffer initial size for field
StringBuilder sb = new StringBuilder(64);
Modifier.toString(getModifiers(), sb).append(' ');
sb.append(ClassHelper.getUserName(getType())).append(' ');
sb.append(getDeclaringClass().getName()).append('.');
sb.append(getName());
return sb.toString();
}
public String toGenericString()
{
StringBuilder sb = new StringBuilder(64);
Modifier.toString(getModifiers(), sb).append(' ');
sb.append(getGenericType()).append(' ');
sb.append(getDeclaringClass().getName()).append('.');
sb.append(getName());
return sb.toString();
}
But GNU Classpath has already replaced Modifier.toString(int, StringBuilder)
by Modifier.toString(int, CPStringBuilder). So Kaffe cannot be built with
the current GNU Classpath.
This problem may be solved by either of the following:
(1) Wait for the release of the new version of GNU Classpath.
Modify Kaffe's methods so that they use CPStringBuilder.
Declare that Kaffe requires the new version of GNU Classpath.
(2) Modify GNU Classpath so that it supports the old method call
Modifier.toString(int, StringBuilder).
(2) is easy, but I do not think it is acceptable for GNU Classpath
people.
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: OutOfMemoryError while compiling GNU Classpath
From: Dalibor Topic [EMAIL PROTECTED] Subject: Re: [kaffe] Re: OutOfMemoryError while compiling GNU Classpath Date: Sat, 16 Feb 2008 00:39:12 +0100 I've committed a fix now. Thank you very much for spotting this embarassing bug, and I hope the fix will work for you, too. Yes, It worked for me too. Thank you, Dalibor. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] PrimordialLoaderTest fails
Hi Kiyo, From: Kiyo Inaba [EMAIL PROTECTED] Subject: Re: [kaffe] PrimordialLoaderTest fails Date: Mon, 11 Feb 2008 17:31:03 +0900 (JST) Does this problem have something to do with zziplib? I don't think so. I just installed a new file server with FB-6.3, and the regression (against 08/02/07 snap) tells me All 149 tests behaved as expected (2 expected failures) You are right. I have rebuilt GNU Classpath and Kaffe, and have got the same good result. Something must be wrong with the environment before the rebuilding, which was built on FreeBSD 6.3-RELEASE on qemu on FreeBASD 6.2-RELEASE. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] PrimordialLoaderTest fails
From: Ito Kazumitsu [EMAIL PROTECTED] Subject: [kaffe] PrimordialLoaderTest fails Date: Sun, 10 Feb 2008 12:08:42 +0900 (JST) Strangely enough, this test passed when I did it on FreeBSD 6.2-RELEASE. Does this problem have something to do with zziplib? On FreeBSD 6.2-RELEASE, I installed zziplib from source (beginning with Python) because the binary package for this OS version was no longer available. But I installed the binary package of zziplib on FreeBSD 6.3-RELEASE. Compiling zziplib from source did not solve this problem. I think I will study this problem further. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] PrimordialLoaderTest fails
Now PrimordialLoaderTest fails on my FreeBSD 6.3-RELEASE machine. PrimordialLoaderTest.fail says: jar java/lang/Object.class jar java/lang/Object.class class java.util.zip.ZipFile$1 And the expected result is: jar java/lang/Object.class jar java/lang/Object.class class java.util.jar.JarFile$EntryInputStream Strangely enough, this test passed when I did it on FreeBSD 6.2-RELEASE. Does this problem have something to do with zziplib? On FreeBSD 6.2-RELEASE, I installed zziplib from source (beginning with Python) because the binary package for this OS version was no longer available. But I installed the binary package of zziplib on FreeBSD 6.3-RELEASE. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Kaffe needs Python
Now kaffe needs zziplib. But I could not install zziplib for not having python. Do I have to begin with installing python in order to install kaffe? ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] org.kaffe.security.provider.Kaffe
Maybe after the removal of libraries/clib/security/Kaffe.security,
this warning message appears:
WARNING: Error loading security provider org.kaffe.security.provider.Kaffe:
java.lang.ClassNotFoundException: org.kaffe.security.provider.Kaffe
not found in java.lang.ClassLoader$1{urls=[...], parent=null}
I cannot find where org.kaffe.security.provider.Kaffe is defined.
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] System.out.println
Alexander Gromnizki wrote I've compiled kaffe-1.1.8 on FreeBSD 6.0 with tiny patch as described at http://www.kaffe.org/pipermail/kaffe/2007-June/104986.html. The patch which used to be in FAQ/FAQ.freebsd was incomplete. Please do not use that workaround. The bug fix is in GNU Classpath 0.96.1. I suggest you install GNU Classpath 0.96.1 first and then build kaffe using --with-system-classpath. I do not know whether it has something to do with the following problem. % java gnu/classpath/examples/management/TestOS % I.e. it outputs nothing! Problem is in System.out.println() function. Why it doesn't print anything? ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Unexpected NullPointerException
From: Kiyo Inaba [EMAIL PROTECTED] Subject: Re: [kaffe] Unexpected NullPointerException Date: Thu, 9 Aug 2007 17:37:13 +0900 (JST) Please tackle the bug: http://www.kaffe.org/cgi-bin/bugzilla/show_bug.cgi?id=100 Congratulation, Kaz! We finally reach next level of bug reports :-) And it has been fixed, I hope. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Unexpected NullPointerException
Please tackle the bug: http://www.kaffe.org/cgi-bin/bugzilla/show_bug.cgi?id=100 In short, Class.forName(x).toString() or Class.forName(x).hashCode() throws an unexpected NullPointerException, where x is one of the following: java.lang.reflect.AnnotatedElement java.lang.reflect.GenericDeclaration java.lang.reflect.Type all of which are interfaces belonging to the package java.lang.reflect, and java.lang.Class implements. The NullPointerException seems to be thrown not from a Java class such as java.lang.Class but from a native part of Kaffe. This bug will appear if you run rhino on Kaffe: Rhino 1.6 release 5 2006 11 18 js cl = java.lang.Class.forName(AnyClass); java.lang.NullPointerException at java.lang.Class$MethodKey.init (Class.java:652) at java.lang.Class.internalGetMethods (Class.java:846) at java.lang.Class.getMethods (Class.java:815) ... ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] kaffe/kaffevm/readClass.c: Should class version 1.5 be supported?
Hi,
I happened to find that, luckily, a class file of version 1.5
compiled by Sun's javac from source like this:
import java.util.ArrayList;
public class Test1 {
@Deprecated
public static void main(String[] args) {
ArrayListString a = new ArrayListString();
a.add(aaa);
for (String s : a) System.out.println(s);
}
}
can be run with Kaffe normally.
On the other hand, kaffe/kaffevm/readClass.c seems to be trying
to prevent class file version 1.5 from running.
But UnsupportedClassVersionError does not occur because of the
bug in kaffe/kaffevm/readClass.c of not returning NULL.
The question is whether UnsupportedClassVersionError should be
thrown in this case or the class file should be run normally.
I prefer the latter, and this is my proposed patch.
Index: kaffe/kaffe/kaffevm/readClass.c
===
RCS file: /cvs/kaffe/kaffe/kaffe/kaffevm/readClass.c,v
retrieving revision 1.28
diff -u -r1.28 readClass.c
--- kaffe/kaffe/kaffevm/readClass.c 17 Apr 2006 17:57:07 - 1.28
+++ kaffe/kaffe/kaffevm/readClass.c 2 Apr 2007 13:44:23 -
@@ -62,12 +62,14 @@
if (! ((major_version == MAJOR_VERSION_V1_1 minor_version ==
MINOR_VERSION_V1_1) ||
(major_version == MAJOR_VERSION_V1_2 minor_version ==
MINOR_VERSION_V1_2) ||
(major_version == MAJOR_VERSION_V1_3 minor_version ==
MINOR_VERSION_V1_3) ||
- (major_version == MAJOR_VERSION_V1_4 minor_version ==
MINOR_VERSION_V1_4))) {
+ (major_version == MAJOR_VERSION_V1_4 minor_version ==
MINOR_VERSION_V1_4) ||
+ (major_version == MAJOR_VERSION_V1_5 minor_version ==
MINOR_VERSION_V1_5))) {
postExceptionMessage(einfo,
JAVA_LANG(UnsupportedClassVersionError),
%d.%d,
major_version,
minor_version);
+ return NULL;
}
if (readConstantPool(classThis, fp, einfo) == false) {
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Build failure of CVS head for i386/NetBSD
Hi, From: Kiyo Inaba [EMAIL PROTECTED] Subject: [kaffe] Build failure of CVS head for i386/NetBSD Date: Mon, 15 Jan 2007 14:58:58 +0900 (JST) But for cpnet.c, this patch omit one feature which is originally provided. I have no idea (except with private signal handler) how to add NOPIPE flag for send, if it is not provided by the OS... Any better idea which really fix the cpnet.c's problem? Maybe Kaffe VM takes care of SIGPIPE, and we do not have to use a special option. Such is the patch I made in GNU Classpath. I cannot wait for the next occasion of resynchronization with GNU Classpath, and mannually copied some files from GNU Classpath. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Build failure of CVS head for i386/NetBSD
Hi, From: Kiyo Inaba [EMAIL PROTECTED] Subject: [kaffe] Build failure of CVS head for i386/NetBSD Date: Mon, 15 Jan 2007 14:58:58 +0900 (JST) As Kaz suggested, I modified as attached patch and the build get success. But for cpnet.c, this patch omit one feature which is originally provided. I have no idea (except with private signal handler) how to add NOPIPE flag for send, if it is not provided by the OS... It looks like this 'patch' also solve m68k/NetBSD configure problem. Any better idea which really fix the cpnet.c's problem? I think cpnet.c needs further review. It will not work properly on FreeBSD 5.4-RELEASE, either. #if defined (HAVE_MSG_NOSIGNAL) #define SOCKET_NOSIGNAL MSG_NOSIGNAL #elif defined (HAVE_SO_NOSIGPIPE) #define SOCKET_NOSIGNAL SO_NOSIGPIPE #else #error No suitable flag found to ommit a SIGPIPE on signal errors with send(). #endif ret = send(fd, data, len, SOCKET_NOSIGNAL); FreeBSD 5.4-RELEASE: HAVE_MSG_NOSIGNAL false HAVE_SO_NOSIGPIPE true 0x0800 SO_NOSIGPIPE (0x0800) is set to SOCKET_NOSIGNAL and is used as an option to send. But SO_NOSIGPIPE is a socket level option which should be used with setsockopt. 0x0800 used as an option to send will not have any effect, or may have some unexpected effects. Anyway, this is a GNU Classpath issue. I will report a bug about this to GNU Classpath. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Can you tell me the arithmetic's theory
Hi, I don't know what does the arithmetic say! The result from a is 1000, then the result from b is 6. I am not sure, but isn't this calculating the geometrical average of the given five numbers: Math.pow(x1 * x2 * x3 * x4 * x5, 0.2) ? ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Java lang spec: private access
Hi, This question is not directly related to kaffe, but ... The Java Language Specification, Third Edition says: |6.6.1 Determining Accessibility | Otherwise, if the member or constructor is declared private, then |access is permitted if and only if it occurs within the body of the top |level class (7.6) that encloses the declaration of the member or |constructor. | Why the top level class ? What if the private member is declared in an inner class? ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Java lang spec: private access
From: Stuart Ballard [EMAIL PROTECTED]
Date: Tue, 16 May 2006 10:08:36 -0400
Because inner classes *are* within the body of the top level class, perhaps?
:)
Yes, in the following example, the private member of the inner class is
accessible to the top level class.
public class ZZ {
public class ZZ1 {
private int a;
}
ZZ1 zz1;
public ZZ() {
zz1 = new ZZ1();
zz1.a = 1;
}
}
But the following cannot be compiled because a in type ZZ$ZZ1 is
not accessible. Isn't this an access from within the top level class?
public class ZZ {
public class ZZ1 {
private int a;
public void foo() {}
}
ZZ1 zz1;
public ZZ() {
zz1 = new ZZ1() {
public void foo() {
a = 1;
}
};
}
}
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Java lang spec: private access
From: Ito Kazumitsu [EMAIL PROTECTED]
Date: Wed, 17 May 2006 01:20:37 +0900 (JST)
But the following cannot be compiled because a in type ZZ$ZZ1 is
not accessible. Isn't this an access from within the top level class?
I understand. It is not an access to a in type ZZ$ZZ1.
public class ZZ {
public class ZZ1 {
private int a;
public void foo() {}
}
ZZ1 zz1;
public ZZ() {
zz1 = new ZZ1() {
public void foo() {
a = 1;
This is not an access to a in ZZ1, but an access to a in the
anonymous class as a subclass of ZZ1. And the private member a
cannot be inherited.
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Re: Things to do for 1.1.7
Hi Dalibor, From: Dalibor Topic [EMAIL PROTECTED] Date: Tue, 03 Jan 2006 16:40:29 +0100 I've seen that Ito has been working on improving the XML code in GNU Classpath, so it would be good to know if there should be another merge with GNU Classpath's code before the release candidate. The big change in XML code in GNU Classpath is that the default SAX parser package has changed from gnu.xml.aelfred2 to gnu.xml.stream. It seems that the latter is more actively maintained. So another merge with GNU Classpath's code is desirable. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] CVS kaffe (guilhem): Fixed class accessibility.
Hi Guilhem, Here is a better example. The previous could not be compiled directly if you try to compile indepedently then you'll see the runtime accepts it. Here I have an example which compiles and should run on a VM. However kaffe throws an IllegalAccessError. In this case, my patch does not work. Sigh. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] CVS kaffe (guilhem): Fixed class accessibility.
From: Kaffe CVS [EMAIL PROTECTED]
Date: Wed, 21 Dec 2005 10:13:12 -0800
Fixed class accessibility.
* kaffe/kaffevm/access.c
(checkAccess): If target and context are in the same package they are
always visible.
same_package = 1;
/* Package */
- if (!(target-accflags ACC_PROTECTED))
- {
- class_acc = 1;
- }
+ class_acc = 1;
It was stupid of me to check !(target-accflags ACC_PROTECTED)
here. Maybe I meant !(target-accflags ACC_PRIVATE).
But anyway, the correct way is not to check target-accflags
because, if target and context are in the same package, they are
always visible.
Having looked at Sun's documents The Java Virtual Machine Specification
and The Java Language Specification, I have got some idea of
how the run time access control differs from the compile time access
control.
A class or interface C is accessible to a class or interface D if and only if
either of the following conditions are true:
(Runtime):
- C is public.
- C and D are members of the same runtime package.
(Compile time):
- C is public.
- C is a top level class, and C is not public, and C belongs to the
same package as D.
- C is an inner class, and any of the following conditions are true:
o C is public.
o C is protected and ...(omitted).
o C is private and C and D belong to the same top level class.
o C is none of the above, and C and D belong to the same package.
A field or method (or a construntor) R is accessible to a class or
interface D if and only if any of the following conditions is true:
(Runtime):
- R is public.
- R is protected and is declared in a class C, and D is either a subclass of
C or C itself.
- R is either protected or package private (that is, neither public nor
protected nor private), and is declared by a class in the same runtime
package as D.
- R is private and is declared in D.
(Compile time):
- R is declared in a class or interface C, and C is accessible to D
and any of the following conditions is true:
o R is public.
o R is protected and ...(omitted).
o R is private and R and D belong to the same top level class.
o R is none of the above, and R and D belong to the same package.
According to this, the behavior of Sun's JDK throwing
IllegalAccessException for the following may be correct.
public class A {
private static class A1 {
private A1() {}
}
public static void main(String[] args) throws Exception {
new A1();
A1.class.newInstance();
}
}
new A1() is allowed because the private constructor is within the
top level class A, but A1.class.newInstance() is illegal because
the private constructor is not declared in A.
The runtime access control is much simpler than the compile-time
access control. And we may be able to omit the checking of nested
relations of classes at runtime.
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] CVS kaffe (guilhem): Fixed class accessibility.
From: Ito Kazumitsu [EMAIL PROTECTED]
Date: Thu, 22 Dec 2005 11:08:15 +0900 (JST)
The runtime access control is much simpler than the compile-time
access control. And we may be able to omit the checking of nested
relations of classes at runtime.
Simply omitting the checking of nested relations of classes
causes IllegalAccessError, which was reported in November, 2003.
I am afraid Sun's VM spec:
A class or interface C is accessible to a class or interface D if and only if
either of the following conditions are true:
(Runtime):
- C is public.
- C and D are members of the same runtime package.
is incomplete and something should be said about the case
where C is protected.
Attached below is my proposed patch. I have deleted the
checking of outer classes for determining slot_acc,
but kept such checking for determining class_acc.
With this patch applied,
- All the regression tests pass.
- Mauve test gnu.testlet.java.lang.Class.newInstance shows the
same results as Sun's JDK.
- The testcase attached to
http://www.kaffe.org/pipermail/kaffe/2003-November/096187.html
passes.
--- kaffe/kaffevm/access.c.orig Thu Dec 22 08:45:13 2005
+++ kaffe/kaffevm/access.c Thu Dec 22 14:42:08 2005
@@ -153,45 +153,6 @@
}
}
-/*
- * Returns 1 if oc is an outer class of c
- */
-static
-int outerof (Hjava_lang_Class *c, Hjava_lang_Class *oc)
-{
- innerClass *ic;
- Hjava_lang_Class *outer;
- errorInfo einfo;
-
- outer = NULL;
- if( c-this_inner_index = 0 )
- {
- ic = c-inner_classes[c-this_inner_index];
- if( ic-outer_class )
- {
- outer = getClass(ic-outer_class, c, einfo);
- if( outer == NULL )
- {
- discardErrorInfo(einfo);
- }
- }
- }
- if ( outer != NULL )
- {
- if ( oc == outer)
- {
- return 1;
- }
- else
- {
- return outerof(outer, oc);
- }
- }
- else {
- return 0;
- }
-}
-
int checkAccess(struct Hjava_lang_Class *context,
struct Hjava_lang_Class *target,
accessFlags target_flags)
@@ -209,20 +170,15 @@
return 1;
}
- else if ( outerof(target, context) )
- {
- /* target is within the context. */
- class_acc = 1;
- slot_acc = 1;
-
- return 1;
- }
else if( target-accflags ACC_PUBLIC )
{
/* Public class. */
class_acc = 1;
}
- else if( instanceof(target, context) )
+ /* Sun's VM spec does not refer to the case where the target class
+* is protected.
+*/
+ else if( target-accflags ACC_PROTECTED instanceof(target,
context) )
{
class_acc = 1;
}
@@ -310,51 +266,6 @@
/* Package. */
slot_acc = 1;
}
-/*
- Commented out because private members get accessible to
- any context in the same package if target is a nested class.
-
- else if( (target-name-data[0] != '[')
-same_package
-(target-this_inner_index = 0) )
- {
- slot_acc = 1;
- }
-*/
- else if( context-this_inner_index = 0 )
- {
- innerClass *ic;
-
- /*
-* Check for an inner class accessing something in the outer.
-*/
- ic = context-inner_classes[context-this_inner_index];
- if( ic-outer_class )
- {
- Hjava_lang_Class *outer;
- errorInfo einfo;
-
- outer = getClass(ic-outer_class, context, einfo);
- if( outer != NULL )
- {
- if( (target_flags ACC_PRIVATE)
- (target == outer) )
- {
- /* XXX Not sure about this. */
- slot_acc = 1;
- }
- else if( (target_flags ACC_PROTECTED)
-instanceof(target, outer) )
- {
- slot_acc = 1;
- }
- }
- else
- {
- discardErrorInfo(einfo);
- }
- }
- }
return( class_acc slot_acc );
}
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi
Re: [kaffe] Should IllegalAccessException be thrown or not?
From: Ito Kazumitsu [EMAIL PROTECTED] Date: Mon, 12 Dec 2005 13:21:59 +0900 (JST) Sun's JDK (the test programs compiled with ecj): Call a private constructor in the same class OK Call a private constructor in the same pakeage OK (*3) Call a private constructor in another pakeage java.lang.IllegalAccessException: Class A can not access a member of class b.B$PrivateClass with modifiers (*3) Ecj fails to put the private flag to the constructor. This is not a issue of Kaffe, but just for your reference, I found this bug reported in https://bugs.eclipse.org/bugs/show_bug.cgi?id=77473 and the following seems to be due to the same bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=117758 ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] CVS kaffe (kaz): kaffe/kaffevm/access.c
From: Dalibor Topic [EMAIL PROTECTED] Date: Tue, 13 Dec 2005 16:28:43 +0100 * kaffe/kaffevm/access.c (outerof): New function, (checkAccess): Corrected the handling of private access. thanks for the patch, Ito! My pleasure. With this patch applied (and also even without it), the mauve test gnu.testlet.java.lang.Class.newInstance shows the following result. gnu.testlet.java.lang.Class.newInstance PASS: gnu.testlet.java.lang.Class.newInstance (number 1) PASS: gnu.testlet.java.lang.Class.newInstance (number 2) PASS: gnu.testlet.java.lang.Class.newInstance (number 3) PASS: gnu.testlet.java.lang.Class.newInstance (number 4) PASS: gnu.testlet.java.lang.Class.newInstance (number 5) PASS: gnu.testlet.java.lang.Class.newInstance (number 6) PASS: gnu.testlet.java.lang.Class.newInstance (number 7) PASS: gnu.testlet.java.lang.Class.newInstance (number 8) PASS: gnu.testlet.java.lang.Class.newInstance (number 9) FAIL: gnu.testlet.java.lang.Class.newInstance (number 10) PASS: gnu.testlet.java.lang.Class.newInstance (number 11) PASS: gnu.testlet.java.lang.Class.newInstance (number 12) PASS: gnu.testlet.java.lang.Class.newInstance (number 13) PASS: gnu.testlet.java.lang.Class.newInstance (number 14) PASS: gnu.testlet.java.lang.Class.newInstance (number 15) 1 of 15 tests failed The test case #10 is the case where a privtate constructor of an inner class is called from an outer class, that is the problematic case from which this kaffe/kaffevm/access.c case revealed. Sun's JDK passes the test case #10, but as I wrote before, this test should fail and JDK's behavour seems to be wrong. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Should IllegalAccessException be thrown or not?
From: Ito Kazumitsu [EMAIL PROTECTED]
Date: Sun, 11 Dec 2005 10:51:52 +0900 (JST)
The next test case will illustrate this problem more clearly.
$ cat A.java
public class A {
public static void main(String[] args) {
try {
B.getPrivateClass().newInstance();
}
catch (Exception e) {
e.printStackTrace();
}
}
}
$ cat B.java
public class B {
private static class PrivateClass {}
public static Class getPrivateClass() { return PrivateClass.class; }
}
In this case, Sun's JDK throws IllegalAccessException as expected.
But Kaffe does not.
kaffe/kaffevm/access.c has this code:
261 else if( same_package !(target_flags ACC_PRIVATE) )
262 {
263 /* Package. */
264 slot_acc = 1;
265 }
I am afraid this makes anything private in the target class T
accessible to the caller C if T and C are in the same package
and T is accessible to C.
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Should IllegalAccessException be thrown or not?
The test case attached below gives interesting results when run on
various environments. It seems that kaffe, Sun's JDK, and ecj have
some problem of their own.
Kaffe:
Call a private constructor in the same class
OK
Call a private constructor in the same pakeage
OK (*1)
Call a private constructor in another pakeage
java.lang.IllegalAccessException
(*1) Maybe a bug in kaffe/kaffevm/access.c
Sun's JDK (the test programs compiled with Sun's javac):
Call a private constructor in the same class
java.lang.IllegalAccessException: Class A can not access a member of class
A$PrivateClass with modifiers private (*2)
Call a private constructor in the same pakeage
java.lang.IllegalAccessException: Class A can not access a member of class
B$PrivateClass with modifiers private
Call a private constructor in another pakeage
java.lang.IllegalAccessException: Class A can not access a member of class
b.B$PrivateClass with modifiers private
(*2) JDK seems to be missing the fact that the target is declared
within the caller.
Sun's JDK (the test programs compiled with ecj):
Call a private constructor in the same class
OK
Call a private constructor in the same pakeage
OK (*3)
Call a private constructor in another pakeage
java.lang.IllegalAccessException: Class A can not access a member of class
b.B$PrivateClass with modifiers
(*3) Ecj fails to put the private flag to the constructor.
The source of the test case follows.
$ cat A.java
public class A {
private static class PrivateClass {
private PrivateClass() {}
}
public static void main(String[] args) {
System.err.println(Call a private constructor in the same class);
try {
PrivateClass.class.newInstance();
System.err.println(OK);
}
catch (Exception e) {
System.err.println(e);
}
System.err.println(Call a private constructor in the same pakeage);
try {
B.getPrivateClass().newInstance();
System.err.println(OK);
}
catch (Exception e) {
System.err.println(e);
}
System.err.println(Call a private constructor in another pakeage);
try {
b.B.getPrivateClass().newInstance();
System.err.println(OK);
}
catch (Exception e) {
System.err.println(e);
}
}
}
$cat B.java
public class B {
private static class PrivateClass {
private PrivateClass() {}
}
public static Class getPrivateClass() { return PrivateClass.class; }
}
$cat b/B.java
package b;
public class B {
private static class PrivateClass {
private PrivateClass() {}
}
public static Class getPrivateClass() { return PrivateClass.class; }
}
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Should IllegalAccessException be thrown or not?
From: Ito Kazumitsu [EMAIL PROTECTED]
Date: Mon, 12 Dec 2005 11:35:59 +0900 (JST)
kaffe/kaffevm/access.c has this code:
261 else if( same_package !(target_flags ACC_PRIVATE) )
262 {
263 /* Package. */
264 slot_acc = 1;
265 }
I am afraid this makes anything private in the target class T
accessible to the caller C if T and C are in the same package
and T is accessible to C.
Sorry, I missed the !.
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Should IllegalAccessException be thrown or not?
From: Ito Kazumitsu [EMAIL PROTECTED]
Date: Mon, 12 Dec 2005 11:35:59 +0900 (JST)
kaffe/kaffevm/access.c has this code:
261 else if( same_package !(target_flags ACC_PRIVATE) )
262 {
263 /* Package. */
264 slot_acc = 1;
265 }
I am afraid this makes anything private in the target class T
accessible to the caller C if T and C are in the same package
and T is accessible to C.
This is not the case thanks to the ! of !(target_flags ACC_PRIVATE).
But I am afraid
266 else if( (target-name-data[0] != '[')
267 same_package
268 (target-this_inner_index = 0) )
269 {
270 slot_acc = 1;
271 }
will make something private in the target class T accessible to
the caller C if T and C are in the same package and T is a nested
class.
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Should IllegalAccessException be thrown or not?
From: Ito Kazumitsu [EMAIL PROTECTED]
Date: Mon, 12 Dec 2005 15:21:26 +0900 (JST)
But I am afraid
266 else if( (target-name-data[0] != '[')
267 same_package
268 (target-this_inner_index = 0) )
269 {
270 slot_acc = 1;
271 }
will make something private in the target class T accessible to
the caller C if T and C are in the same package and T is a nested
class.
How about this patch?
--- kaffe/kaffevm/access.c.orig Fri Aug 19 15:00:41 2005
+++ kaffe/kaffevm/access.c Mon Dec 12 16:37:15 2005
@@ -153,6 +153,45 @@
}
}
+/*
+ * Returns 1 if oc is an outer class of c
+ */
+static
+int outerof (Hjava_lang_Class *c, Hjava_lang_Class *oc)
+{
+ innerClass *ic;
+ Hjava_lang_Class *outer;
+ errorInfo einfo;
+
+ outer = NULL;
+ if( c-this_inner_index = 0 )
+ {
+ ic = c-inner_classes[c-this_inner_index];
+ if( ic-outer_class )
+ {
+ outer = getClass(ic-outer_class, c, einfo);
+ if( outer == NULL )
+ {
+ discardErrorInfo(einfo);
+ }
+ }
+ }
+ if ( outer != NULL )
+ {
+ if ( oc == outer)
+ {
+ return 1;
+ }
+ else
+ {
+ return outerof(outer, oc);
+ }
+ }
+ else {
+ return 0;
+ }
+}
+
int checkAccess(struct Hjava_lang_Class *context,
struct Hjava_lang_Class *target,
accessFlags target_flags)
@@ -236,6 +275,14 @@
}
}
+ else if ( outerof(target, context) )
+ {
+ /* target is within the context. */
+ class_acc = 1;
+ slot_acc = 1;
+
+ return 1;
+ }
if((context-packageLength == target-packageLength)
!strncmp(context-name-data,
@@ -263,12 +310,17 @@
/* Package. */
slot_acc = 1;
}
+/*
+ Commented out because private members get accessible to
+ any context in the same package if target is a nested class.
+
else if( (target-name-data[0] != '[')
same_package
(target-this_inner_index = 0) )
{
slot_acc = 1;
}
+*/
else if( context-this_inner_index = 0 )
{
innerClass *ic;
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Should IllegalAccessException be thrown or not?
From: Ito Kazumitsu [EMAIL PROTECTED]
Date: Sat, 10 Dec 2005 11:18:13 +0900 (JST)
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
According to 8.8.9 Default Constructor in The Java Language Specification,
if the class is declared private, then the default constructor is
implicitly given the access modifier private.
So IllegalAccessException should be thrown.
The next test case will illustrate this problem more clearly.
$ cat A.java
public class A {
public static void main(String[] args) {
try {
B.getPrivateClass().newInstance();
}
catch (Exception e) {
e.printStackTrace();
}
}
}
$ cat B.java
public class B {
private static class PrivateClass {}
public static Class getPrivateClass() { return PrivateClass.class; }
}
In this case, Sun's JDK throws IllegalAccessException as expected.
But Kaffe does not.
___
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
Re: [kaffe] ecj-compiled kaffe fails in regression tests
From: Ito Kazumitsu [EMAIL PROTECTED] Date: Thu, 08 Dec 2005 11:26:03 +0900 (JST) 4 of 148 tests failed Please report to kaffe@kaffe.org Failed were FAIL: TestSerialVersions.java FAIL: TestSerialPersistent.java FAIL: TestSerialFields.java FAIL: ClassGC.java I ran these tests by compiling with various compilers on various VMs. The resuls are attached below. Seeing the results, I have had an impression that (1) TestSerial* tests have something specific to Kaffe because they never produce expected results when run on Sun's JDK. (2) Ecj may have some bug which causes unexpected results of TestSerial* tests. As Kiyo points, the bug may be similar to one that seems to have existed in old Jikes. (3) Kaffe VM may have something wrong which causes the failure of ClassGC test because Sun's JDK works well. Jikes seems to produce some bytecode which escapes from the proplem. My test results follow. OK: Produces the expected output. NG: Does not Produces the expected output. VMs: kaffe_jikes: kaffe VM 1.1.6+cvs ChangeLog head : 2005-11-04 Guilhem Lavaux [EMAIL PROTECTED] glibj.zip compiled with Jikes. kaffe_ecj: kaffe VM 1.1.6+cvs ChangeLog head : 2005-12-05 Guilhem Lavaux [EMAIL PROTECTED] glibj.zip compiled with ecj. Sun's JDK: java full version 1.5.0_06-b05 Compilers: jikes: Jikes Compiler - Version 1.22 Bootclasspath is glibj.zip of kaffe_jikes. jikes_ecj: Jikes Compiler - Version 1.22 Bootclasspath is glibj.zip of kaffe_ecj. ecj: org.eclipse.jdt.core_3.1.1.jar Bootclasspath is glibj.zip of kaffe_ecj. ecj-jikes: org.eclipse.jdt.core_3.1.1.jar Bootclasspath is glibj.zip of kaffe_jikes. gcj: gcj (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) sun: Sun's javac 1.5.0_06 (-source 1.4 -target 1.4) Compiler\VM kaffe_jikeskaffe_ecj Sun's JDK Test=TestSerialVersions jikes OK OKNG jikes_ecj OK OKNG ecjNG NGNG ecj_jikes NG NGNG gcjOK OKNG sunOK OKNG Test=TestSerialPersistent jikes OK OKNG jikes_ecj OK OKNG ecjNG NGNG ecj_jikes NG NGNG gcjOK OKNG sunNG NGNG Test=TestSerialFields jikes OK OKNG jikes_ecj OK OKNG ecjNG NGNG ecj_jikes NG NGOK gcjOK OKOK sunOK OKNG Test=ClassGC jikes OK OKOK jikes_ecj OK OKOK ecjNG NGOK ecj_jikes NG NGOK gcjNG NGOK sunNG NGOK ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] ecj-compiled kaffe fails in regression tests
Hi Wolfgang, Would you mind to post the patch for your editing of these scripts? This is the last remaining problem before we can switching the debian kaffe package to ecj - currently we cannot run the regression checks. I hope Guilhem's fix will work. My manual editing was a dirty work in haste of getting the results. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] ecj-compiled kaffe fails in regression tests
From: Kiyo Inaba [EMAIL PROTECTED] Date: Thu, 8 Dec 2005 13:54:21 +0900 (JST) Using the following poor man's ecj, $ cat bin/ecj #!/bin/sh exec /usr/local/kaffe/bin/kaffe \ -classpath $HOME/javalib/org.eclipse.jdt.core_3.1.1.jar \ org.eclipse.jdt.internal.compiler.batch.Main \ $@ That's a good news! Could you please add something in 'FAQ.classlibrary- compile' for where we can get the jar file and this script? OK, how about this? --- FAQ/FAQ.classlibrary-compile.orig Wed Sep 21 15:02:00 2005 +++ FAQ/FAQ.classlibrary-compileFri Dec 9 10:55:09 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
From: Ito Kazumitsu [EMAIL PROTECTED] Date: Fri, 09 Dec 2005 09:41:24 +0900 (JST) My test results follow. Sorry, I made mistakes while manually editing the test results. This time I used join to summarize the results: OK: Produces the expected output. NG: Does not Produces the expected output. VMs: kaffe_jikes: kaffe VM 1.1.6+cvs ChangeLog head : 2005-11-04 Guilhem Lavaux [EMAIL PROTECTED] glibj.zip compiled with Jikes. kaffe_ecj: kaffe VM 1.1.6+cvs ChangeLog head : 2005-12-05 Guilhem Lavaux [EMAIL PROTECTED] glibj.zip compiled with ecj. Sun's JDK: java full version 1.5.0_06-b05 Compilers: jikes: Jikes Compiler - Version 1.22 Bootclasspath is glibj.zip of kaffe_jikes. jikes_ecj: Jikes Compiler - Version 1.22 Bootclasspath is glibj.zip of kaffe_ecj. ecj: org.eclipse.jdt.core_3.1.1.jar Bootclasspath is glibj.zip of kaffe_ecj. ecj-jikes: org.eclipse.jdt.core_3.1.1.jar Bootclasspath is glibj.zip of kaffe_jikes. gcj: gcj (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) sun: Sun's javac 1.5.0_06 (-source 1.4 -target 1.4) Test/Compiler kaffe_jikes kaffe_ecj Sun's JDK TestSerialVersions/jikes OK OK NG TestSerialVersions/jikes_ecj OK OK NG TestSerialVersions/ecj NG NG NG TestSerialVersions/ecj_jikes NG NG NG TestSerialVersions/gcj OK OK NG TestSerialVersions/sun OK OK NG TestSerialPersistent/jikes OK OK NG TestSerialPersistent/jikes_ecj OK OK NG TestSerialPersistent/ecj NG NG NG TestSerialPersistent/ecj_jikes NG NG NG TestSerialPersistent/gcj OK OK NG TestSerialPersistent/sun NG NG NG TestSerialFields/jikes OK OK NG TestSerialFields/jikes_ecj OK OK NG TestSerialFields/ecj NG NG NG TestSerialFields/ecj_jikes NG NG NG TestSerialFields/gcj OK OK NG TestSerialFields/sun OK OK NG ClassGC/jikesOK OK OK ClassGC/jikes_ecjOK OK OK ClassGC/ecj NG NG OK ClassGC/ecj_jikesNG NG OK ClassGC/gcj NG NG OK ClassGC/sun NG NG OK ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] ecj-compiled kaffe fails in regression tests
Hi, From: pietro ferrari [EMAIL PROTECTED] Date: Fri, 9 Dec 2005 00:37:17 -0200 On 12/8/05, Ito Kazumitsu [EMAIL PROTECTED] wrote: I hope Guilhem's fix will work. it does, but the 3 serial tests still fail :( Since those test cases compiled with jikes, gcj and Sun's javac almost all (but TestSerialPersistent compiled with Sun's javac) pass, the problem seems to exist in ecj. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] ecj-compiled kaffe fails in regression tests
Hi, From: pietro ferrari [EMAIL PROTECTED] Date: Fri, 9 Dec 2005 00:37:17 -0200 On 12/8/05, Ito Kazumitsu [EMAIL PROTECTED] wrote: I hope Guilhem's fix will work. it does, but the 3 serial tests still fail :( Since those test cases compiled with jikes, gcj and Sun's javac almost all (but TestSerialPersistent compiled with Sun's javac) pass, the problem seems to exist in ecj. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] ecj-compiled kaffe fails in regression tests
From: Ito Kazumitsu [EMAIL PROTECTED] Date: Fri, 09 Dec 2005 12:50:15 +0900 (JST) Since those test cases compiled with jikes, gcj and Sun's javac almost all (but TestSerialPersistent compiled with Sun's javac) pass, the problem seems to exist in ecj. The TestSerial* tests have this comment in common: // XXX output assumes returned test array is consistently sorted... But it seems that when compiled with ecj, the returned test array is NOT consistently sorted. Sort both *.out and *.fail files and compare them, and you will find that they are identical. 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. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] ecj-compiled kaffe fails in regression tests
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. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] ecj-compiled kaffe fails in regression tests
From: Ito Kazumitsu [EMAIL PROTECTED] Date: Fri, 09 Dec 2005 09:41:24 +0900 (JST) I ran these tests by compiling with various compilers on various VMs. The resuls are attached below. Seeing the results, I have had an impression that (1) TestSerial* tests have something specific to Kaffe because they never produce expected results when run on Sun's JDK. 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. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] libraries/javalib/external/classpath/doc/*.info files are missing
Hi, The building of recent CVS version fails with the following message. hacking.texinfo:16: Unknown command `ifnotplaintext'. hacking.texinfo:22: Bad argument to `end', `ifnotplaintext', using `ifinfo'. hacking.texinfo:22: Unmatched [EMAIL PROTECTED]'. makeinfo: Removing output file `hacking.info' due to errors; use --force to preserve. make[4]: *** [hacking.info] Error 1 I am afraid my makeinfo is too old. $ makeinfo --version makeinfo (GNU texinfo) 4.1 But when I tried to get a newer makeinfo, I found a file named makeinfo.README saying | makeinfo is part of the texinfo distribution. | Get texinfo-*.tar.gz. | | However, all GNU distributions should come with prebuilt info files, | thus makeinfo should not be needed. If you notice a distribution | that does not come with *.info files, please report it as a bug. Since Kaffe's CVS tree is not a GNU distribution, *.info files being missing may not be a bug. But I think there sould be some comment on the required texinfo version. ___ 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
Hi Kiyo, The building of recent CVS version fails with the following message. You met same problem as I faced (and reported titled 'build failure for nb1.6') several days ago. Sorry for missing your message. I did not think that would be a problem to me. | However, all GNU distributions should come with prebuilt info files, | thus makeinfo should not be needed. If you notice a distribution | that does not come with *.info files, please report it as a bug. Since Kaffe's CVS tree is not a GNU distribution, *.info files being missing may not be a bug. But I think there sould be some comment on the required texinfo version. I have not checked the contents of this documentation, but my feeling is (even if Kaffe is not part of GNU distribution) this should be a bug :-) If noone has objection to put prebuilt *.info file into CVS, I will do that in this weekend. It is OK for me. But external/classpath comes from GNU Classpath, so the problem is wheher GNU Classpath should keep prebuilt info files in their CVS repository. GNU Classpath is a GNU distribution, so released GNU Classpath packages must have prebuilt info files, of course. But whether or not they should always be kept in the CVS repository may be another question. Anyway I will ask GNU Classpath. BTW, Kaz, what is the build environment for this. Since it is ok with linux-2.4.18 based redhat (maybe RH7.2?). My problematic environment is also a linux-2.4.18 based redhat. Haven't you installed a newer texinfo by chance? ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] ecj-compiled kaffe fails in regression tests
Using the following poor man's ecj, $ cat bin/ecj #!/bin/sh exec /usr/local/kaffe/bin/kaffe \ -classpath $HOME/javalib/org.eclipse.jdt.core_3.1.1.jar \ org.eclipse.jdt.internal.compiler.batch.Main \ $@ I could make kaffe from kaffe-snapshot-20051206.tar.gz from http://people.debian.org/~avdyk/kaffe/snapshot/. After manually editing some script files, I managed to run make check, but the results were 4 of 148 tests failed Please report to kaffe@kaffe.org Failed were FAIL: TestSerialVersions.java FAIL: TestSerialPersistent.java FAIL: TestSerialFields.java FAIL: ClassGC.java Attached are the diff outputs of *.fail and *.out. Recompiling the sources of test programs with jikes and running them with ecj-compiled glibj.zip gives good results. 0.diff.gz Description: Binary data ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] CVS kaffe (guilhem): Fix to be able to use ECJ instead of JIKES.
From: Kaffe CVS [EMAIL PROTECTED] Date: Sat, 03 Dec 2005 05:04:09 -0800 Fix to be able to use ECJ instead of JIKES. Being an old-fashined programmer, I am not interested in Eclipse, but would like to try ECJ because JIKES seems to be inactive now. Unfortunately, I can not find out where I can get ECJ. Is ECJ equivalent to java -jar org.eclipse.jdt.core_3.1.1.jar? Isn't it stupid to get 100MB of Eclipse to use 3MB of JDT core? ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] libraries/javalib/vmspecific/gnu/java/nio/charset
Hi, Now that our fixes have been accepted by GNU Classpath, the following files are not needed any more. libraries/javalib/vmspecific/gnu/java/nio/charset/ UTF_16Decoder.java UnicodeLittle.java iconv/IconvProvider.java What should I do? ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] --without-classpath-gtk-awt ignored
From: Gianluca Moro [EMAIL PROTECTED] Date: Sun, 23 Oct 2005 23:44:41 -0700 (PDT) try adding --disable-native-awt Thank you. This worked. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] classpath _merged_
From: Ito Kazumitsu [EMAIL PROTECTED] Date: Sat, 22 Oct 2005 01:25:29 +0900 (JST) Thrillingly enough, on my FreeBSD 5.5-RELEASE, I mean FreeBSD 5.4-RELEASE. FAIL: TestSerializable2.java FAIL: SerialPersistentFields.java FAIL: TestSerialPersistent.java FAIL: SerialUID.java FAIL: Alias.java FAIL: HashTest.java FAIL: SecureRandomTest.java Thanks to Dalibor's fix, now all tests pass. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] --without-classpath-gtk-awt ignored
Hi, I have got the following error while doing ./configure \ --without-classpath-gtk-awt \ --without-kaffe-qt-awt \ --enable-debug in an environment where neither GTK nor X is available. checking for X... no configure: error: GTK+ peers requested but no X library available configure: error: /bin/sh './configure' failed for libraries/javalib/external/classpath ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] CVS kaffe (kaz): libraries/javalib/external/classpath/gnu/java/nio/charset/UTF_16Decoder.java,
Hi, I think that when you are not a developper it's better to submit them to the web site. In your case I don't remember whether you have the access rights to the CVS. If it's so then you can send your patches to classpath-patches and after a review check it in into the CVS. If not I'll do it. I do not have the access rights to CVS. Would you please do it? ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] classpath _merged_
Hi, From: Guilhem Lavaux [EMAIL PROTECTED] Date: Wed, 19 Oct 2005 22:55:35 +0200 The classpath tree has been merged. I know that it builds, runs regression tests install peacefully here but I haven't yet tested make dist. If there are problems they will be fixed progressively. Thrillingly enough, on my FreeBSD 5.5-RELEASE, 7 of 148 tests failed Please report to kaffe@kaffe.org FAIL: TestSerializable2.java FAIL: SerialPersistentFields.java FAIL: TestSerialPersistent.java FAIL: SerialUID.java FAIL: Alias.java FAIL: HashTest.java FAIL: SecureRandomTest.java I will look into them one by one. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] classpath _merged_
Hi, From: Guilhem Lavaux [EMAIL PROTECTED] Date: Wed, 19 Oct 2005 22:55:35 +0200 The classpath tree has been merged. I know that it builds, runs regression tests install peacefully here but I haven't yet tested make dist. If there are problems they will be fixed progressively. In my case, it did not build. configure: error: cannot run /usr/local/bin/bash ./config.sub configure: error: /usr/local/bin/bash './configure' failed for libraries/javalib/external/classpath ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] CVS kaffe (kaz): libraries/javalib/external/classpath/gnu/java/nio/charset/UTF_16Decoder.java,
Hi, From: Guilhem Lavaux [EMAIL PROTECTED] Date: Thu, 20 Oct 2005 20:59:38 +0200 Could you push your patch yourself on classpath-patches ml ? :) I could do it but it is maybe better if you do it. I reported the bugs and submitted the patches to Savannah last June, and the bugs are still open. Which is the right place to submit patchs? classpath-patches? commit-classpath? Or the bug reporting web site? ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Problem with Strings/Xml Parsing while trying to run an embedded Jetty
From: Rafael Teixeira [EMAIL PROTECTED] Date: Tue, 18 Oct 2005 10:45:06 -0200 Also when Jetty is trying to read the configuration xmls, DTD aren't being correctly loaded in the sax validator: INFO: Version Jetty/5.1.x org.xml.sax.SAXParseException: Element type 'web-app' was not declared Again the same configuration files embedded in the jar run fine in Sun's VM and Jetty gets started and runs my web-app... The web-app not being accepted is the one in my WEB-INF/web.xml that uses another DTD, that indeed should accept 'web-app' !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; By disabling xerces, I could reproduce the same error: org.xml.sax.SAXParseException: Element type 'web-app' was not declared. I've put some diagnostic printlns inside the gnu.xml.pipeline.ValidationConsumer.startElement method that is raising the error, and surely it looks like the DTDs isn't being loaded as it list of valid elements is empty at start (it adds the offending item to the list so that it can continue to validate without reissuing the same error for similar itens, so the list grows during the execution). I am afraid gnu.xml package is not mature enough as a validating XML parser. Much work will be needed to make it stable. So again looks like some other problem (I guess again with string manipulation) may be precluding the DTDs from being parsed/loaded and so the other errors appear. Switching the SAX parser to xerces solves the problem. So I think the problem exists in gnu.xml package. Suggested workaround for now is either (1) Use xerces. Xerces comes with Jetty and it can be activated by setting the system property javax.xml.parsers.SAXParserFactory to org.apache.xerces.jaxp.SAXParserFactoryImpl or (2) Do not try to validate the configuration XML files. Jetty will not validate the XML files if the system property org.mortbay.xml.XmlParser.NotValidating is set to true. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Problem with Strings/Xml Parsing while trying to run an embedded Jetty
Hi,
Let's discuss the problem of System.out.println first.
From: Rafael Teixeira [EMAIL PROTECTED]
Date: Tue, 18 Oct 2005 10:45:06 -0200
usr/bin/kaffe -jar
../../../java/inteligenciafiscal/inteligenciafiscal.jar
Software B\usico do M\udulo Fiscal de Seguran
Vers\uo: 01.00.00
But alas if you want the code:
private void _Iniciar(String[] args)
{
System.out.println(Software Básico do Módulo Fiscal
de Segurança);
System.out.print(Versão: );
System.out.println(VersãoDesteSoftwareBásico);
...
It is on a utf-8 encoded source, edited and compiled with Eclipse 3.0
(what I think it means it is compiled with Sun's Javac).
I wrote this:
public class TestLatin1 {
public static void main(String[] args) {
System.out.println(Software Básico do Módulo Fiscal de Segurança);
System.out.flush();
}
}
Then I compiled it with Sun's Javac using the command:
javac -encoding UTF-8 TestLatin1.java
And ran the class file with kaffe:
$ kaffe TestLatin1
Software Básico do Módulo Fiscal de Segurança
I do not see any problem.
I compile it into a fatjar(with onejar). And start with:
java -jar myfatjar.jar
or
kaffe -jar myfatjar.jar
I also made an executable jar file. And got the same result:
$ kaffe -jar foo.jar
Software Básico do Módulo Fiscal de Segurança
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Problem with Strings/Xml Parsing while trying to run an embedded Jetty
From: Rafael Teixeira [EMAIL PROTECTED] Subject: [kaffe] Problem with Strings/Xml Parsing while trying to run an embedded Jetty Date: Fri, 14 Oct 2005 13:56:10 -0300 Anyway the EclipseOnJDK5-compiled code have problem with accented letters when printing them to the console only in kaffe: usr/bin/kaffe -jar ../../../java/inteligenciafiscal/inteligenciafiscal.jar Software B\usico do M\udulo Fiscal de Seguran Vers\uo: 01.00.00 Would you please show the source code printing this text? I do not see why kaffe cannot print Europian characters while it can print Japanese characters correctly. Also when Jetty is trying to read the configuration xmls, DTD aren't being correctly loaded in the sax validator: INFO: Version Jetty/5.1.x org.xml.sax.SAXParseException: Element type 'web-app' was not declared Would you please show the configuration file? I am running Jetty 5.1.4 with kaffe without problem. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] strange problem - jvm exits with OutOfMemoryError
the exact command i used is /home/siddharth/kaffe-1.1.5/bin/java -Xms32m -Xmx32m loop The VM exits with OutofMemory with following error message Throwing OutOfMemoryError is not implemented in Boehm-GC. Aborted In my case, the program ended normally. ... 9995 9996 9997 9998 $ Kaffe version: Engine: Just-in-time v3 Version: 1.1.x-cvs Java Version: 1.4 Heap defaults: minimum size: 5 MB, maximum size: 64 MB Stack default size: 256 KB Configuration/Compilation options: ) Compile date : Mon Jul 4 10:00:20 JST 2005 Install prefix : /usr/local/kaffe Thread system: unix-pthreads Garbage Collector: kaffe-gc CC : gcc CFLAGS : -g -O2 -Wall -pthread -DENABLE_BINRELOC LDFLAGS : ChangeLog head : 2005-06-29 Guilhem Lavaux [EMAIL PROTECTED] OS: Linux 2.4.18-3 ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Prevayler works
Hi,
Compatibility - Application Testing
(http://www.kaffe.org/compatibility_applications.shtml) says,
| 2. Prevayler
|
|Status: Partially works.
|
|See this post by Ito Kazumitsu for more information.
And my old post says,
| With the following patch to prevayler2.01.000alpha,
|
| --- src/org/prevayler/foundation/DurableOutputStream.java Wed Mar 3
19:04:38 2004
| +++ test/org/prevayler/foundation/DurableOutputStream.java Sat Apr 3
10:00:30 2004
| @@ -104,7 +104,7 @@
|
| synchronized void setSynched() {
| _isSynched = true;
| - synchronized (this) { notifyAll(); }
| + notifyAll();
| }
| }
|
|
| the simplest demo of prevayler works fine.
|
| This makes me think that there is something wrong around
| kaffe/kaffevm/locks.c.
I don't whether there is anything wrong in kaffe, but now
prevayler-2.02.006 does not have this problematic coding.
So now Prevayler works fine with Kaffe.
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] InputStream#available() for System.in throws IOException
From: Ito Kazumitsu [EMAIL PROTECTED] Subject: Re: [kaffe] InputStream#available() for System.in throws IOException Date: Tue, 30 Aug 2005 13:57:07 +0900 (JST) So here is my proposed patch. I am checking this in. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] InputStream#available() for System.in throws IOException
Hi,
The program attached below throws java.io.IOException when run with
current CVS version of Kaffe.
Case 1: Terminal input
$ kaffe TestBufferedReader
java.io.IOException: No such file or directory
at gnu.java.nio.channels.FileChannelImpl.available (FileChannelImpl.java)
at java.io.FileInputStream.available (FileInputStream.java:165)
at java.io.FilterInputStream.available (FilterInputStream.java:129)
at java.io.BufferedInputStream.read (BufferedInputStream.java:276)
at java.io.FilterInputStream.read (FilterInputStream.java:173)
at java.io.InputStreamReader.read (InputStreamReader.java:395)
at java.io.BufferedReader.fill (BufferedReader.java:373)
at java.io.BufferedReader.readLine (BufferedReader.java:475)
at TestBufferedReader.main (TestBufferedReader.java:12)
java.io.IOException: No such file or directory
Case 2: Pipe
$ echo | kaffe TestBufferedReader
java.io.IOException: No such file or directory
at gnu.java.nio.channels.FileChannelImpl.available (FileChannelImpl.java)
at java.io.FileInputStream.available (FileInputStream.java:165)
at java.io.FilterInputStream.available (FilterInputStream.java:129)
at java.io.BufferedInputStream.read (BufferedInputStream.java:276)
at java.io.FilterInputStream.read (FilterInputStream.java:173)
at java.io.InputStreamReader.read (InputStreamReader.java:395)
at java.io.BufferedReader.fill (BufferedReader.java:373)
at java.io.BufferedReader.readLine (BufferedReader.java:475)
at TestBufferedReader.main (TestBufferedReader.java:12)
java.io.IOException: No such file or directory
Case 3: File input - OK
$ kaffe TestBufferedReader TestBufferedReader.java
$
Case 4: Here document - OK
$ kaffe TestBufferedReader EOF
EOF
$
This error occurs on both FreeBSD and Linux.
Slight differences among operating systems are:
(1) On Linux 2.6.7-co-0.6.2, the message of the IOException is
Success instead of No such file or directory.
(2) On Linux 2.4.18-3, instead of throwing IOException, the program
seems to go into a deadlock. But giving an argument to the
program, we see the same IOException.
$ echo | kaffe TestBufferedReader US-ASCII
java.io.IOException: No such file or directory
at gnu.java.nio.channels.FileChannelImpl.available (FileChannelImpl.java)
at java.io.FileInputStream.available (FileInputStream.java:165)
...
And here is the program for testing.
import java.io.*;
public class TestBufferedReader {
public static void main(String[] args) throws Exception {
try {
BufferedReader rdr = new BufferedReader(
(args.length 0 ?
new InputStreamReader(System.in, args[0]) :
new InputStreamReader(System.in)));
while (true) {
String s = rdr.readLine();
if (s == null) break;
}
}
catch (Exception e) {
e.printStackTrace();
throw e;
}
}
}
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] InputStream#available() for System.in throws IOException
From: Ito Kazumitsu [EMAIL PROTECTED]
Subject: [kaffe] InputStream#available() for System.in throws IOException
Date: Tue, 30 Aug 2005 01:54:52 +0900 (JST)
Case 1: Terminal input
$ kaffe TestBufferedReader
java.io.IOException: No such file or directory
Case 2: Pipe
$ echo | kaffe TestBufferedReader
java.io.IOException: No such file or directory
Case 3: File input - OK
$ kaffe TestBufferedReader TestBufferedReader.java
Case 4: Here document - OK
$ kaffe TestBufferedReader EOF
EOF
The message text of the IOException is meaningless.
This IOException comes from the macro TARGET_NATIVE_FILE_AVAILABLE
defined in libraries/clib/target/Linux/target_native_file.h.
If the standard input is piped to another process or it is a
character device, KFSTAT(filedescriptor,__statBuffer) returns 0
but S_ISREG(__statBuffer.st_mode) is false because it is not a
regular file.
The solution may be either
(a) if S_ISREG(__statBuffer.st_mode) is false, try other
methods as libraries/clib/nio/FileChannelImpl.c did before.
or
(b) if S_ISREG(__statBuffer.st_mode) is false, give up trying
to figure out available length and just return 0.
I think (b) is simple and reasonable enough. Running the following
program on Sun's JDK,
public class TestAvailable {
public static void main(String[] args) throws Exception {
System.out.println(System.in.available());
}
}
I find Sun's System.in.available() often returns 0 if the standerd
input is a terminal or is piped to another process.
So here is my proposed patch.
--- libraries/clib/target/Linux/target_native_file.h.orig Fri Aug 5
10:20:19 2005
+++ libraries/clib/target/Linux/target_native_file.hTue Aug 30 13:31:24 2005
@@ -138,18 +138,26 @@
\
length=0; \
\
-if ((KFSTAT(filedescriptor,__statBuffer)==0)
S_ISREG(__statBuffer.st_mode)) \
+if (KFSTAT(filedescriptor,__statBuffer)==0) \
{ \
- int klseek_result; \
- klseek_result=(KLSEEK(filedescriptor,0,SEEK_CUR, __n)); \
- if (klseek_result == 0) \
+ if (S_ISREG(__statBuffer.st_mode)) \
{ \
-
length=TARGET_NATIVE_MATH_INT_INT32_TO_INT64(__statBuffer.st_size-__n); \
-result=TARGET_NATIVE_OK; \
+int klseek_result; \
+klseek_result=(KLSEEK(filedescriptor,0,SEEK_CUR, __n)); \
+if (klseek_result == 0) \
+{ \
+
length=TARGET_NATIVE_MATH_INT_INT32_TO_INT64(__statBuffer.st_size-__n); \
+ result=TARGET_NATIVE_OK; \
+} \
+else \
+{ \
+ result=TARGET_NATIVE_ERROR; \
+} \
} \
else \
{ \
-result=TARGET_NATIVE_ERROR; \
+ length=TARGET_NATIVE_MATH_INT_INT32_TO_INT64(0); \
+ result=TARGET_NATIVE_OK; \
} \
} \
else \
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] xargs -i
Hi,
The following line Makefile.am causes error on FreeBSD.
echo
KAFFELIBRARYPATH=\$${KAFFELIBRARYPATH+\\$$KAFFELIBRARYPATH\\''$(PATHSEP)'\'}`for
f in $(JAVA_LIBS); do echo $$f | sed 's%/[^/]*$$%%' | xargs -n 1 -iXXX echo
XXX/.libs; done | (tr '\012' ' '; echo) | sed -e 's/ $$//' -e s/
/\'$(PATHSEP)\'/g`\; export KAFFELIBRARYPATH BUILD_ENVIRONMENT.new; \
xargs -i is specific to GNU version of xargs, and FreeBSD's xargs
does not accept that option. I had to install GNU's findutils-4.2.23
to make all the tests pass.
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] config/i386/freebsd2/md.c
Hi, Today's make on FreeBSD 5.4-RELEASE faild while compiling config/i386/freebsd2/md.c. In file included from ../../config/i386/freebsd2/md.c:17, from md.c:1: /usr/include/sys/sysctl.h:637: error: syntax error before u_int gmake[2]: *** [libkaffevm_la-md.lo] Error 1 ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] NetworkInterfaceTest fails on Linux 2.4.18-3
Hi, NetworkInterfaceTest fails when run on Linux 2.4.18-3. $ kaffe -fullversion ... Engine: Just-in-time v3 Version: 1.1.x-cvs Java Version: 1.4 Heap defaults: minimum size: 5 MB, maximum size: unlimited Stack default size: 256 KB Configuration/Compilation options: ) Compile date : Wed Aug 10 16:59:59 JST 2005 Compile host : Install prefix : /home/ito/kaffe/inst Thread system: unix-pthreads Garbage Collector: kaffe-gc CC : gcc CFLAGS : -g -O2 -Wall -pthread -DENABLE_BINRELOC LDFLAGS : ChangeLog head : 2005-08-02 Ito Kazumitsu [EMAIL PROTECTED] $ uname -a Linux 2.4.18-3 #1 Thu Apr 18 07:37:53 EDT 2002 i686 unknown $ cat test/regression/NetworkInterfaceTest.fail /home/ito/kaffe/kaffe-snap-050804/kaffe/kaffe/.libs/lt-kaffe-bin: relocation error: /home/ito/kaffe/kaffe-snap-050804/libraries/clib/net/.libs/libnet-1.1.x-cvs.so: undefined symbol: getifaddrs $ nm replace/.libs/getifaddrs.o $ Formerly, nm showed $ nm ../kaffe-snap-050630/replace/.libs/getifaddrs.o U _GLOBAL_OFFSET_TABLE_ U __errno_location U bind U calloc U close U free 0590 t free_data 0520 t free_nlmsglist 12e0 T freeifaddrs 0640 T getifaddrs U getpid 0060 t ifa_make_sockaddr t ifa_sa_len U malloc U memcpy U memset 05f0 t nl_close 00f0 t nl_getlist U realloc U recvmsg U sendto U socket U strncpy U time ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Kaffe treats extended abstract redefinition incorrectly [Tiny Test Case attached]
Hi, From: David Tiller [EMAIL PROTECTED] Subject: [kaffe] Kaffe treats extended abstract redefinition incorrectly [Tiny Test Case attached] Date: Thu, 11 Aug 2005 08:00:54 -0400 When run under kaffe-1.1.5, the following is output: In Class1 method. java.lang.VerifyError: No code attribute for Class2.method. at Class2.init (Class2.java:8) at Class2.init (Class2.java:4) at Class2.init (Class3.java:3) at Main.main (Main.java:3) I tried this with the current CVS version of Kaffe, and did not see this error. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] NetworkInterfaceTest fails on Linux 2.4.18-3
NetworkInterfaceTest fails when run on Linux 2.4.18-3. $ cat test/regression/NetworkInterfaceTest.fail /home/ito/kaffe/kaffe-snap-050804/kaffe/kaffe/.libs/lt-kaffe-bin: relocation error: /home/ito/kaffe/kaffe-snap-050804/libraries/clib/net/.libs/libnet-1.1.x-cvs.so: undefined symbol: getifaddrs $ nm replace/.libs/getifaddrs.o $ The following patch worked at least for me. ** --- replace/getifaddrs.c.orig Mon Jul 18 03:01:00 2005 +++ replace/getifaddrs.cFri Aug 12 11:24:25 2005 @@ -36,6 +36,8 @@ #define __close(x) close(x) #endif +#include ifaddrs_linux.c + #elif defined(SIOCGIFCONF) #include ifaddrs_bsd.c ** Is the deletion of ifaddrs_linux.c intentional, or by accident? ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] File order bug - Testcase
From: Wolfgang Baer [EMAIL PROTECTED]
Subject: Re: [kaffe] File order bug - Testcase
Date: Wed, 10 Aug 2005 09:31:57 +0200
yes the API does not specify an order. However, as the unit testcases
of logkit show, some programs depend on the SUN behaviour.
This is why I found this bug and I think kaffe should follow what Sun
does (and the other gnu classpath vms).
OK, how about this?
--- libraries/clib/io/File.c.orig Sun Dec 26 14:52:34 2004
+++ libraries/clib/io/File.cWed Aug 10 17:40:36 2005
@@ -207,6 +207,7 @@
};
struct dentry* dirlist;
struct dentry* mentry;
+ struct dentry* lastentry;
HArrayOfObject* array;
int count;
int i;
@@ -221,6 +222,7 @@
}
dirlist = NULL;
+ lastentry = NULL;
count = 0;
/* XXX make part of jsyscall interface !? */
while ((entry = readdir(dir)) != NULL) {
@@ -242,8 +244,14 @@
throwError(info);
}
strcpy(mentry-name, entry-d_name);
-mentry-next = dirlist;
-dirlist = mentry;
+mentry-next = NULL;
+if (count == 0) {
+dirlist = mentry;
+}
+else {
+lastentry-next = mentry;
+}
+lastentry = mentry;
count++;
}
/* XXX make part of jsyscall interface !? */
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] File order bug - Testcase
From: Wolfgang Baer [EMAIL PROTECTED] Subject: [kaffe] File order bug - Testcase Date: Tue, 09 Aug 2005 22:01:42 +0200 here is the testcase. kaffe behaves differently than all other implementations in the order the files are listed. Seeing libraries/clib/io/File.c, I understand how the order of files is reversed. But, however strange Kaffe's result looks, I do not think it is Kaffe's bug. Sun's API document of java.io.File#listFiles() says: There is no guarantee that the name strings in the resulting array will appear in any specific order; they are not, in particular, guaranteed to appear in alphabetical order. So we must not depend on the order of files java.io.File#listFiles() returns. That said, I think it would be better if we could make Kaffe's result look similar to Sun's. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] CVS kaffe (kaz): test/regression/BufferedInputStreamAvailableTest.java:
Hi Dalibor, I've removed the ioctl based implementation of avail in the target layer since Kaffe does not have a thread safe ioctl wrapper, and I did not want to introduce one without need. All tests passed on FreeBSD 5.4-RELEASE today. Thank you. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Apache Jakarta Commons Net does not work on Linux
From: Ito Kazumitsu [EMAIL PROTECTED]
Subject: [kaffe] Apache Jakarta Commons Net does not work on Linux
Date: Tue, 02 Aug 2005 00:10:49 +0900 (JST)
I have found that apache Jakarta Commons Net does not work
with current Kaffe on Linux.
I slightly changed the test program to find the following.
(1) Telnet client including FTP client of Apache Commons Net
performs its socket input operation in a different thread
called reader thread.
(2) When run on Kaffe on Linux, there seems to occur a deadlock
between the reader thread and the current thread. The writing
operation of the current thread cannot be finished until some
state of the reader thread changes. But the reading thread is
waiting for a response from the server, which will never come
until the writing operation of the current thread is finished.
(3) Such deadlock does not occur when run on Sun's JDK
or on Kaffe on FreeBSD.
(4) By setting some socket timeout value, the deadlock of (2)
can be releasd. But such timeout means the death of the reading
thread and this cannot be a solusion of the problem.
And on Linux 2.6.7-co-0.6.2, setting a timeout causes another
error like
$ java TestCommonsNet somehost foo bar 5000 true
220
kaffe-bin: pthread_mutex_lock.c:78: __pthread_mutex_lock: Assertion
`mutex-__data.__owner == 0' failed.
Aborted
(5) Telnet client including FTP client of Apache Commons Net has
an option of disabling the use of reader thread. This helps
to avoid the deadlock of (2).
Application system users can be satisfied with (5), but the problem
(2) seen only on Kaffe on Linux indicates some bugs in Kaffe.
My test program follows.
import org.apache.commons.net.ftp.*;
public class TestCommonsNet {
public static void main(String[] args) throws Exception {
String hostName = args[0];
int port = 21;
String userName = args[1];
String password = args[2];
int timeout = Integer.parseInt(args[3]);
boolean readerThread = (args[4].equals(true));
FTPClient _ftpClient = new FTPClient();
_ftpClient.setDefaultTimeout(timeout);
_ftpClient.setReaderThread(readerThread);
_ftpClient.connect(hostName, port);
System.err.println(_ftpClient.getReplyCode());
_ftpClient.login(userName, password);
System.err.flush();
System.err.println(_ftpClient.getReplyCode());
_ftpClient.logout();
System.err.println(_ftpClient.getReplyCode());
}
}
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Apache Jakarta Commons Net does not work on Linux
Hi Guilhem, Thank you for looking into my problem. From: Guilhem Lavaux [EMAIL PROTECTED] Subject: Re: [kaffe] Apache Jakarta Commons Net does not work on Linux Date: Wed, 03 Aug 2005 19:10:21 +0200 Btw, I haven't got the assert error you mentioned. It should be a problem in the libc itself as I am not tweaking the mutexes but on the contrary raising protections around them. (What is Linux 2.6.7-co-0.6.2 ?) I haven't got the assert error, either, on another Linux machine. Cooperative Linux (short-named coLinux) is a Linux which runs on Microsoft Windows (http://www.colinux.org/). Being a FreeBSD user not skilled in Linux, I bought a package of coLinux and installed it on a Windows XP machine, which serves as an X terminal of my FreeBSD machine. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] CVS kaffe (kaz): test/regression/BufferedInputStreamAvailableTest.java:
From: Kaffe CVS [EMAIL PROTECTED] Subject: [kaffe] CVS kaffe (kaz): test/regression/BufferedInputStreamAvailableTest.java: Date: Tue, 02 Aug 2005 09:29:24 -0700 BufferedInputStream is = new BufferedInputStream( new FileInputStream(file), (int)flen); int alen = is.available(); - System.out.println((int)flen == alen); + // System.out.println((int)flen == alen); + // We are happy if (int)flen == alen, but that is not necessarily true. + System.out.println(alen = 0); I added this test in order to know whether the problem about FreeBSD's ioctl (http://www.kaffe.org/pipermail/kaffe/2005-July/103009.html) has been solved. But this test failed on Linux 2.6.7-co-0.6.2 because available() returned 1. So I changed the test criterion. By the way, isn't it a problem that available() returns 1 when a several hundred byte file is being read? ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Apache Jakarta Commons Net does not work on Linux
Hi,
I have found that apache Jakarta Commons Net does not work
with current Kaffe on Linux.
Test program:
$ cat TestCommonsNet.java
import org.apache.commons.net.ftp.*;
public class TestCommonsNet {
public static void main(String[] args) throws Exception {
String hostName = args[0];
int port = 21;
String userName = args[1];
String password = args[2];
FTPClient _ftpClient = new FTPClient();
_ftpClient.connect(hostName, port);
System.err.println(_ftpClient.getReplyCode());
_ftpClient.login(userName, password);
System.err.println(_ftpClient.getReplyCode());
_ftpClient.logout();
System.err.println(_ftpClient.getReplyCode());
}
}
Result on FreeBSD 5.4-RELEASE is good.
$ kaffe -classpath commons-net-1.4.0.jar:. TestCommonsNet somehost foo bar
220
530
221
$
Result on Linux 2.6.7-co-0.6.2
$ kaffe -classpath commons-net-1.4.0.jar:. TestCommonsNet somehost foo bar
220
^C(I cannot help but kill the process)
If I remember correctly, I used to run Jakarta Commons Net with
Kaffe 1.1.4 on some Linux machine.
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] SecureRandomTest failed
From: Ito Kazumitsu [EMAIL PROTECTED]
Subject: Re: [kaffe] SecureRandomTest failed
Date: Sun, 24 Jul 2005 08:18:31 +0900 (JST)
java.io.IOException: Inappropriate ioctl for device
I am afraid that on FreeBSD, ioctl with FIONREAD cannot
be used for file IO.
The following simple program shows errno == 25 (Inappropriate ioctl
for device).
#include sys/ioctl.h
#include sys/filio.h
#include errno.h
#include fcntl.h
int main(int argc, char* argv) {
int n;
int fd;
fd = open(test.c, O_RDONLY);
int rc = ioctl(fd,FIONREAD,n);
printf(%d, %d\n, rc, errno);
}
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] SecureRandomTest failed
Hi Guilhem,
From: Guilhem Lavaux [EMAIL PROTECTED]
Subject: Re: [kaffe] SecureRandomTest failed
Date: Sat, 23 Jul 2005 09:01:01 +0200
Thanks for the analysis. Actually with your second report I have feared
that the providers in java.security were not loaded. It apparently is
the case as you have reported. It would be interesting if you have some
time for this to check what happens in java.security.Security.clinit
and loadProviders. I know that some exceptions are hidden there and
these functions are in charge of loading the providers.
Yes, inserting System.err.prinln() into java/security/Security.java,
I got:
loadProviders loading: file:///path-to-kaffe/jre/lib/security/Kaffe.security
loadProviders caught java.io.FileNotFoundException: No such file or directory
loadProviders loading: file:///path-to-kaffe/jre/lib/security/java.security
loadProviders caught java.io.IOException: Inappropriate ioctl for device
loadProviders loading: file:///path-to-kaffe/jre/lib/security/classpath.security
loadProviders caught java.io.FileNotFoundException: No such file or directory
So the cause of error is java.io.IOException: Inappropriate ioctl for device.
This is my simplified test case:
$ cat URLTest.java
import java.io.*;
import java.net.URL;
public final class URLTest
{
public static void main(String[] args)
{
String filestr = args[0];
try
{
System.err.println(loading: + filestr);
InputStream fin = new URL(filestr).openStream();
BufferedReader reader =
new BufferedReader(new InputStreamReader(fin, ISO-8859-1));
String line;
while ((line = reader.readLine()) != null)
{
}
}
catch (IOException e)
{
e.printStackTrace();
}
}
}
$ path-to-kaffe/bin/java URLTest
file:///path-to-kaffe/jre/lib/security/java.security
loading: file:///path-to-kaffe/jre/lib/security/java.security
java.io.IOException: Inappropriate ioctl for device
at gnu.java.nio.channels.FileChannelImpl.available (FileChannelImpl.java)
at java.io.FileInputStream.available (FileInputStream.java:165)
at java.io.FilterInputStream.available (FilterInputStream.java:129)
at java.io.BufferedInputStream.read (BufferedInputStream.java:276)
at java.io.FilterInputStream.read (FilterInputStream.java:173)
at java.io.InputStreamReader.read (InputStreamReader.java:395)
at java.io.BufferedReader.fill (BufferedReader.java:373)
at java.io.BufferedReader.readLine (BufferedReader.java:475)
at URLTest.main (URLTest.java:15)
Using URL here seems to be significant. Changing the test program so that
it uses FileInputStream instead of URL.openStream(), I got no exception.
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] SecureRandomTest failed
I am afraid something has changed so that Security.getProviders() returns
gnu.java.security.provider.Gnu: name=GNU version=1.0
before
kaffe.security.provider.Kaffe: name=KAFFE version=1.0
Yes, gnu.java.security.provider.Gnu comes first. But that depends
on the environment.
I have found two independent problems related to this issue.
(1) In some environment, e.g. my case with FreeBSD 5.4-RELEASE,
Security.getProviders() by default lists only
gnu.java.security.provider.Gnu. So if you add
kaffe.security.provider.Kaffe, it is listed after
gnu.java.security.provider.Gnu.
But in another environment, Security.getProviders() by default lists
gnu.crypto.jce.GnuCrypto
org.metastatic.jessie.provider.Jessie
kaffe.security.provider.Kaffe
gnu.java.security.provider.Gnu
in this order. So if you add kaffe.security.provider.Kaffe,
it is not added because it is already there.
Older Kaffe on FreeBSD 5.4-RELEASE also behaved this way.
(2) The SHA1PRNG algorithm provided by gnu.java.security.provider.Gnu
is not secure enough because differnt instances always produce the
same result. So in an environment where the problem (1) exists,
SecureRandomTest fails.
To study this problem, I patched SecureRandomTest.java for debuging.
--- SecureRandomTest.java.orig Thu Feb 24 23:42:08 2005
+++ SecureRandomTest.java Sat Jul 23 05:52:43 2005
@@ -64,6 +64,10 @@
byte data[];
Security.addProvider(new kaffe.security.provider.Kaffe());
+ Provider[] pp = Security.getProviders();
+ for (int i=0; i pp.length; i++) {
+ System.err.println(pp[i]);
+ }
/*
* Make sure the SecureRandom's produce different sequences after
Then I tested this program on FreeBSD 5.4-RELEASE and Linux 2.6.7-co-0.6.2.
In both cases, I used kaffe whose ChangeLog head is:
2005-07-22 Guilhem Lavaux [EMAIL PROTECTED]
On FreeBSD 5.4-RELEASE:
[EMAIL PROTECTED] kaffe SecureRandomTest
gnu.java.security.provider.Gnu: name=GNU version=1.0
kaffe.security.provider.Kaffe: name=KAFFE version=1.0
java.lang.Error: The secure random isn't! : lpc= 0 lpc2 = 20 data =
8bc7ec02ec7c04f87a13ec6120616ead831baeaf
at java.lang.VMThrowable.fillInStackTrace (VMThrowable.java:native)
at java.lang.VMThrowable.fillInStackTrace (VMThrowable.java:79)
at java.lang.Throwable.fillInStackTrace (Throwable.java:498)
at java.lang.Throwable.init (Throwable.java:159)
at java.lang.Error.init (Error.java:81)
at SecureRandomTest.checkHistory (SecureRandomTest.java:51)
at SecureRandomTest.main (SecureRandomTest.java:89)
On Linux 2.6.7-co-0.6.2:
[EMAIL PROTECTED] kaffe SecureRandomTest
gnu.crypto.jce.GnuCrypto: name=GNU-CRYPTO version=2.1
org.metastatic.jessie.provider.Jessie: name=Jessie version=1.0
kaffe.security.provider.Kaffe: name=KAFFE version=1.0
gnu.java.security.provider.Gnu: name=GNU version=1.0
Two SecureRandoms produce different output.
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] SecureRandomTest failed
Hi, Today's regression test failure: [EMAIL PROTECTED] cat test/regression/SecureRandomTest.fail java.lang.Error: The secure random isn't! : lpc= 0 lpc2 = 20 data = 8bc7ec02ec7c04f87a13ec6120616ead831baeaf at java.lang.VMThrowable.fillInStackTrace (VMThrowable.java:native) at java.lang.VMThrowable.fillInStackTrace (VMThrowable.java:79) at java.lang.Throwable.fillInStackTrace (Throwable.java:498) at java.lang.Throwable.init (Throwable.java:159) at java.lang.Error.init (Error.java:81) at SecureRandomTest.checkHistory (SecureRandomTest.java:51) at SecureRandomTest.main (SecureRandomTest.java:85) [EMAIL PROTECTED] /disk/kaz/work/kaffe-inst/bin/kaffe -fullversion kaffe VM 1.1.x-cvs Copyright (c) 1996-2005 Kaffe.org project contributors (please see the source code for a full list of contributors). All rights reserved. Portions Copyright (c) 1996-2002 Transvirtual Technologies, Inc. The Kaffe virtual machine is free software, licensed under the terms of the GNU General Public License. Kaffe.org is a an independent, free software community project, not directly affiliated with Transvirtual Technologies, Inc. Kaffe is a Trademark of Transvirtual Technologies, Inc. Kaffe comes with ABSOLUTELY NO WARRANTY. Engine: Just-in-time v3 Version: 1.1.x-cvs Java Version: 1.4 Heap defaults: minimum size: 5 MB, maximum size: unlimited Stack default size: 256 KB Configuration/Compilation options: ) Compile date : Thu Jul 21 00:08:47 JST 2005 Compile host : ph.maczuka.gcd.org Install prefix : /disk/kaz/work/kaffe-inst Thread system: unix-pthreads Garbage Collector: kaffe-gc CC : gcc CFLAGS : -g -O2 -Wall -D_THREAD_SAFE -pthread LDFLAGS : ChangeLog head : 2005-07-20 Wolfgang Baer [EMAIL PROTECTED] [EMAIL PROTECTED] uname -a FreeBSD ph.maczuka.gcd.org 5.4-RELEASE FreeBSD 5.4-RELEASE #0: Sun May 8 10:21:06 UTC 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] SecureRandomTest failed
Today's regression test failure: [EMAIL PROTECTED] cat test/regression/SecureRandomTest.fail java.lang.Error: The secure random isn't! : lpc= 0 lpc2 = 20 data = 8bc7ec02ec7c04f87a13ec6120616ead831baeaf I am afraid something has changed so that Security.getProviders() returns gnu.java.security.provider.Gnu: name=GNU version=1.0 before kaffe.security.provider.Kaffe: name=KAFFE version=1.0 With an older kaffe whose ChangeLog head is 2005-06-29 Guilhem Lavaux [EMAIL PROTECTED], with which SecureRandomTest passed, I can reproduce the error by forcing SecureRandomTest to use gnu.java.security.provider.Gnu. Change the lines in SecureRandomTest.java that read sr = SecureRandom.getInstance(SHA1PRNG); to sr = SecureRandom.getInstance(SHA1PRNG, GNU); and you will see the same error. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] CVS kaffe (robilad): Updated jikes recommendation to 1.22
Hi, +The preferred compiler is jikes. The URL for jikes is: + + http://www10.software.ibm.com/developerworks/opensource/jikes/ I have found that Jikes' home has moved to http://jikes.sourceforge.net/ ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] What UnicodeLittle should be?
From: Ito Kazumitsu [EMAIL PROTECTED] Subject: Re: [kaffe] What UnicodeLittle should be? Date: Fri, 24 Jun 2005 12:00:41 +0900 (JST) But http://java.sun.com/j2se/1.5.0/docs/guide/intl/encoding.doc.html says about UnicodeLittle, Sixteen-bit Unicode Transformation Format, little-endian byte order, with byte-order mark So, gnu.java.nio.charset.UnicodeLittle must be correct. Correct, but buggy. I submitted a bug report to GNU Classpath. http://savannah.gnu.org/bugs/?func=detailitemitem_id=13532 ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Kaffe's jar and current directory
Hi, Is this a bug of Kaffe's jar, or am I doing something wrong? Command to be executed: jar -cf 0.jar -C tmp . $ ls -al tmp total 16 drwxrwxr-x2 ito ito 4096 Jun 24 10:01 . drwx-- 52 ito ito 4096 Jun 23 16:08 .. -rw-rw-r--1 ito ito 6 Jun 24 10:01 file1 -rw-rw-r--1 ito ito 6 Jun 24 10:01 file2 With Kaffe's jar: $ /usr/local/kaffe/bin/jar -cf 0.jar -C tmp . $ /usr/local/kaffe/bin/jar tvf 0.jar 263 Fri Jun 24 10:03:22 GMT+09:00 2005 META-INF/MANIFEST.MF 0 Fri Jun 24 10:03:22 GMT+09:00 2005 ./ 6 Fri Jun 24 10:03:22 GMT+09:00 2005 ./file1 6 Fri Jun 24 10:03:22 GMT+09:00 2005 ./file2 With GCJ's jar: $ /usr/local/bin/jar -cf 0.jar -C tmp . $ /usr/local/bin/jar tvf 0.jar 0 Fri Jun 24 10:04:50 JST 2005 META-INF/ 44 Fri Jun 24 10:04:50 JST 2005 META-INF/MANIFEST.MF 0 Fri Jun 24 10:01:32 JST 2005 ./ 6 Fri Jun 24 10:01:28 JST 2005 file1 6 Fri Jun 24 10:01:32 JST 2005 file2 With Sun's jar $ /cygdrive/c/j2sdk1.4.2_06/bin/jar -cf 0.jar -C tmp . $ /cygdrive/c/j2sdk1.4.2_06/bin/jar tvf 0.jar 0 Fri Jun 24 10:07:06 JST 2005 META-INF/ 71 Fri Jun 24 10:07:06 JST 2005 META-INF/MANIFEST.MF 6 Fri Jun 24 10:01:30 JST 2005 file1 6 Fri Jun 24 10:01:32 JST 2005 file2 I am afraid that the current directory notation ./ attached to each file name may be the cause of NoClassDefFoundError when a kaffe-made jar file is in the classpath. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] What UnicodeLittle should be?
Hi, I have found that the famous Java Excel API (http://www.andykhan.com/jexcelapi/) does not work with Kaffe these days: Japanese text cannot be extracted from Excel worksheets. This seems to be due to the difference between iconv and gnu.java.nio.charset on the handling of UnicodeLittle. iconv, which kaffe used before importing gnu.java.nio.charset, treats UnicodeLittle as an alias of UCS-2LE (WITHOUT byte order mark). But gnu.java.nio.charset.UnicodeLittle treats it as UTF-16 little endian WITH byte order mark. I do not know which is correct, but seeing the behavior of Java Excel API, I think iconv's implementation is correct. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] What UnicodeLittle should be?
From: Ito Kazumitsu [EMAIL PROTECTED] Subject: [kaffe] What UnicodeLittle should be? Date: Fri, 24 Jun 2005 11:37:54 +0900 (JST) iconv, which kaffe used before importing gnu.java.nio.charset, treats UnicodeLittle as an alias of UCS-2LE (WITHOUT byte order mark). But gnu.java.nio.charset.UnicodeLittle treats it as UTF-16 little endian WITH byte order mark. I do not know which is correct, but seeing the behavior of Java Excel API, I think iconv's implementation is correct. But http://java.sun.com/j2se/1.5.0/docs/guide/intl/encoding.doc.html says about UnicodeLittle, Sixteen-bit Unicode Transformation Format, little-endian byte order, with byte-order mark So, gnu.java.nio.charset.UnicodeLittle must be correct. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Japanese charsets support
Hi, Formerly, when Kaffe had original ByteToChar and CharToByte converters, we could use such Japanese charsets or charset aliases as EUC_JP, Shift_JIS, and MS932. Now that kaffe uses gnu.java.nio.charset.iconv package, those charsets cannot be used any more. EUC_JP:missing in the aliases list of EUC-JP. Shift_JIS: iconv's behavior may be correct in the light of the standard, but in the real life, we need something slightly deifferent. See http://savannah.gnu.org/bugs/?func=detailitemitem_id=13111 MS932 or officially Windows-31J: iconv does not support this. iconv does support CP932, which is similar to MS932, but iconv's CP932 is slightly different from MS932. As a solution of this issue, I have made my own CharsetProvider as a wrapper of gnu.java.nio.charset.iconv.IconvProvider and put it at http://www.jsdi.or.jp/~maczuka/kaffe/IconvJapaneseCharsetProvider.java I would like to contibute this to Kaffe. Where in the source tree should I put it ? ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] kaffe -jar fails when environment variable CLASSPATH is set
From: Michael Koch [EMAIL PROTECTED]
Subject: Re: [kaffe] kaffe -jar fails when environment variable CLASSPATH is set
Date: Tue, 7 Jun 2005 07:16:55 +0200
CLASSPATH and -classpath have to get completely ignored when using -jar.
The only valid CLASSPATH is the Class-Path entry in the manifest of the jar.
Oh, yes. j2sdk-1_4_2-doc/docs/tooldocs/linux/java.html says so.
Then the code in main.c
752 if (vmargs.classpath != NULL) {
753 strcat (newcpath, path_separator);
754 strcat (newcpath, vmargs.classpath);
755 free (vmargs.classpath);
756 }
757
758 /* set the new classpath */
759 vmargs.classpath = newcpath;
should be
752 if (vmargs.classpath != NULL) {
755 free (vmargs.classpath);
756 }
757
758 /* set the new classpath */
759 vmargs.classpath = newcpath;
Anyway, the problem is that free (vmargs.classpath); fails here
if the environment variable CLASSPATH is set. However meaningless
it may be, CLASSPATH can be set when -jar is used.
My patch is expected to save this case.
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] kaffe -jar failes when environment variable CLASSPATH is set
Hi,
Kaffe invoked with -jar option failes if the environment variable
CLASSPATH is set. Please see the following test case.
bash$ cat src/META-INF/MANIFEST.MF
Manifest-Version: 1.0
Main-Class: Main
bash$ cat src/Main.java
public class Main {
public static void main(String[] args) {
System.out.println(OK);
}
}
bash$ jar tvf test.jar
0 Tue Jun 07 09:03:34 JST 2005 META-INF/
43 Tue Jun 07 08:53:58 JST 2005 META-INF/MANIFEST.MF
408 Tue Jun 07 09:00:14 JST 2005 Main.class
bash$ kaffe -jar test.jar
OK
bash$ kaffe -classpath XXX -jar test.jar
OK
bash$ CLASSPATH= kaffe -jar test.jar
Segmentation fault
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] kaffe -jar fails when environment variable CLASSPATH is set
Kaffe invoked with -jar option failes if the environment variable
fails
CLASSPATH is set. Please see the following test case.
How about this?
--- kaffe/kaffe/main.c.orig Tue May 31 06:16:02 2005
+++ kaffe/kaffe/main.c Tue Jun 7 13:00:52 2005
@@ -130,6 +130,17 @@
}
#endif
}
+ /* classpath may be changed later, so we copy it to a newly allocated
+ area so that the memory can be freed. */
+ if (cp != NULL) {
+ char* newcp;
+ if ((newcp = malloc(strlen(cp) + 1)) == NULL) {
+ fprintf(stderr, _(Error: out of memory.\n));
+ exit(1);
+ }
+ strcpy(newcp, cp);
+ cp = newcp;
+ }
vmargs.classpath = cp;
cp = getenv(LIBRARYPATH1);
@@ -499,15 +510,17 @@
+ strlen(argv[i])
+ 1;
- /* Get longer buffer FIXME: free the old one */
+ /* Get longer buffer */
if ((newcpath = malloc(cpathlength)) == NULL) {
fprintf(stderr, _(Error: out of memory.\n));
exit(1);
}
/* Construct new classpath */
- if( vmargs.classpath != 0 )
+ if( vmargs.classpath != 0 ) {
strcpy(newcpath, vmargs.classpath);
+ free(vmargs.classpath);
+ }
else
newcpath[0] = '\0';
strcat(newcpath, path_separator);
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] gnu.java.nio.charset.iconv.IconvCharset cannot be used
Hi Guilhem. Thanks for taking interest in my problem.
Could you add (*env)-ExceptionDescribe(env) at the point where there is
a failed assertion. It should work now in any case. I guess that
FindClass returns NULL because it cannot find RawData* but we must
check.
Yes, the result of (*env)-ExceptionDescribe(env) follows:
java.lang.ClassNotFoundException: gnu.classpath.RawData32
at java.lang.VMClassLoader.loadClass (VMClassLoader.java)
at java.lang.Class.forName (Class.java:210)
at gnu.java.nio.charset.iconv.IconvEncoder.openIconv (IconvEncoder.java)
at gnu.java.nio.charset.iconv.IconvEncoder.init (IconvEncoder.java:68)
at gnu.java.nio.charset.iconv.IconvCharset.newEncoder (IconvCharset.java:81)
at gnu.java.nio.charset.iconv.IconvCharset.init (IconvCharset.java:54)
at gnu.java.nio.charset.iconv.IconvProvider.charsetForName
(IconvProvider.java:103)
at TestCharsetProviderMain.main (TestCharsetProviderMain.java:21)
The following simple program also shows interesting results:
bash-2.05b$ cat TestClassForName.java
public class TestClassForName {
public static void main(String[] args) throws Exception {
System.err.println(Class.forName(args[0]));
}
}
bash-2.05b$ kaffe TestClassForName java.io.File
class java.io.File
bash-2.05b$ kaffe TestClassForName gnu.java.nio.charset.iconv.IconvCharset
class gnu.java.nio.charset.iconv.IconvCharset
bash-2.05b$ kaffe TestClassForName gnu.classpath.RawData32
java.lang.ClassNotFoundException: gnu.classpath.RawData32 not found in
java.lang.ClassLoader$1{urls=[file:/home/kaz/javatest/testIconv/./],
parent=null}
at java.net.URLClassLoader.findClass (URLClassLoader.java:841)
at java.lang.ClassLoader.loadClass (ClassLoader.java:349)
at java.lang.ClassLoader$1.loadClass (ClassLoader.java:1090)
at java.lang.ClassLoader.loadClass (ClassLoader.java:301)
at java.lang.Class.forName (Class.java:219)
at java.lang.Class.forName (Class.java:161)
at TestClassForName.main (TestClassForName.java:3)
bash-2.05b$ kaffe TestClassForName gnu.classpath.SystemProperties
java.lang.ClassNotFoundException: gnu.classpath.SystemProperties not found in
java.lang.ClassLoader$1{urls=[file:/home/kaz/javatest/testIconv/./],
parent=null}
at java.net.URLClassLoader.findClass (URLClassLoader.java:841)
at java.lang.ClassLoader.loadClass (ClassLoader.java:349)
at java.lang.ClassLoader$1.loadClass (ClassLoader.java:1090)
at java.lang.ClassLoader.loadClass (ClassLoader.java:301)
at java.lang.Class.forName (Class.java:219)
at java.lang.Class.forName (Class.java:161)
at TestClassForName.main (TestClassForName.java:3)
Why can't gnu.classpath.* be found?
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] CVS kaffe (hkraemer): fix for Kaffe_FindClass
From: Kaffe CVS [EMAIL PROTECTED] Subject: [kaffe] CVS kaffe (hkraemer): fix for Kaffe_FindClass Date: Sat, 04 Jun 2005 14:03:26 -0700 +2005-06-04 Helmer Kraemer [EMAIL PROTECTED] + + * kaffe/kaffevm/jni/jni.c (Kaffe_FindClass): fixed so it works correctly + for native methods of system classes. + Thanks. The problem gnu.java.nio.charset.iconv.IconvCharset cannot be used has been solved now. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] CVS kaffe (kaz): libraries/javalib/gnu/java/nio/charset/iconv/IconvProvider.java
2005-06-05 Ito Kazumitsu [EMAIL PROTECTED] * libraries/javalib/gnu/java/nio/charset/iconv/IconvProvider.java (IconvProvider): Made the constructor public. * libraries/javalib/java/nio/charset/Charset.java (providers2): Allow spaces and comments in META-INF/services/java.nio.charset.spi.CharsetProvider. Load the provider using the context class loader. These changes fix: http://savannah.gnu.org/bugs/?func=detailitemitem_id=13267 http://savannah.gnu.org/bugs/?func=detailitemitem_id=13251 ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] gnu.java.nio.charset.iconv.IconvCharset cannot be used
Hi,
ChangeLog says:
2005-05-30 Helmer Kraemer [EMAIL PROTECTED]
* libraries/javalib/kaffe/lang/AppClassLoader.java,
libraries/javalib/kaffe/lang/PrimordialClassLoader.java,
libraries/clib/native/PrimordialClassLoader.c: removed. Loading classes
is
now handled completely by ClassLoader / VMClassLoader.
...
*
libraries/javalib/META-INF/services/java.nio.charset.spi.CharsetProvider:
removed, as iconv is treated specially by java.nio.charset.Charset
The removal of META-INF/... is OK for me because I prefer using my own
CharsetProvider wrapping gnu.java.nio.charset.iconv.IconvProvider.
But the following simple program dumps core. This problem did not occur
when kaffe.lang.*ClassLoader was used.
bash-2.05b$ cat TestCharsetProviderMain.java
import java.nio.charset.*;
import java.nio.charset.spi.*;
public final class TestCharsetProviderMain
{
public static void main(String[] args) throws Exception
{
Class c = Class.forName(gnu.java.nio.charset.iconv.IconvProvider, true,
Thread.currentThread().getContextClassLoader());
System.out.println(c);
System.out.flush();
CharsetProvider p = (CharsetProvider)(c.newInstance());
System.out.println(p);
System.out.flush();
System.out.println(p.charsetForName(args[0]));
}
}
bash-2.05b$ kaffe TestCharsetProviderMain EUC-JP
class gnu.java.nio.charset.iconv.IconvProvider
[EMAIL PROTECTED]
charsetForName EUC-JP
IconvMetaData [EMAIL PROTECTED]
trying new IconvCharset(info)
Assertion failed: (cls != NULL), function createRawData, file
gnu_java_nio_charset_iconv_IconvEncoder.c, line 192.
Abort trap (core dumped)
Please note that some files are modified for debugging purpose:
--- gnu/java/nio/charset/iconv/IconvProvider.java.orig Sat Apr 23 18:54:27 2005
+++ gnu/java/nio/charset/iconv/IconvProvider.java Fri Jun 3 07:34:02 2005
@@ -62,7 +62,7 @@
}
}
- private IconvProvider()
+ public IconvProvider()
{
IconvMetaData.setup();
}
@@ -88,13 +88,23 @@
{
try
{
+ System.out.println(charsetForName + charsetName);
+ System.out.flush();
IconvMetaData info = IconvMetaData.get(charsetName);
+ System.out.println(IconvMetaData + info);
+ System.out.flush();
// Try anyway if the set isn't found.
if (info == null)
info = new IconvMetaData(charsetName, 2.0f, 2.0f, 2.0f, 2.0f,
new String[] { }, charsetName);
- return new IconvCharset(info);
+ System.out.println(trying new IconvCharset(info));
+ System.out.flush();
+ Charset cs = new IconvCharset(info);
+ System.out.println(new IconvCharset(info) + cs);
+ System.out.flush();
+ return cs;
+ // return new IconvCharset(info);
}
catch (IllegalArgumentException e)
{
Note: Without changing private IconvProvider() to public IconvProvider(),
an instance of this class cannot be created newInstance().
--- libraries/clib/nio/gnu_java_nio_charset_iconv_IconvEncoder.c.~1.3.~ Fri May
20 23:46:49 2005
+++ libraries/clib/nio/gnu_java_nio_charset_iconv_IconvEncoder.cSat Jun
4 07:04:23 2005
@@ -79,6 +79,7 @@
if (infid == NULL || outfid == NULL)
{
cls = (*env)-GetObjectClass (env, obj);
+ assert (cls != NULL);
infid = (*env)-GetFieldID (env, cls, inremaining, I);
assert (infid != 0);
outfid = (*env)-GetFieldID (env, cls, outremaining, I);
@@ -183,10 +184,12 @@
#ifdef POINTERS_ARE_64BIT
cls = (*env)-FindClass (env, gnu/classpath/RawData64);
+ assert (cls != NULL);
method = (*env)-GetMethodID (env, cls, init, (J)V);
data = (*env)-NewObject (env, cls, method, (jlong) ptr);
#else
cls = (*env)-FindClass (env, gnu/classpath/RawData32);
+ assert (cls != NULL);
method = (*env)-GetMethodID (env, cls, init, (I)V);
data = (*env)-NewObject (env, cls, method, (jint) ptr);
#endif
Note: assert (cls != NULL) is also written in lookupClassMethod
in kaffe/kaffevm/support.c. Without inserting assert (cls != NULL)
here, the failure will be checked there.
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] iconv problem on FreeBSD
From: Riccardo [EMAIL PROTECTED] Subject: [kaffe] Re: Re: NetworkInterface problem Date: Mon, 25 Apr 2005 00:22:23 + (UTC) In [EMAIL PROTECTED] Dalibor Topic wrote: p.s. I hope the recent iconv changes work for you on freebsd. Riccardo seems to be having some problems, we're debugging them on IRC. unfortunately adding /usr/local/lib to iconv-libraries didn't help. still the same stupid error. In my case, I use the following script for configuration CPPFLAGS=-I/usr/local/include LIBS=-L/usr/local/lib -lgmp -lintl \ ./configure \ --without-classpath-gtk-awt \ --without-kaffe-qt-awt \ --with-libiconv-prefix=/usr/local \ --with-libintl-prefix=/usr/local \ and then gmake goes without problem. I have long used the environment variables CPPFLAGS and LIBS. Maybe I had some problem without them, which I do not remember. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
NetworkInterface problem (Re: [kaffe] freebsd 5.3 failed regression)
From: Riccardo [EMAIL PROTECTED]
Subject: [kaffe] freebsd 5.3 failed regression
Date: Fri, 22 Apr 2005 11:38:06 + (UTC)
on 18 april, freebsd 5.3 passed all tests, today it fails one:
In my case, also on FreeBSD 5.3-RELEASE, compilation failes
before going to the regression test.
Now Kaffe's CVS version compiles fine, and I am experiencing
the same problem reported by Riccardo.
The problem seems to appear when a network interface has more than
one addresses.
Attached is a program copied from test/regression/NetworkInterfaceTest.java.
According to this,
(1) NetworkInterface returned by NetworkInterface.getNetworkInterfaces()
contains all addresses of that interface.
(2) NetworkInterface returned by NetworkInterface.getByName(name) or
NetworkInterface.getByInetAddress(addr) contains only one of the
addresses of that interface.
Test program:
import java.util.Enumeration;
import java.net.InetAddress;
import java.net.SocketException;
import java.net.NetworkInterface;
public class TestNetworkInterface
{
private static void showNetworkInterface(NetworkInterface ni)
{
System.out.println( showNetworkInterface: + ni + {);
System.out.println( Name: + ni.getName());
System.out.println( Display Name:
+ ni.getDisplayName());
Enumeration ips = ni.getInetAddresses();
while( ips.hasMoreElements() )
{
InetAddress ia;
ia = (InetAddress)ips.nextElement();
System.out.println( Address: + ia);
}
System.out.println( });
}
public static void main(String args[])
{
try
{
Enumeration enum;
int lpc;
enum = NetworkInterface.getNetworkInterfaces();
for( lpc = 0; enum.hasMoreElements(); lpc++ )
{
NetworkInterface ni, ni2;
Enumeration ips;
ni = (NetworkInterface)enum.nextElement();
System.out.println(Detected interface # + lpc);
showNetworkInterface(ni);
ni2 = NetworkInterface.getByName(ni.getName());
System.out.println(getByName( + ni.getName() + ));
showNetworkInterface(ni2);
ips = ni.getInetAddresses();
while( ips.hasMoreElements() )
{
InetAddress ia;
ia = (InetAddress)ips.nextElement();
System.out.println(getByInetAddress( + ia + ));
ni2 = NetworkInterface.getByInetAddress(ia);
showNetworkInterface(ni2);
}
}
}
catch(SocketException e)
{
e.printStackTrace();
System.exit(77);
}
catch(kaffe.util.NotImplemented e)
{
e.printStackTrace();
System.exit(77);
}
}
}
Result:
Detected interface #0
showNetworkInterface: name: lo0 (lo0) addresses:
127.0.0.1/127.0.0.1;
::1/0:0:0:0:0:0:0:1;
fe80:3::1/fe80:3:0:0:0:0:0:1;
{
Name: lo0
Display Name: lo0
Address: 127.0.0.1/127.0.0.1
Address: ::1/0:0:0:0:0:0:0:1
Address: fe80:3::1/fe80:3:0:0:0:0:0:1
}
getByName(lo0)
showNetworkInterface: name: lo0 (lo0) addresses:
127.0.0.1/127.0.0.1;
{
Name: lo0
Display Name: lo0
Address: 127.0.0.1/127.0.0.1
}
getByInetAddress(127.0.0.1/127.0.0.1)
showNetworkInterface: name: lo0 (lo0) addresses:
127.0.0.1/127.0.0.1;
{
Name: lo0
Display Name: lo0
Address: 127.0.0.1/127.0.0.1
}
getByInetAddress(::1/0:0:0:0:0:0:0:1)
showNetworkInterface: name: lo0 (lo0) addresses:
::1/0:0:0:0:0:0:0:1;
{
Name: lo0
Display Name: lo0
Address: ::1/0:0:0:0:0:0:0:1
}
getByInetAddress(fe80:3::1/fe80:3:0:0:0:0:0:1)
showNetworkInterface: name: lo0 (lo0) addresses:
fe80:3::1/fe80:3:0:0:0:0:0:1;
{
Name: lo0
Display Name: lo0
Address: fe80:3::1/fe80:3:0:0:0:0:0:1
}
Detected interface #1
showNetworkInterface: name: fxp0 (fxp0) addresses:
192.168.0.3/192.168.0.3;
fe80:1::202:55ff:feec:ab05/fe80:1:0:0:202:55ff:feec:ab05;
{
Name: fxp0
Display Name: fxp0
Address: 192.168.0.3/192.168.0.3
Address: fe80:1::202:55ff:feec:ab05/fe80:1:0:0:202:55ff:feec:ab05
}
getByName(fxp0)
showNetworkInterface: name: fxp0 (fxp0) addresses:
192.168.0.3/192.168.0.3;
{
Name: fxp0
Display Name: fxp0
Address: 192.168.0.3/192.168.0.3
}
getByInetAddress(192.168.0.3/192.168.0.3)
showNetworkInterface: name: fxp0 (fxp0) addresses:
192.168.0.3/192.168.0.3;
{
Name: fxp0
Display Name: fxp0
Address: 192.168.0.3/192.168.0.3
}
getByInetAddress(fe80:1::202:55ff:feec:ab05/fe80:1:0:0:202:55ff:feec:ab05)
showNetworkInterface: name: fxp0 (fxp0) addresses:
fe80:1::202:55ff:feec:ab05/fe80:1:0:0:202:55ff:feec:ab05;
{
Name: fxp0
Display Name: fxp0
Address: fe80:1::202:55ff:feec:ab05/fe80:1:0:0:202:55ff:feec:ab05
}
Re: [kaffe] freebsd 5.3 failed regression
From: Riccardo [EMAIL PROTECTED] Subject: [kaffe] freebsd 5.3 failed regression Date: Fri, 22 Apr 2005 11:38:06 + (UTC) on 18 april, freebsd 5.3 passed all tests, today it fails one: In my case, also on FreeBSD 5.3-RELEASE, compilation failes before going to the regression test. gcc -DHAVE_CONFIG_H -I. -I. -I../../../config -I../../../include/kaffe -I../../ ../kaffe -I../../../include -I../../../kaffe/kaffevm/jni -I/disk/kaz/work/kaffe- make-current/kaffe/./kaffe/kaffevm -I/disk/kaz/work/kaffe-make-current/kaffe/./k affe/kaffevm/jit3 -I/disk/kaz/work/kaffe-make-current/kaffe/./kaffe/kaffevm/syst ems/unix-pthreads -I../../../replace -I../../../binreloc -I../../../config -I../ ../../include -I/usr/local/include -DKAFFE_VMDEBUG -D_REENTRANT -g -O2 -Wall -D_ THREAD_SAFE -pthread -MT libnet_la-PlainDatagramSocketImpl.lo -MD -MP -MF .deps/ libnet_la-PlainDatagramSocketImpl.Tpo -c PlainDatagramSocketImpl.c -fPIC -DPIC -o .libs/libnet_la-PlainDatagramSocketImpl.o PlainDatagramSocketImpl.c:23:39: java_net_NetworkInterface.h: No such file or di rectory In file included from PlainDatagramSocketImpl.c:25: ../../../include/gnu_java_net_PlainDatagramSocketImpl.h:37: warning: struct Hja va_net_NetworkInterface declared inside parameter list ../../../include/gnu_java_net_PlainDatagramSocketImpl.h:37: warning: its scope i s only this definition or declaration, which is probably not what you want ../../../include/gnu_java_net_PlainDatagramSocketImpl.h:38: warning: struct Hja va_net_NetworkInterface declared inside parameter list PlainDatagramSocketImpl.c:27:34: java_net_InetAddress.h: No such file or directo ry PlainDatagramSocketImpl.c: In function `gnu_java_net_PlainDatagramSocketImpl_bin d': PlainDatagramSocketImpl.c:135: error: dereferencing pointer to incomplete type PlainDatagramSocketImpl.c:144: error: dereferencing pointer to incomplete type PlainDatagramSocketImpl.c:153: error: dereferencing pointer to incomplete type PlainDatagramSocketImpl.c:162: error: dereferencing pointer to incomplete type PlainDatagramSocketImpl.c: In function `gnu_java_net_PlainDatagramSocketImpl_sen d0': PlainDatagramSocketImpl.c:220: error: dereferencing pointer to incomplete type PlainDatagramSocketImpl.c:229: error: dereferencing pointer to incomplete type PlainDatagramSocketImpl.c:238: error: dereferencing pointer to incomplete type PlainDatagramSocketImpl.c:247: error: dereferencing pointer to incomplete type PlainDatagramSocketImpl.c: In function `gnu_java_net_PlainDatagramSocketImpl_pee k': PlainDatagramSocketImpl.c:290: error: dereferencing pointer to incomplete type PlainDatagramSocketImpl.c:294: error: dereferencing pointer to incomplete type PlainDatagramSocketImpl.c: In function `gnu_java_net_PlainDatagramSocketImpl_rec eive0': PlainDatagramSocketImpl.c:389: error: dereferencing pointer to incomplete type PlainDatagramSocketImpl.c: In function `gnu_java_net_PlainDatagramSocketImpl_soc ketSetOption': PlainDatagramSocketImpl.c:449: error: dereferencing pointer to incomplete type PlainDatagramSocketImpl.c: In function `gnu_java_net_PlainDatagramSocketImpl_joi n': PlainDatagramSocketImpl.c:547: error: dereferencing pointer to incomplete type PlainDatagramSocketImpl.c: In function `gnu_java_net_PlainDatagramSocketImpl_lea ve': PlainDatagramSocketImpl.c:585: error: dereferencing pointer to incomplete type PlainDatagramSocketImpl.c: At top level: PlainDatagramSocketImpl.c:614: warning: struct Hjava_net_NetworkInterface decl ared inside parameter list PlainDatagramSocketImpl.c:615: error: conflicting types for 'gnu_java_net_PlainD atagramSocketImpl_joinGroup' ../../../include/gnu_java_net_PlainDatagramSocketImpl.h:37: error: previous decl aration of 'gnu_java_net_PlainDatagramSocketImpl_joinGroup' was here PlainDatagramSocketImpl.c:615: error: conflicting types for 'gnu_java_net_PlainD atagramSocketImpl_joinGroup' ../../../include/gnu_java_net_PlainDatagramSocketImpl.h:37: error: previous decl aration of 'gnu_java_net_PlainDatagramSocketImpl_joinGroup' was here PlainDatagramSocketImpl.c: In function `gnu_java_net_PlainDatagramSocketImpl_joi nGroup': PlainDatagramSocketImpl.c:626: error: dereferencing pointer to incomplete type PlainDatagramSocketImpl.c:634: error: dereferencing pointer to incomplete type PlainDatagramSocketImpl.c:637: error: dereferencing pointer to incomplete type PlainDatagramSocketImpl.c:639: error: dereferencing pointer to incomplete type PlainDatagramSocketImpl.c: At top level: PlainDatagramSocketImpl.c:668: warning: struct Hjava_net_NetworkInterface decl ared inside parameter list PlainDatagramSocketImpl.c:669: error: conflicting types for 'gnu_java_net_PlainD atagramSocketImpl_leaveGroup' ../../../include/gnu_java_net_PlainDatagramSocketImpl.h:38: error: previous decl aration of 'gnu_java_net_PlainDatagramSocketImpl_leaveGroup' was here PlainDatagramSocketImpl.c:669: error: conflicting types for 'gnu_java_net_PlainD atagramSocketImpl_leaveGroup'
Re: [kaffe] HSQLDB and Kaffe
Hi, Wolfgang Baer wrote: Fernando Lozano wrote: Just to report HSQLDB (hsqldb.sf.net) seems to run fine under Kaffe which version of HSQLDB did you tried ? The Debian package maintainer had problems with 1.7.3 and kaffe because of NIO locking, but someone said these problems should be solved in 1.8.0RC3. So the version would be interesting :-) I tried HSQLDB 1.8.0.RC9 to find that the NIO locking problem is still there. I think this problem will be solved either when GNU Classpath's java.nio.channels.FileLock becomes usable, or when HSQLDB can detect whether java.nio.channels.FileLock is usable rather than just checking the existence of java.nio.channels.FileLock. I have been using HSQLDB after patching its LockFile.java so that it throws Exception before Class.forName(java.nio.channels.FileLock) succeeds. Fernando may be using HSQLDB's defualt memory tables, in which case NIO file locking may not be used. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] ThreadLocalTest fails
ThreadLocalTest fails recently. It does not finish until killed by the killer process. bash-3.00$ uname -a FreeBSD mq.maczuka.gcd.org 5.3-RELEASE FreeBSD 5.3-RELEASE #0: Fri Nov 5 04:19:18 UTC 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 bash-3.00$ /disk/kaz/work/kaffe-inst/bin/kaffe -fullversion Kaffe Virtual Machine Copyright (c) 1996-2004 Kaffe.org project contributors (please see the source code for a full list of contributors). All rights reserved. Portions Copyright (c) 1996-2002 Transvirtual Technologies, Inc. The Kaffe virtual machine is free software, licensed under the terms of the GNU General Public License. Kaffe.org is a an independent, free software community project, not directly affiliated with Transvirtual Technologies, Inc. Kaffe is a Trademark of Transvirtual Technologies, Inc. Kaffe comes with ABSOLUTELY NO WARRANTY. Engine: Just-in-time v3 Version: 1.1.x-cvs Java Version: 1.1 Configuration/Compilation options: Compile date : Wed Mar 16 01:02:48 JST 2005 Compile host : mq.maczuka.gcd.org Install prefix : /disk/kaz/work/kaffe-inst Thread system: unix-pthreads Garbage Collector: kaffe-gc CC : gcc CFLAGS : -g -O2 -Wchar-subscripts -Wcomment -Wformat=2 -Wimplicit-function-declaration -Wimplicit-int -Wmain -Wmissing-braces -Wparentheses -Wsequence-point -Wreturn-type -Wswitch -Wswitch-default -Wswitch-enum -Wtrigraphs -Wunused-function -Wunused-label -Wunused-parameter -Wunused-variable -Wunused-value -Wunknown-pragmas -Wstrict-aliasing -W -Wfloat-equal -Wdeclaration-after-statement -Wundef -Wendif-labels -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings -Wconversion -Wsign-compare -Waggregate-return -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -Wmissing-format-attribute -Wpacked -Wredundant-decls -Wnested-externs -Winvalid-pch -Winline -Wlong-long -Wdisabled-optimization -no-cpp-precomp -D_THREAD_SAFE -pthread LDFLAGS : ChangeLog head : 2005-03-14 Dalibor Topic [EMAIL PROTECTED] And here is the message the regression test showed. TestScript ./ThreadLocalTest.java testing ./ThreadLocalTest.java JAVA_SRCS=./ThreadLocalTest.java jikes +Pno-switchcheck +Pno-shadow +E -nowarn -bootclasspath ../..//libraries/javalib/rt.jar -classpath .:@GNU_CRYPTO_JAR@:@JAVAX_SECURITY_JAR@:.:compile_time:.: -d . ./ThreadLocalTest.java /disk/kaz/work/kaffe-make-current/kaffe/kaffe/kaffe/kaffe-bin -Dgnu.classpath.home.url=file:///disk/kaz/work/kaffe-make-current/kaffe/test/regression/../../libraries/clib/ ThreadLocalTest Background pid: 80311 Killer process pid: 80312 with timeout of 900 seconds output differs from ThreadLocalTest.out, saving in ThreadLocalTest.fail FAIL: ThreadLocalTest.java The difference of ThreadLocalTest.fail from the expected output is only this: Timeout - 900 seconds - killed ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] undefined reference to `pthread_...
: == Ito Kazumitsu [EMAIL PROTECTED] writes: : Make on FreeBSD 5.3-RELEASE failed today: : FreeBSD's pthread requires the gcc flag -pthread for linking. : : Seeing the output from make, I found -pthread set for gcc compiling : indivisual C programs, but not for the gcc -o .libs/kaffe-bin. As a workaround, I set the environment variable CC=gcc -pthread, and it went well. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] undefined reference to `pthread_...
Hi, Make on FreeBSD 5.3-RELEASE failed today: ../kaffevm/.libs/libkaffevm.so: undefined reference to `pthread_attr_getstacksize' ../kaffevm/.libs/libkaffevm.so: undefined reference to `pthread_create' and so on. FreeBSD's pthread requires the gcc flag -pthread for linking. Seeing the output from make, I found -pthread set for gcc compiling indivisual C programs, but not for the gcc -o .libs/kaffe-bin. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Bug report: java.text.SimpleDateFormat#parse
In message Re: [kaffe] Bug report: java.text.SimpleDateFormat#parse on 05/01/29, Dalibor Topic [EMAIL PROTECTED] writes: : And even more thanks for your patch fixing the problem :) I've merged it : in from GNU Classpath, and now all tests pass again for me. But sadly enough, the recent change to java.util.GregorianCalendar, which does not honor zone offset and DST offset set before computeTime(), has made these chandes to java.text.SimpleDateFormat#parse ineffective. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Bug report: java.text.SimpleDateFormat#parse
Hi, In message Re: [kaffe] Bug report: java.text.SimpleDateFormat#parse on 05/01/27, Dalibor Topic [EMAIL PROTECTED] writes: Thanks Ito, I've applied your patch, as Andrew applied it to Classpath. The regression test still fails for me, unfortunately. This failure occurs with a time zone that has DST. $ kaffe -Duser.timezone=JST DateFormatTest Same time zone Different time zone $ kaffe -Duser.timezone=PST DateFormatTest Same time zone Different time zone Dates don't match? Thu Oct 28 06:00:27 America/Los_Angeles 2004 != Thu Oct 28 05:00:27 America/Los_Angeles 2004 And it can be explained as follows: JST (Zone offset = 9, DST offset = 0) java.text.SimpleDateFormat#parse java.util.GregorianCalendar#computeTime Parsed ZoneDST ZoneDSTResult in GMT/JST string offset offset offset offset 13:00GMT+00:00 00:00 - 00:00*[1] 00:00*[2] 13:00 / 22:00 [1] rawOffset = fields[ZONE_OFFSET] because isSet[ZONE_OFFSET] [2] dstOffset = 0 (DST offset of JST) because !isSet[DST_OFFSET] PST (Zone offset = -8, DST offset = 1) java.text.SimpleDateFormat#parse java.util.GregorianCalendar#computeTime Parsed ZoneDST ZoneDSTResult in GMT/PDT string offset offset offset offset 13:00GMT+00:00 00:00 - 00:00*[1] 01:00*[2] 12:00 / 05:00 [1] rawOffset = fields[ZONE_OFFSET] because isSet[ZONE_OFFSET] [2] dstOffset = 1 (DST offset of PST) because !isSet[DST_OFFSET] I should have added calendar.set (Calendar.DST_OFFSET, 0); to the part where GMT+xx:yy is being parsed, not only just swapping Calendar.DST_OFFSET and Calendar.ZONE_OFFSET. By the way, Dates don't match? Thu Oct 28 06:00:27 America/Los_Angeles 2004 != Thu Oct 28 05:00:27 America/Los_Angeles 2004 ^^^ why America/Los_Angeles appears instead of PDT is explained in http://www.kaffe.org/pipermail/kaffe/2005-January/101286.html http://lists.gnu.org/archive/html/classpath/2005-01/msg00200.html ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
