When is ClassDefiner used?

I've run into a ClassLoader problem, and it goes something like this:

java.lang.ClassCastException: com.google.appengine.api.datastore.Key 
cannot be cast to com.google.appengine.api.datastore.Key

At first I had no idea how this could happen, but after some search I learned that ClassCastException can also be thrown if the same class is loaded by 2 different ClassLoaders. I continued to dig around and discovered this:

[Loaded com.google.appengine.api.datastore.Key from JVM_DefineClass]

...

[Loaded com.google.appengine.api.datastore.Key from file:/home/alex/java/eclipse/plugins/com.google.appengine.eclipse.sdkbundle_1.5.1.r36v201106211634/appengine-java-sdk-1.5.1/lib/user/appengine-api-1.0-sdk-1.5.1.jar]

This is indeed the proof that Key is actually loaded in 2 different ClassLoaders. However, I have no idea how to continue my investigation; I know a new ClassLoad开发者_开发问答er is instantiated via ClassDefiner (see http://www.java2s.com/Open-Source/Java-Document/6.0-JDK-Modules-sun/reflect/sun/reflect/ClassDefiner.java.htm), but I have no idea why. I've googled for some answers, but found none.

Does it have anything to do with the fact that a base test sets a different ClassLoader using @BeforeClass? But if that's true (I can accept JVM_DefineClass), what is the second ClassLoader all about?

Hope to find some answers here, Alex.

I'm not sure I quite grasp your problem, but nobody else is answering, so I'll give it a shot. First, what does ClassDefiner have to do with this? Are you using it somewhere? Even though ClassDefiner creates a new ClassLoader, it uses the given parent ClassLoader as the new ClassLoader's parent, and default ClassLoader behavior is to search for a class in a parent ClassLoader before loading it itself, so this by itself won't cause the "class is loaded by two ClassLoaders" problem that you're describing.

What do you mean about setting a different ClassLoader in @BeforeClass? If you load a class in some ClassLoader, keep the class or instances of the class around somewhere, and then arbitrarily switch ClassLoaders, you could certainly see problems like this.

Does any of that help? I get the feeling you're looking for a bug in the Java core classes when you should probably be looking at your own code. Always be cautious to assume a bug in an established library.