[kaffe] loadClass() vs. loadClass()
Hi, I gave JBoss another try recently and finally got to a point where I really don't know what to do. As you will know, java.lang.ClassLoader contains two different loadClass methods, one that takes a String and a boolean as its parameters and one that takes only a String. Whenever kaffe has to load some class using a user defined loader, it invokes the two parameter form of loadClass. JBOSS however contains a class loader that only overrides the loadClass(String) method, but not the other one. This means that it doesn't work with kaffe at the moment, because some classes will not be found. The simple and quick fix would be to modify kaffe so it calls the loadClass(String) method of a user defined class loader instead of the loadClass(String, boolean) one. In theory, this should not break existing code since loadClass(String) simply calls the other method. I don't know whether this is the right way to fix this, though. Therefore, I'd like to hear other opinions about this before deciding whether or not to do the change. Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] loadClass() vs. loadClass()
Hi, I gave JBoss another try recently and finally got to a point where I really don't know what to do. As you will know, java.lang.ClassLoader contains two different loadClass methods, one that takes a String and a boolean as its parameters and one that takes only a String. Whenever kaffe has to load some class using a user defined loader, it invokes the two parameter form of loadClass. Looks like this is just wrong, the javadoc says the single parameter one should be called... JBOSS however contains a class loader that only overrides the loadClass(String) method, but not the other one. This means that it doesn't work with kaffe at the moment, because some classes will not be found. Hmm, they should be overriding findClass(), is there any reason why they needed to use loadClass()? Regards, Helmer tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] loadClass() vs. loadClass()
Hi, On Fri, 2003-09-19 at 16:23, Helmer Krämer wrote: Whenever kaffe has to load some class using a user defined loader, it invokes the two parameter form of loadClass. [...] The simple and quick fix would be to modify kaffe so it calls the loadClass(String) method of a user defined class loader instead of the loadClass(String, boolean) one. In theory, this should not break existing code since loadClass(String) simply calls the other method. I don't know whether this is the right way to fix this, though. I think this is the correct fix. See: http://java.sun.com/docs/books/vmspec/2nd-edition/html/ConstantPool.doc.html#79448 1 Since JDK release 1.1 the Java virtual machine invokes the loadClass method of a class loader in order to cause it to load a class or interface. The argument to loadClass is the name of the class or interface to be loaded. There is also a two-argument version of the loadClass method. The second argument is a boolean that indicates whether the class or interface is to be linked or not. Only the two-argument version was supplied in JDK release 1.0.2, and the Java virtual machine relied on it to link the loaded class or interface. From JDK release 1.1 onward, the Java virtual machine links the class or interface directly, without relying on the class loader. You should also call the one argument ClassLoader.loadClass(String) method for Class.forName(), but I cannot quickly find where in the spec this is defined. Cheers, Mark signature.asc Description: This is a digitally signed message part
[kaffe] BeOS Kaffe !!!
I am having problems in compiling kaffe-1.1.1 in BeOS 5.03 !!! I used this parameters in configure: % ./configure --disable-shared --prefix=/boot/home/bekaffe --with-threads=beos-native .. % make ... After that i got the error: gcc -DHAVE_CONFIG_H -I. -I. -I../../config -I../../include -I../kaffevm -I./../kaffevm -DKAFFEH -DKVER='1.1.0' -I/boot/home/jp/kaffe-1.1.0/./kaffe/kaffevm -I/boot/home/jp/kaffe-1.1.0/./kaffe/kaffevm/systems/beos-native -I../../config -I../../include -DKAFFE_VMDEBUG -g -O2 -Wall -Wstrict-prototypes -c `test -f 'support.c' || echo './'`support.c In file included from /boot/home/jp/kaffe-1.1.0/kaffe/kaffevm/systems/beos-native/jthread.h:25, from /boot/home/jp/kaffe-1.1.0/kaffe/kaffevm/classMethod.h:21, from /boot/home/jp/kaffe-1.1.0/kaffe/kaffeh/support.c:23: /boot/home/jp/kaffe-1.1.0/kaffe/kaffevm/thread.h:19: java_lang_Throwable.h: No such file or directory /boot/home/jp/kaffe-1.1.0/kaffe/kaffevm/thread.h:20: java_lang_Thread.h: No such file or directory /boot/home/jp/kaffe-1.1.0/kaffe/kaffevm/thread.h:21: java_lang_ThreadGroup.h: No such file or directory make[3]: *** [support.o] Error 1 make[3]: Leaving directory `/boot/home/jp/kaffe-1.1.0/kaffe/kaffeh' make[2]: *** [stamp-kaffeh] Error 2 make[2]: Leaving directory `/boot/home/jp/kaffe-1.1.0/include' make[1]: *** [all] Error 2 make[1]: Leaving directory `/boot/home/jp/kaffe-1.1.0/include' make: *** [all-recursive] Error 1 I see that the files java_lang_Throwable.h, java_lang_Thread.h, java_lang_ThreadGroup.h weren't found !! I found this files in the package BeKaffe and solved those problems, but then i got more error in compiling files under directories net. How can I solve this problem ??? _ Voce quer um iGMail protegido contra vírus e spams? Clique aqui: http://www.igmailseguro.ig.com.br Ofertas imperdíveis! Link: http://www.americanas.com.br/ig/ ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] loadClass() vs. loadClass()
On Fri, 19 Sep 2003 09:12:44 -0600 (MDT)
Timothy Stack [EMAIL PROTECTED] wrote:
Hi,
I gave JBoss another try recently and finally got to a
point where I really don't know what to do.
As you will know, java.lang.ClassLoader contains two
different loadClass methods, one that takes a String
and a boolean as its parameters and one that takes
only a String. Whenever kaffe has to load some class
using a user defined loader, it invokes the two parameter
form of loadClass.
Looks like this is just wrong, the javadoc says the single parameter one
should be called...
I'll commit the change to classMethod.c, then.
JBOSS however contains a class loader that only overrides
the loadClass(String) method, but not the other one.
This means that it doesn't work with kaffe at the moment,
because some classes will not be found.
Hmm, they should be overriding findClass(), is there any reason why they
needed to use loadClass()?
Their class loader looks like this:
===8==
public static Object create(final Class intf,
final ObjectName name,
final MBeanServer server)
{
// make a which delegates to MBeanProxyInstance's cl for it's class resolution
ClassLoader cl = new ClassLoader(intf.getClassLoader())
{
public Class loadClass(final String className) throws ClassNotFoundException
{
try {
return super.loadClass(className);
}
catch (ClassNotFoundException e) {
// only allow loading of MBeanProxyInstance from this loader
if (className.equals(MBeanProxyInstance.class.getName())) {
return
MBeanProxyInstance.class.getClassLoader().loadClass(className);
}
// was some other classname, throw the CNFE
throw e;
}
}
};
return Proxy.newProxyInstance(cl,
new Class[] { MBeanProxyInstance.class, intf },
new MBeanProxyExt(name, server));
}
===8=
So I think they could as well move the catch block
into a findClass() method.
Regards,
Helmer
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] loadClass() vs. loadClass()
On Fri, 19 Sep 2003 17:20:05 +0200 Mark Wielaard [EMAIL PROTECTED] wrote: Hi, On Fri, 2003-09-19 at 16:23, Helmer Krämer wrote: Whenever kaffe has to load some class using a user defined loader, it invokes the two parameter form of loadClass. [...] The simple and quick fix would be to modify kaffe so it calls the loadClass(String) method of a user defined class loader instead of the loadClass(String, boolean) one. In theory, this should not break existing code since loadClass(String) simply calls the other method. I don't know whether this is the right way to fix this, though. I think this is the correct fix. See: http://java.sun.com/docs/books/vmspec/2nd-edition/html/ConstantPool.doc.html#79448 1 Since JDK release 1.1 the Java virtual machine invokes the loadClass method of a class loader in order to cause it to load a class or interface. The argument to loadClass is the name of the class or interface to be loaded. There is also a two-argument version of the loadClass method. The second argument is a boolean that indicates whether the class or interface is to be linked or not. Only the two-argument version was supplied in JDK release 1.0.2, and the Java virtual machine relied on it to link the loaded class or interface. From JDK release 1.1 onward, the Java virtual machine links the class or interface directly, without relying on the class loader. You should also call the one argument ClassLoader.loadClass(String) method for Class.forName(), but I cannot quickly find where in the spec this is defined. Could this probably help with the problem about loading classes during verification, too? One of the problems was that we thought we couldn't predict the state of a class that's returned by a user class loader, but this paragraph seems to define this, doesn't it ? Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Freeing jit temp data on demand (Was: Re: JavaLayer 0.3.0
hi, now the jit frees its temp data, but I don't hear a sound anymore and the cpu usage is at ninety-something percent ;) when I run kaffe with -verbosecall and pipe the output to a file, I can hear some sound, but it skips. Weird. Could you take a third look at the code? yeah, I just have to find a machine where sound works. Okie, I've duplicated the problem, the gc is getting stuck and that eats up all the CPU. In particular it gets stuck in startGC() looping on the finalizer list. I tried backing out helmer's last changes to the GC and it seems to run fine again, but I'm not really sure where the bug is just yet. btw, playing mp3's with kaffe is kinda neat! cheers, dalibor topic tim tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] loadClass() vs. loadClass()
Could this probably help with the problem about loading
classes during verification, too? One of the problems
was that we thought we couldn't predict the state of a
class that's returned by a user class loader, but this
paragraph seems to define this, doesn't it ?
I don't think so, the root of the problem is that once you call into user
code, all bets are off. For example:
Class loadClass(String name)
{
Class retval;
...
retval.newInstance();
return retval;
}
The call to newInstance() will be the first-use, so the VM will have to
complete linking before loadClass() returns control to the VM.
Regards,
Helmer
tim
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
