[kaffe] Character encoder/ClassLoader initialization

[Dalibor Topic]

Helmer Krämer wrote:
> Guilhem Lavaux <guilhem at kaffe.org> 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 <robilad at kaffe.org>
	[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