Re: loadClass(String) vs loadClass(String, bool)

[Tom Tromey <tromey at redhat dot com>]

>>>>> "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.

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

Tom