Guilhem Lavaux <[EMAIL PROTECTED]> wrote:
It seems that when we don't use iconv there are some problems in initializing the EncodingManager. CharToByteConverter.getEncoder needs ClassLoader.getSystemResource which needs ClassLoader.staticData. However staticData is not yet initialized because getEncoder is called while initializing ClassLoader.StaticData.systemClassLoader. Everything goes to a NPE.
The initialization loop can be broken either:
* by removing the dependency on getSystemResource (but I bet it will be difficult)
* by getting rid of AppClassLoader which is the source of the loop: it uses URLClassLoader.
Note that AppClassLoader did not extend URLClassLoader in the beginning. That was changed because some application wanted to call addURL on the SystemClassLoader (I don't remember which application that was, you'd have to search the archive for details).
Hallo Helmer,
thanks for reminding me of that one. I've googled around and it was
2003-07-26 Dalibor Topic <[EMAIL PROTECTED]>
[snip]
* libraries/javalib/kaffe/lang/AppClassLoader.java:
Extend URLClassLoader. OpenEJB expects the application class loader to
extend URLClassLoader.
(AppClassLoader) cass superclass contructor with empty array of URLs.
(findResources, findResource) changed access to public as they are
public
in URLClassLoader.A third option might be to find out why I don't get the exception in my tree ;) If I undef HAVE_ICONV_H and HAVE_ICONV in CharToByteIconv.c and ByteToCharIconv.c I don't get any exceptions when trying to start kjc, I just see the usual messages from kjc when no input files are given. The only difference between my local tree and HEAD is the merged java.lang.Class implementation from GNU classpath.
Oh, then I vote for the tree without exceptions and the Class class merged in :)
cheers, dalibor topic
_______________________________________________ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
