loadClass(String) vs loadClass(String, bool)

Sun Apr 17 09:12:00 GMT 2005

Tom Tromey writes:
 > >>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:
 > 
 > Andrew> Calling loadClass(String) is different from calling
 > Andrew> loadClass(String, false) because some class loaders override
 > Andrew> one method but not the other.
 > 
 > Andrew> This is an old version of PluginClassLoaderWrapper so this
 > Andrew> might now have been fixed -- it's just an example. But it
 > Andrew> does mean that in some applications we have to be very careful
 > Andrew> about what we call within libgcj. It looks to me like
 > Andrew> loadClass(String) is always to be preferred.
 > 
 > The thing is, we are currently calling the 1-argument form, and that
 > is causing Mark W. problems with Eclipse. (In the past we called the
 > 2-argument form.) In fact I was going to revert this and go back to
 > the 2 argument form to make things work.
Ah. :-)
 > Mark and I debugged his failure over irc yesterday. Apparently the
 > problem is that if libgcj calls the 1-arg form, some Eclipse
 > ClassLoader erroneously calls resolveClass.
 > 
 > About PluginClassLoaderWrapper... this is only used by the help
 > server, I think.
Like I said, it's just an example. The same thing happens in other
places in Eclipse.
 > The bug Mark was seeing was more central. Of course, really
 > PluginClassLoaderWrapper should not override loadClass() but rather
 > findClass(); I'm planning to add a warning to gcjx for this.
 > 
 > One question is whether we should have resolveClass() do anything
 > at all. It is a lame part of the API and perhaps the leeway given
 > to the implementation in terms of linking could be stretched to
 > cover this.
Maybe, but we'd risk breaking compatibility. All we can do is try to
determine what others do -- and do te same thing!
Andrew.