The Bukkit class loader usually does fine and doesn't need to care, but the issue comes when two plugins contain the same lib (or two classes with exactly same name), the PluginClassLoader will attempt to load class from the previously loaded plugin if no cached class found, then load it from it's belonging plugin's file. If these two classes have different content, then the plugin would crash.

Normally this wouldn't happen, and two plugins shouldn't have classes with the same full name. But it is weird that class loader preferred to load classes from another jar rather than its own.

So this issue is mainly caused by logic in PluginClassLoader::findClass, it will try to find cached class from JavaPluginLoader and other PluginClassLoader first, then find bytecode file in its own jar. But finding class through all other plugins just for a cache doesn't seem to be more efficient than finding its own.

Another thing about PluginClassLoader is that it's the only option to load plugin, adding an option to allow developers to specify a custom class loader for their own plugin would be better. 

 

For example in Plugin A:

public class Test

{     public static void test() \{System.out.println("Test plugin A loaded!");}

}

public final class TestPluginA extends JavaPlugin

{ public void onEnable() \{System.out.println("Loading plugin A!");Test.test();}

}

 

And Plugin B:

public class Test

{     public static void test() \{System.out.println("Test plugin B loaded!");}

}

public final class TestPluginB extends JavaPlugin

{ public void onEnable() \{System.out.println("Loading plugin B!");Test.test();}

}

 

The two classes named Test are in the package com.example in two different plugin.

 

There're always a plugin that can print "Loading plugin A following" with "Test plugin A loaded".

Then another plugin will print "Loading plugin B following" with a Bukkit dependency warning and "Test plugin A loaded".