Re: Kaffe size
On Wed, 21 Feb 2001 [EMAIL PROTECTED] wrote: Can you please tell me where i can find eCos ? Med venlig hilsen / Best regards Dan Net A/S Benjamin Petersen Systemudvikler Sure, try: http://sources.redhat.com/ecos/ Mo DeJong Red Hat Inc
Re: KOPI contacts
On Tue, 10 Oct 2000, Nic Ferrier wrote: Anyone know how to get in touch with anybody from the Kopi project? I have some fixes for them and they're not answering my mails. I don't know about contacting the Kopi authors, but you might want to consider adding regression tests for your compiler bug fixes to the Jacks regression test suite. Jacks is a set of tests designed to exercise a Java compiler. It was created as part of the Jikes project, but it now includes support for Jikes, GCJ, Kaffe (Kopi), as well as javac. You can get it like so: setenv CVSROOT :pserver:[EMAIL PROTECTED]:/cvs/jikes cvs login paswsd anoncvs cvs checkout jacks cheers Mo DeJong Red Hat Inc
Re: Transvirtual Technologies Delivers Consolidated, Open So urce , KaffeT Implementation
On Sat, 22 Jul 2000, Tim Wilkinson wrote: We're planning to do a release of the current CVS tree which is pretty stable right now - and we've not done a release for about 9 months so its time. Hopefully that can happen ASAP. With that out of the way we'll start the merge process - the plan is to get the majority of the work done over the next month but bear with us since the VMs in particular will take a while to put together again. Cheers Tim Yes, now would be a great time to get a new release out the door. The 1.0.5 release that shipped with my Red Hat 6.2 system is really showing its age. There are plenty of bugs that have already been fixed in the CVS. I am going to do a CVS update and run some regression tests right now. later Mo DeJong Red Hat Inc
Patch for configure --with-threads option.
Could someone add this patch to the configure script? It just prints the available threading systems. Mo DeJong Red Hat Inc Index: configure.in === RCS file: /cvs/kaffe/kaffe/configure.in,v retrieving revision 1.146 diff -u -r1.146 configure.in --- configure.in2000/07/21 22:41:36 1.146 +++ configure.in2000/07/22 18:37:35 @@ -380,7 +380,7 @@ dnl Use the new internal threading system "jthreads" dnl - -AC_ARG_WITH(threads,[ --with-threads=SYSTEM Define which threading system to use]) +AC_ARG_WITH(threads,[ --with-threads=SYSTEM Define which threading system to use (unix-jthreads, unix-pthreads, win32, oskit-pthreads, or beos-native)]) AC_MSG_CHECKING(thread system) if test x"$with_threads" = x"" ; then with_threads=unix-jthreads
ANNOUNCE: New Jacks Java project is online.
Hi all. I thought I would post a short "heads up" message to let everyone know about the new Java compiler regression testing project hosted by the kind folks at IBM that brought you the Jikes Java compiler. The Jacks project is a "sister project" to Jikes, it seeks to provide a test suite to test how well a Java compiler adheres to the JLS. The cool thing about this project is that is also works with other Java compilers. The default configuration supports javac, jikes, gcj, and kaffe (kopi). Once a set of JLS test cases are created, they can be used with any of the free Java compiler projects. It is extremely easy to add a new test case and Jacks also includes an automated documentation generation tool, so the docs are always up to date. Jacks is licensed under the GPL. If you want to check out Jacks, here is the CVS info and the mailing list info. (CVS) setenv CVSROOT :pserver:[EMAIL PROTECTED]:/cvs/jikes cvs login paswsd anoncvs cvs checkout jacks See the jacks/jacks.html file to get started. (MAILING LIST) (send subscribe message to) [EMAIL PROTECTED] (this should go in the message body) subscribe jacks (wait for conformation message, then reply with) auth subscribe jacks EMAIL After you have subscribed, you can post messages to [EMAIL PROTECTED] cheers Mo DeJong Red Hat Inc
Re: reporting bugs for kaffe-1.0.5
2) I think that the jar packager is broken for if I specify a manifest file, it says that unexpected end of file in line 1. I have tried with more manifest files, and it doesnt works. The jar tool for version 1.0.5 was totally broken. It is fixed now, you would need to get a CVS version. That brings up a good point, when is a 1.0.6 release going to be made? Red Hat 7.0 is now in beta and I don't want to see another version shipped with kaffe 1.0.5. I also think that it can't update files, but I have tried it only once (now I use zip for this) The "update" feature in Sun's jar for JDK 1.2 was not implemented. I could not think of a good way to do it other than just extracting the whole archive into a temp directory and then creating a whole new archive. If you would like to add that feature, the code is here: kaffe/libraries/extensions/tools/javalib/kaffe/tools/jar/Jar.java Mo Dejong Red Hat Inc.
Deadlock in JNI program that loads Kaffe
uot;} {\n puts \"Installed program is working correctly\"\n exit 0\n}
else {\n puts stderr \"Installed program is not working correctly,
please recheck instal"..., length=340, flags=0) at
/home/mo/project/tcl/unix/../generic/tclParse.c:945
#20 0x4008b5d4 in Tcl_EvalEx (interp=0x804bc28, script=0x8059ad8 "puts
\"Testing installed program\"\nflush stdout\n\nif {[catch {\npackage
require java\n} err]} {\n puts stderr \"\\\"package require java\\\"
failed with the following error\"\n puts stderr $err\n exit
-1\n}\n\nset "..., numBytes=561, flags=0) at
/home/mo/project/tcl/unix/../generic/tclParse.c:1406
#21 0x40080074 in Tcl_EvalFile (interp=0x804bc28, fileName=0xbfffee70
"Test.tcl") at /home/mo/project/tcl/unix/../generic/tclIOUtil.c:330
#22 0x40083cda in Tcl_Main (argc=1, argv=0xb3b8,
appInitProc=0x8048758 Tcl_AppInit) at
/home/mo/project/tcl/unix/../generic/tclMain.c:198
#23 0x8048746 in main (argc=2, argv=0xb3b4) at
/home/mo/project/tcl/unix/../unix/tclAppInit.c:99
#24 0x401019cb in __libc_start_main (main=0x8048720 main, argc=2,
argv=0xb3b4, init=0x80485a4 _init, fini=0x80487dc _fini,
rtld_fini=0x4000ae60 _dl_fini, stack_end=0xb3ac) at
../sysdeps/generic/libc-start.c:92
Kaffe seems to be getting while loading a class.
This call is from lookup.c
78 if (loadClass == true) {
79 ci = METHODREF_CLASS(idx, pool);
80 class = getClass(ci, this, einfo);
81 if (class == NULL) {
82 call-cname = WORD2UTF(pool-data[ci]);
83 countInsAndOuts(sig-data, call-in,
call-out, call-rettype);
84 return (false);
85 }
86 assert(class-state = CSTATE_LINKED);
Line 80 call the getClass() method in the same file.
157 case CONSTANT_Class:
158 /* The class may be resolved by another thread so
we better
159 * lock and get the tag name again just in
case. If we
160 * have been resolved then we just return the answer.
161 */
162 lockClass(this);
This call to lockClass() is where things get deadlocked. I guess I just
do not understand how this thread is going to be woken up after it goes
to sleep with no timeout.
Any ideas?
Mo DeJong
Red Hat Inc
Re: (no subject)
On Tue, 30 May 2000, sumedhan wrote: dear sir, I am interested in porting kaffe on windows NT system. I have downloaded the source code from kaffe.org. I am facing a lot of difficulty in using make. could u pl send me step by step implementation procedure for doing this? Pl give me the reference or site where this info is available? sumedha. The first thing you will need to do is install cygwin. Just grab the "net installer" from one of the mirrors and run it to install gcc and gdb on your NT system. Download the installer. ftp://ftp.freesoftware.com/pub/sourceware/cygwin/latest/setup.exe Run it and then point it at a mirror like ftp://ftp.freesoftware.com/pub/sourceware/cygwin/latest ftp://ftp.sunsite.utk.edu/pub/cygwin/latest/ You should then be able to download and extract a tar ball of Kaffe. Then you just cd to the kaffe directory run ./configure ; make ; make install and it should build and install. I have not tested this myself so you may run into problems but that is how it "should" work. Mo Dejong Red Hat Inc.
Re: Thread.stop()
I was under the impression that methods like Thread.stop() were
removed from the JDK or replaced with no-ops. I seem to remember
that they were never implemented in Netscape's JVM. The whole
concept of stoping a thread seems like a bad idea, a thread
should expire due to natural causes.
Here are some notes about it from the Sun developer site.
http://developer.java.sun.com/developer/bugParade/bugs/4187649.html
http://developer.java.sun.com/developer/bugParade/bugs/4248898.html
Mo Dejong
Red Hat Inc.
On 22 May 2000, Jason Baker wrote:
Archie Cobbs [EMAIL PROTECTED] writes:
Email me a simple test case and I'll run it under both kaffe and JDK 1.2.
Weird. Blackdown 1.2.2 doesn't seem to asynchronously stop threads at
all, while jdk 1.1.7 can do it some of the time. Neither one seems to
throw an exception with a stack trace at all.
Jason
--
1.2.2:
nephi(53) java Die
sleeper started
doing it...
loop started
caught an error
java.lang.Error: throwing from main
done
doing it...
^C
--
1.1.7:
nephi(57) java Die
sleeper started
doing it...
loop started
caught an error
java.lang.Error: throwing from main
done
doing it...
^C
nephi(59) java Die 100
sleeper started
doing it...
loop started
caught an error
java.lang.Error: throwing from main
done
doing it...
caught an error
java.lang.Error: throwing from main
done
--
patched kaffe:
sleeper starteddoing it...
loop started
caught an error
java.lang.Error: throwing from main
at java.lang.Thread.waitOn(Thread.java:475)
at java.lang.Thread.sleep(Thread.java:364)
at Die$1.doIt(Die.java:24)
at Die.run(Die.java:7)
done
doing it...
caught an error
java.lang.Error: throwing from main
at Die.run(Die.java:7)
done
--
public abstract class Die extends Thread {
abstract void doIt();
public void run()
{
System.err.println("doing it...");
try { doIt(); }
catch (Error e) {
System.err.println("caught an error");
e.printStackTrace(System.err);
}
System.err.println("done");
}
static public void main(String[] args)
throws InterruptedException
{
int startup = 1000;
if (args.length 0)
startup = Integer.parseInt(args[0]);
Thread u = new Die() {
void doIt() {
try { Thread.sleep(30); }
catch (InterruptedException _) { }
}
};
u.start();
System.err.println("sleeper started");
Thread.sleep(startup);
u.stop(new Error("throwing from main"));
Thread t = new Die() {
void doIt() { while (true) ; }
};
t.start();
System.err.println("loop started");
Thread.sleep(startup);
t.stop(new Error("throwing from main"));
}
}
Re: Thread.stop()
I also found this note in kaffe/FAQ/FAQ.pthreads
* We do not support asynchronous exceptions via Thread.stop()
Mo Dejong
Red Hat Inc.
On Mon, 22 May 2000, Mo DeJong wrote:
I was under the impression that methods like Thread.stop() were
removed from the JDK or replaced with no-ops. I seem to remember
that they were never implemented in Netscape's JVM. The whole
concept of stoping a thread seems like a bad idea, a thread
should expire due to natural causes.
Here are some notes about it from the Sun developer site.
http://developer.java.sun.com/developer/bugParade/bugs/4187649.html
http://developer.java.sun.com/developer/bugParade/bugs/4248898.html
Mo Dejong
Red Hat Inc.
On 22 May 2000, Jason Baker wrote:
Archie Cobbs [EMAIL PROTECTED] writes:
Email me a simple test case and I'll run it under both kaffe and JDK 1.2.
Weird. Blackdown 1.2.2 doesn't seem to asynchronously stop threads at
all, while jdk 1.1.7 can do it some of the time. Neither one seems to
throw an exception with a stack trace at all.
Jason
--
1.2.2:
nephi(53) java Die
sleeper started
doing it...
loop started
caught an error
java.lang.Error: throwing from main
done
doing it...
^C
--
1.1.7:
nephi(57) java Die
sleeper started
doing it...
loop started
caught an error
java.lang.Error: throwing from main
done
doing it...
^C
nephi(59) java Die 100
sleeper started
doing it...
loop started
caught an error
java.lang.Error: throwing from main
done
doing it...
caught an error
java.lang.Error: throwing from main
done
--
patched kaffe:
sleeper starteddoing it...
loop started
caught an error
java.lang.Error: throwing from main
at java.lang.Thread.waitOn(Thread.java:475)
at java.lang.Thread.sleep(Thread.java:364)
at Die$1.doIt(Die.java:24)
at Die.run(Die.java:7)
done
doing it...
caught an error
java.lang.Error: throwing from main
at Die.run(Die.java:7)
done
--
public abstract class Die extends Thread {
abstract void doIt();
public void run()
{
System.err.println("doing it...");
try { doIt(); }
catch (Error e) {
System.err.println("caught an error");
e.printStackTrace(System.err);
}
System.err.println("done");
}
static public void main(String[] args)
throws InterruptedException
{
int startup = 1000;
if (args.length 0)
startup = Integer.parseInt(args[0]);
Thread u = new Die() {
void doIt() {
try { Thread.sleep(30); }
catch (InterruptedException _) { }
}
};
u.start();
System.err.println("sleeper started");
Thread.sleep(startup);
u.stop(new Error("throwing from main"));
Thread t = new Die() {
void doIt() { while (true) ; }
};
t.start();
System.err.println("loop started");
Thread.sleep(startup);
t.stop(new Error("throwing from main"));
}
}
Re: Urgent! Problem in running kaffe 1.0.5 on Cygwin!
You might want to try the new "net release" of cygwin. It was just announced yesterday. Just grab the "net installer" from ftp://sourceware.cygnus.com/pub/cygwin/latest/setup.exe and run it to install right over the network. Use a root like C:\Cygwin for best results. The new net release is a lot better than the B.20 release. Mo Dejong Red Hat Inc. On Wed, 19 Apr 2000, Jim King wrote: Hello, I am a Win32 JVM developer. Though I succeeded in building and running Kaffe 1.0b3 on Cygwin one year ago, I failed to running Kaffe 1.0.5. After making install and setting environment parameters, Kaffe.exe shows no output with any JAVA samples. I have also tried to use "make check" command, and almost all the tests were failed. If anyone who has managed to run kaffe 1.0.5 on cygwin or who knows the problem, please help me! My system platform is Cygwin32 b20 on Windows NT 4 and Windows 2000 Pro. BTW: Have any one tried mingw32? Does Kaffe works on it? Best regards, Jim King mailto:[EMAIL PROTECTED]
Re: name mangling bug in kaffeh
Doug, now that you have identified the problem, you sould also taking a crack at fixing it. I think the first patch I ever wrote for Kaffe was for the kaffeh program. kaffeh is small and simple, it is a great place to get started hacking on Kaffe. Just check out the CVS version, make your changes, run "cvs diff" and post your patch to the list. Mo Dejong Red Hat Inc. On Tue, 11 Apr 2000, Douglas De Couto wrote: hi, i tried to post this bug on the web site last night, but it didn't seem to work. When using kaffeh to emit jni headers, underscores in method names are not correctly handled. e.g. get_packet should end up as get_1packet in the .h file. Kaffe is correctly looking for the get_1packet in the shared library, however. Also, overloading is not handled -- but I already saw this in the bug list. cheers, doug -- Douglas S. J. De Couto[EMAIL PROTECTED]
Re: General question
On Wed, 12 Apr 2000, Chris Gray wrote: On Tue, 11 Apr 2000, Mo DeJong wrote: The "best" thing for you to do is write your code on your desktop with the Sun JDK 1.2 installed. Then when your code is finished and you have created your regression tests, compile and run the same code on Kaffe (the GPLed version). If the code does not compile with Kaffe, post a note to the list describing the problem. If you can not fix it yourself, I am sure someone can help you figure out how to fix it. If you can fix the problem yourself, then fix the bug in Kaffe and send a patch to the list. Good point Chris. Yes, everyone is invited to hack on kaffe except those poor folks that agreed to a Sun license and looked at Sun source code. It is important to note that this only applies to source code for the JVM and class libs. You will need to look at the Sun JDK docs and the language specs if you want to help out. You should probably add that what Julien *shouldn't* do is look at the Sun JDK sources to see how to fix kaffe. In fact if he wants to contribute to kaffe then he shouldn't look at Sun's sources at all, right? -- Eur. Ing. Chris Gray MBCS C. Eng. [EMAIL PROTECTED] Mo Dejong Red Hat Inc.
Re: Problem with StringBuffer
On Sun, 2 Apr 2000, Wolfgang Muees wrote: Am Sam, 01 Apr 2000 schrieb Tatu Saloranta: Wolfgang Muees wrote: The right solution for this problem is IMO: don't reuse StringBuffer. It is designed primary as an input buffer for a single string. I think I disagree here; at least if there's no other class for similar purpose. I am interested in optimizing Java-programs, and in general, one of the most efficient optimizations is to recycle objects. Object creation is not a cheap operation. Especially in this case, where StringBuffer does allocate a character array, it means there are at least 2 memory allocations and other initialization code. If the array truncation can be done when the array is being copied (during destringify() or whatever the method was), it won't add a new array allocation. Tatu, I think you miss an important point here: - most JAVA programmers try to code a program that behaves well under all JVMs available. - The default StringBuffer implementation from SUN have problems with resuse of large Stringbuffers. So, IMO all you can do is to code around this problem. best regards Wolfgang This brings up an interesting question. Should kaffe always maintain "compatibility" with a Sun JDK implementation (1.1, 1.2, or 1.3) even when a Sun implementation is clearly wrong or inefficient? I have to wonder when we are going to give up on waiting for Sun to fix bugs in the core libraries and just make sure Kaffe is reasonable. My "pet peeve" API in the java.util.zip package. You can check out the jar implementation I wrote for Kaffe to see an example of the problem with the ZipEntry implementation. In short, the Sun zip impl forces the user to generate a CRC checksum on the data written to the zip file even though the zip library already does this for you. Here is a quick example of what is currently required for the Sun impl (and mirrored in the Kaffe impl). Also note that this only applies to uncompressed zip entries (it is yet another one of the mysteries of the Sun impl). InputStream in = new FileInputStream(entryfile); ZipEntry ze = new ZipEntry(entryname); ze.setMethod(ZipEntry.STORED); ze.setCrc( 0 ); crc = new CRC32(); in = new CheckedInputStream(in,crc); readwriteStreams(in, zos); // this just writes all the data to in ze.setCrc(crc.getValue()); zos.closeEntry(); // this closes the current entry on the ZipOutputStream Why on earth should I need to do this? Code like the following should run faster because a second CRC calculation over the entire stream would not be needed. This code would not run on the Sun JDK because it raises an exception in the closeEntry() method, but we could fix the problem in Kaffe. InputStream in = new FileInputStream(entryfile); ZipEntry ze = new ZipEntry(entryname); ze.setMethod(ZipEntry.STORED); readwriteStreams(in, zos); // this just writes all the data to in zos.closeEntry(); // this closes the current entry on the ZipOutputStream Any comments? Mo DeJong Red Hat Inc.
StringBuffer patch.
Hello.
Between revisions 1.11 and 1.12 of
libraries/javalib/java/lang/StringBuffer.java
the access of the StringBuffer.ensureCapacity(int)V method was changed
from public to private.
+private void ensureCapacity(int minCapacity) {
+ if (minCapacity = 0)
+ return;
+ synchronized (this) {
+ ensureCapacity(minCapacity, false);
+ }
}
-public synchronized void ensureCapacity ( int minimumCapacity ) {
- intn;
- char[] oldBuffer;
+// This method assumes synchronization
This was an error, the method should be public. The change generated
errors like the following in my code.
l:/home/mo/project/kaffe/install/share/kaffe/Klasses.jar \
/home/mo/bin/jikes -g \
-d /home/mo/project/tcljava/unix/Kaffe/jacl \
tcl/lang/*.java sunlabs/brazil/util/regexp/*.java
Found 6 semantic errors compiling "tcl/lang/FileUtil.java":
89. absBuf.ensureCapacity(absBuf.length() + path.length());
*** Error: Method "void ensureCapacity(int $1);" in class
"java/lang/StringBuffer" has private access. Therefore, it is not
accessible in class "tcl/lang/FileUtil".
The following patch fixes the problem.
Sat Apr 1 08:00:00 PST 2000 Mo DeJong [EMAIL PROTECTED]
* libraries/javalib/java/lang/StringBuffer.java: fixed
problem with ensureCapacity() method, it was accidently
changed to private access when it should have been public.
Index: libraries/javalib/java/lang/StringBuffer.java
===
RCS file: /cvs/kaffe/kaffe/libraries/javalib/java/lang/StringBuffer.java,v
retrieving revision 1.12
diff -u -r1.12 StringBuffer.java
--- libraries/javalib/java/lang/StringBuffer.java 2000/03/31
23:29:591.12
+++ libraries/javalib/java/lang/StringBuffer.java 2000/04/01
12:43:13
@@ -104,7 +104,7 @@
}
}
-private void ensureCapacity(int minCapacity) {
+public void ensureCapacity(int minCapacity) {
if (minCapacity = 0)
return;
synchronized (this) {
Mo Dejong
Red Hat Inc.
[Kaffe] Small patch for ArrayForName.java
Could someone apply this patch? It cleans up some old code
and adds a new test case.
Thanks
Mo DeJong
Red Hat Inc.
diff -u -r1.1 ArrayForName.java
--- test/regression/ArrayForName.java 2000/02/29 22:59:42 1.1
+++ test/regression/ArrayForName.java 1999/12/11 14:51:22
@@ -137,6 +137,7 @@
expect("[void", "Exception"); // array of void is not
allowed
expect("[[Ljava/lang/Object;", "Exception"); // classes must use .
as seperator
expect("[[Ljava.lang.String", "Exception"); // need ; at the end
of class name
+ expect("[[java.lang.String;", "Exception"); // need L after [
expect("", "Exception");
}
@@ -149,9 +150,6 @@
msg.append("for clsName \"" + clsName + "\" expected \"" +
expected + "\" but got \"" + result + "\"");
- /*
- throw new RuntimeException(msg.toString());
- */
System.err.println(msg.toString());
}
}
[Kaffe] javac compiler shipped with kaffe fails to compile this!
Hi all.
I just noticed that the javac compiler shipped with Kaffe is badly broken.
It will not compile the following class. I never noticed this before
because I always use jikes, but I would like to see Kaffe work
"out of the box" without forcing the user download jikes. This code
is perfectly legal, the javac compiler shipped with kaffe incorrectly
rejects it.
abstract class Inherit {
abstract void foo() throws ClassNotFoundException;
}
public class InheritOverideException extends Inherit {
void foo() throws ClassNotFoundException, SecurityException {}
}
Is this the right place to send compiler problem reports?
Mo Dejong
Red Hat Inc.
Re: [Kaffe] whatever became of my Class.forName() patches?
On Tue, 29 Feb 2000, Archie Cobbs wrote:
Mo DeJong writes:
I was just looking over the ChangeLog and I noticed that my
Class.forName() patches never got added. I seem to remember
that there was a problem with one of the changes in the patch.
I am going to repost my patch minus the change that was
causing problems and see if that is acceptable. Does anyone
see any problems with the patch in its current form?
I'm committing it now..
Nice catch, that should generate an error too. I added a test case
for this to my forName tests and attached it to this email.
Like so right?
expect("[[Ljava.lang.String", "Exception"); // need ; at the end of class
name
Mo DeJong
Red Hat Inc
Quick question: it appears that kaffe accepts "Ljava/lang/String"
even though you'd think a trailing semi-colon is required.
Is this what JDK does as well (ie, semi-colon is optional at the
end of a string)?
-Archie
public class ArrayForName {
public static void testLoadArray() throws Exception {
// Loading by built-in type ID is not allowed
// int != I
// boolean != Z
// long != J
// float!= F
// double != D
// byte != B
// short!= S
// char != C
// void != V
expect("I", "Exception");
expect("Z", "Exception");
expect("J", "Exception");
expect("F", "Exception");
expect("D", "Exception");
expect("B", "Exception");
expect("S", "Exception");
expect("C", "Exception");
expect("V", "Exception");
// Not possible to load by builtin type name
expect("int", "Exception");
expect("boolean", "Exception");
expect("long","Exception");
expect("float", "Exception");
expect("double", "Exception");
expect("byte","Exception");
expect("short", "Exception");
expect("char","Exception");
expect("void","Exception");
// Test loading an array by built-in type id
// int[]== [I
// int[][] == [[I
// boolean[]== [Z
// boolean[][] == [[Z
// long[] == [J
// long[][] == [[J
// float[] == [F
// float[][]== [[F
// double[] == [D
// double[][] == [[D
// byte[] == [B
// byte[][] == [[B
// short[] == [S
// short[][]== [[S
// char[] == [C
// char[][] == [[C
expect("[I", "int[]");
expect("[[I", "int[][]");
expect("[Z", "boolean[]");
expect("[[Z", "boolean[][]");
expect("[J", "long[]");
expect("[[J", "long[][]");
expect("[F", "float[]");
expect("[[F", "float[][]");
expect("[D", "double[]");
expect("[[D", "double[][]");
expect("[B", "byte[]");
expect("[[B", "byte[][]");
expect("[S", "short[]");
expect("[[S", "short[][]");
expect("[C", "char[]");
expect("[[C", "char[][]");
// Array of type void is not allowed
expect("[V","Exception");
expect("[[V", "Exception");
expect("[[[V", "Exception");
// When loading an array using the built-in
// type id, id must be at end of string
expect("[II", "Exception");
expect("[ZZ", "Exception");
expect("[JJ", "Exception");
expect("[FF", "Exception");
expect("[DD", "Exception");
expect("[BB", "Exception");
expect("[SS", "Exception");
expect("[CC", "Exception");
expect("[ZZ", "Exception");
expect("[C;", "Exception");
expect("[C\0;", "Exception");
// [L + Class + ;
// Primitive Class name is not valid
Re: Class.forName() patches
On Tue, 29 Feb 2000, Archie Cobbs wrote: Mo, I've applied the following patches -- which are a modification of yours, and now four tests are failing: FAIL: Bean.java FAIL: BeanBug.java FAIL: Reflect.java FAIL: ReflectInvoke.java Ugh. Could be my changes but they should be equivalent to yours.. I think the problem may be that kaffe calls classFromSig() on types that are part of a larger string (and not necessarily at the end of the string) such as function types.. eg: Godmar emailed me to say that he was working on some improvements to my patch that would fix things once and for all. We should wait for his improved patches and add them instead of my original patch. I was unaware of this so I thought my original patch had been lost in the shuffle. Thanks Mo Dejong Red Hat Inc. "(Ljava/lang/String;II)V" Please let me know what you want me to do... -Archie
[Kaffe] whatever became of my Class.forName() patches?
I was just looking over the ChangeLog and I noticed that my
Class.forName() patches never got added. I seem to remember
that there was a problem with one of the changes in the patch.
I am going to repost my patch minus the change that was
causing problems and see if that is acceptable. Does anyone
see any problems with the patch in its current form?
Mo Dejong
Red Hat Inc.
Index: kaffe/kaffevm/classMethod.c
===
RCS file: /cvs/kaffe/kaffe/kaffe/kaffevm/classMethod.c,v
retrieving revision 1.75
diff -u -r1.75 classMethod.c
--- kaffe/kaffevm/classMethod.c 2000/01/19 11:04:31 1.75
+++ kaffe/kaffevm/classMethod.c 2000/01/29 01:19:59
@@ -1110,12 +1122,13 @@
}
class = loadClass(utf8, NULL, einfo);
utf8ConstRelease(utf8);
+
if (class != 0) {
if (processClass(class, CSTATE_COMPLETE, einfo) == true) {
return (class);
}
}
- return (0);
+ return (NULL);
}
/*
@@ -2281,12 +2294,18 @@
/* If we couldn't resolve the element type, there's no way we can
* construct the array type.
*/
- if (c == 0) {
- return (0);
+ if (c == NULL) {
+ return (NULL);
}
/* Build signature for array type */
if (CLASS_IS_PRIMITIVE (c)) {
+ /* An array of type void is not allowed */
+ if (strcmp(CLASS_CNAME(c), "void") == 0) {
+ postException(einfo, JAVA_LANG(VerifyError));
+ return (NULL);
+ }
+
arr_class = CLASS_ARRAY_CACHE(c);
if (arr_class) {
return (arr_class);
@@ -2304,12 +2323,12 @@
arr_name = utf8ConstNew(sig, -1); /* release before returning */
if (!arr_name) {
postOutOfMemory(einfo);
- return 0;
+ return (NULL);
}
centry = lookupClassEntry(arr_name, c-loader, einfo);
if (centry == 0) {
utf8ConstRelease(arr_name);
- return (0);
+ return (NULL);
}
if (centry-class != 0) {
Index: kaffe/kaffevm/itypes.c
===
RCS file: /cvs/kaffe/kaffe/kaffe/kaffevm/itypes.c,v
retrieving revision 1.17
diff -u -r1.17 itypes.c
--- kaffe/kaffevm/itypes.c 1999/11/29 23:44:10 1.17
+++ kaffe/kaffevm/itypes.c 2000/01/29 01:19:59
@@ -131,21 +131,49 @@
Hjava_lang_Class*
classFromSig(const char** strp, Hjava_lang_ClassLoader* loader, errorInfo *einfo)
{
- Hjava_lang_Class* cl;
+ Hjava_lang_Class* cl = NULL;
Utf8Const* utf8;
const char* start;
const char* end;
switch (*(*strp)++) {
- case 'V': return (voidClass);
- case 'I': return (intClass);
- case 'Z': return (booleanClass);
- case 'S': return (shortClass);
- case 'B': return (byteClass);
- case 'C': return (charClass);
- case 'F': return (floatClass);
- case 'D': return (doubleClass);
- case 'J': return (longClass);
+ case 'V':
+ if (cl == NULL)
+ cl = voidClass;
+ case 'I':
+ if (cl == NULL)
+ cl = intClass;
+ case 'Z':
+ if (cl == NULL)
+ cl = booleanClass;
+ case 'S':
+ if (cl == NULL)
+ cl = shortClass;
+ case 'B':
+ if (cl == NULL)
+ cl = byteClass;
+ case 'C':
+ if (cl == NULL)
+ cl = charClass;
+ case 'F':
+ if (cl == NULL)
+ cl = floatClass;
+ case 'D':
+ if (cl == NULL)
+ cl = doubleClass;
+ case 'J':
+ if (cl == NULL)
+ cl = longClass;
+
+ if (cl != NULL) {
+ /* If build in type char is not at the end of the string, malformed
+signature */
+ if (*(*strp) != 0) {
+ postException(einfo, JAVA_LANG(VerifyError));
+ return (NULL);
+ }
+ }
+
+ return (cl);
case '[': return (lookupArray(classFromSig(strp, loader, einfo),
einfo));
case 'L':
@@ -159,11 +187,17 @@
utf8 = utf8ConstNew(start, end - start);
if (!utf8) {
postOutOfMemory(einfo);
- return 0;
+ return (NULL);
}
cl = loadClass(utf8, loader, einfo);
utf8ConstRelease(utf8);
- return(cl);
+
+ /* Only class names can appear after a [L in the class name */
+
Re: large Class.forName() patch
On Thu, 3 Feb 100, Godmar Back wrote: Ok, that sounds like a plan. The only other problem I noticed is that Kaffe seems to use plain char* types for class names. These class names really should be in unicode strings or at least UTF8 strings. The current Kaffe implementation means that a \0 embedded in the class name will screw up code that expects a \0 at the end of a string. One of the regression test checks for this. I'm working on it. We'll first try renaming the basic types internally w/o breaking gcj (Jason sent me a patch for that), and see where that gets us, and then the rest. I think we should be able to match Sun's output exactly. Unfortunately, egcs broke on me right after I checked it out today so waiting on that to be fixed before I can do that. You can add it to Kaffe's regression tests but I am planning on turning it into a Mauve test so you should not really need to add it. Mo Dejong Red Hat Inc. Thanks very much for your regression test. - Godmar It sounds like there is still some debate as to how the primitive classes should be searched for by name, so could we agree on this trimmed down patch that does not include the part that disables lookups for "int" and such?
Re: large Class.forName() patch
On that note, here is an updated regression test that takes care
of the case where you have an actual Class name "int" or "I" and
it also checks for / in the name of a class passed to forName().
Mo Dejong
Red Hat Inc.
On Tue, 1 Feb 2000, Godmar Back wrote:
Let me look at Mo's patch more closely and maybe we find something
that will not break the gcj stuff. I kind of like to keep the primitive
classes in the classpool---this I think is nicer for keeping statistics
on all classes, for instance.
As for the Class.forName() interface, I think it's better to strive
for 100% Sun compatibility here, which means to not provide backdoor
ways to lookup primitive classes such as looking up "I" or "int" if
Sun doesn't. For instance, I got totally
confused already when I thought that kaffe could look up "I" before I
realized that's because I do all my tests in a directory filled with
A.class, B.class, ..., I.class, ... Z.class files.
That said, I find Sun's implementation of Class.forName horrible.
Why do I have use the L; form in an array but not for simple classes?
It makes no sense. Of course, the JDK doc also doesn't document it.
And why shouldn't you be able to look primitive classes up by name?
- Godmar
public class ArrayForName {
public static void testLoadArray() throws Exception {
// Loading by built-in type ID is not allowed
// int != I
// boolean != Z
// long != J
// float!= F
// double != D
// byte != B
// short!= S
// char != C
// void != V
expect("I", "Exception");
expect("Z", "Exception");
expect("J", "Exception");
expect("F", "Exception");
expect("D", "Exception");
expect("B", "Exception");
expect("S", "Exception");
expect("C", "Exception");
expect("V", "Exception");
// Not possible to load by builtin type name
expect("int", "Exception");
expect("boolean", "Exception");
expect("long","Exception");
expect("float", "Exception");
expect("double", "Exception");
expect("byte","Exception");
expect("short", "Exception");
expect("char","Exception");
expect("void","Exception");
// Test loading an array by built-in type id
// int[]== [I
// int[][] == [[I
// boolean[]== [Z
// boolean[][] == [[Z
// long[] == [J
// long[][] == [[J
// float[] == [F
// float[][]== [[F
// double[] == [D
// double[][] == [[D
// byte[] == [B
// byte[][] == [[B
// short[] == [S
// short[][]== [[S
// char[] == [C
// char[][] == [[C
expect("[I", "int[]");
expect("[[I", "int[][]");
expect("[Z", "boolean[]");
expect("[[Z", "boolean[][]");
expect("[J", "long[]");
expect("[[J", "long[][]");
expect("[F", "float[]");
expect("[[F", "float[][]");
expect("[D", "double[]");
expect("[[D", "double[][]");
expect("[B", "byte[]");
expect("[[B", "byte[][]");
expect("[S", "short[]");
expect("[[S", "short[][]");
expect("[C", "char[]");
expect("[[C", "char[][]");
// Array of type void is not allowed
expect("[V","Exception");
expect("[[V", "Exception");
expect("[[[V", "Exception");
// When loading an array using the built-in
// type id, id must be at end of string
expect("[II", "Exception");
expect("[ZZ", "Exception");
expect("[JJ", "Exception");
expect("[FF", "Exception");
expect("[DD", "Exception");
expect("[BB", "Exception");
exp
Re: large Class.forName() patch
On Sun, 30 Jan 2000, Archie Cobbs wrote:
Mo DeJong writes:
I have been working on getting Class.forName() working more like
the Sun JDK and I have a patch that I would like to get some comments
I don't understand this comment:
+ /* This is kind of strange, but Sun's implementation
+ does not allow lookups like Class.forName("int"),
+ so if this is a primitive type, we just pretend
+ it could not be found. It would be handy to load
+ "int" or "char" by name, but oh well */
Well, then why does Kaffe allow lookups by name? I thought it might
be a handy feature but it is not something that is allowed in the
Sun JDK. My patch removed the ability to do lookups like
Class.forName("int") and Class.forName("void"), so that Kaffe
would act more like the Sun JDK. I think your "Quick Take" on
it was the same as mine, I just want to make sure that everyone
agrees that such a lookup should not be allowed and that the
patch I sent is the correct way to disallow them. If you like we
can change the "This is kind of strange, but" text to
"Testing shows that Sun's implementation ...".
Mo DeJong
Red Hat Inc.
Why would a JVM be expected to recognize a Java language keyword?
As far as the JVM is concerned, Java is just one of many higher
level languages that are capable of being compiled to bytecode
(or am I misreading something, this was just a quick take).
-Archie
___
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
Re: BUG in ZipInputStream
This bug has been around in one form or another for many many months. The problem seems to be related to the header written before the actual data is placed in the zip file. I have been meaning to get around to fixing it but I just have not had the time to write up all the test cases needed to fix it once and for all. If you want to jump in and take a whack at it, the problem is in the class ZipOutputStream.java! Mo Dejong Red Hat Inc. On Fri, 28 Jan 2000, Hiroshi Oota wrote: ;; I built Kaffe from CVS tree today under FreeBSD-3.4-RELEASE. ;; ;; The ChangeLog says ;; ;; Tue Dec 28 10:14:16 CET 1999 Edouard G. Parmelan [EMAIL PROTECTED] ;; ;; Do you mean this is the latest entry in the ChangeLog? It's more than ;; a month old, and there have been dozens of changes after that. No, I picked up related entry from ChangeLog. I think the ZipInputStream still has a bug. try, `jar tvf /usr/local/share/kaffe/kjc.jar'. It will shows 1: 0 Mon Dec 13 14:11:46 GMT+9:00 1999 META-INF/MANIFEST.MF 2: 0 Mon Dec 13 13:32:24 GMT+9:00 1999 at/dms/util/ 3: 0 Mon Dec 13 13:32:24 GMT+9:00 1999 at/dms/util/ArrayLocator.class 4: 0 Mon Dec 13 13:32:24 GMT+9:00 1999 at/dms/util/Utils.class 5:java.io.IOException: LOC header signature bad: 5007 6:at java.lang.Throwable.init(Throwable.java:38) 7:at java.lang.Exception.init(Exception.java:24) 8:at java.io.IOException.init(IOException.java:25) 9:at java.util.zip.ZipInputStream.getNextEntry(ZipInputStream.java:55) 10: at kaffe.tools.jar.Jar.listFilesInJar(Jar.java:601) 11: at kaffe.tools.jar.Jar.processJar(Jar.java:402) 12: at kaffe.tools.jar.Jar.start(Jar.java:60) 13: at kaffe.tools.jar.Jar.main(Jar.java:39) the lines 1-4 says that the kaffe environment which I use is includes the following changes. Sun Jan 9 02:50:29 CET 2000 Edouard G. Parmelan [EMAIL PROTECTED] snip * libraries/javalib/java/util/zip/ZipEntry.java: add new package method setDosTime(). * libraries/javalib/java/util/zip/ZipInputStream.java (getNextEntry): Use setDosTime() to set time entry. -- HIROSHI OOTA [EMAIL PROTECTED]
