Bug#432541: eclipse-cdt FTBFS with gcj-4.2
aph at redhat.com
Wed Mar 5 12:36:22 UTC 2008
Andrew Haley wrote:
> Andrew Haley wrote:
>> OK, I've found it. The ClassNotFoundException is thrown from a security
>> in libgcj. We are calling Method m1 from method m0, and m1's class loader
>> is different from m0's class loader. We have to check that for every arg
>> in m1, the actual type is the same in both m1.loader and m0.loader.
>> The method in question is
>> org.eclipse.core.runtime.Platform.getPlugin(String), which returns an
>> instance of org.eclipse.core.runtime.Plugin. It gets this
>> by calling org.eclipse.core.internal.plugins.PluginDescriptor.getPlugin().
>> When we do the security check, we call Platform's class loader to ask it
>> to loadClass("org.eclipse.core.runtime.Plugin") and it throws a
> OK, I've discovered some more. The class loader that's throwing the
> exception is a
> org.eclipse.osgi.framework.internal.core.BundleLoader, and
> it's being asked to find org.eclipse.core.runtime.Plugin. Now, this
> is where it gets really interesting.
> org.eclipse.core.runtime.Plugin is defined in
> along with a few other classes, including
> org.eclipse.core.runtime.IPluginDescriptor and
> IPluginDescriptor's class loader is not able to find
OK, and the *reason* for this is that IPluginDescriptor is loaded not
but from eclipse/plugins/org.eclipse.core.runtime.compatibility.registry_3.2.100.v20070316/runtime_registry_compatibility.jar
So, if you ask IPluginDescriptor's class loader to find Plugin it
throws a ClassNotFoundException.
The only files in runtime_registry_compatibility.jar are:
So, I think I now have enough to write a test case. Two class
loaders, one of which loads a subset of the other's classes. Call
an interface in the class defined by the subset class loader and
see what happens.
More information about the pkg-java-maintainers