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
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
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
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
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
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
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?
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
