Ok, so here's my crack-brained theory, not sure if it's right:
-when your plugin loader starts executing, the Plugin interface has not yet been referenced so no classloader has bothered to find it
-you come to the point where you tell your classloader to pick up the class file from disk
-it does so and discovers that it also needs to know about the Plugin interface in order to properly link the plugin bytecode
-it asks its parent classloader (in this case, the jvm classloader) if it knows about Plugin, answer is 'no'
-your classloader then looks around for the Plugin bytecode and finds it on the same classpath as the actual plugin implementation so it loads it
-now your code tries to cast the new implementation
-it now needs to have a definition of the Plugin interface but the jvm classloader doesn't have one (classes are not passed up the classloader hierarchy)
-so it looks on its own classpath, finds Plugin and loads it
-you now have two different versions
The solution? Make sure the Plugin interface is loaded and linked before you do stuff with your own classloader. Try declaring a Plugin as a member of your PluginLoader class, even if you never use it. It will need to be loaded and linked before any code gets executed and when your classloader asks its parent for the Plugin class, it will be there.
If that works, it's a bit of a dirty hack but at least it would shed some light on the situation. In the long run, it's probably wiser not to have the Plugin interface in the same folder hierarchy as the Plugin implementations.
