Shulou(Shulou.com)06/01 Report--

Custom Classloader leads to what to do with ClassCastException. For this question, this article describes in detail the corresponding analysis and solutions, hoping to help more partners who want to solve this problem to find a more simple and feasible way.

Background java.lang.ClassCastException: cn.com.nightfield.Plugin cannot be cast to cn.com.nightfield.Plugin

The same class can't be cast? What the hell is this?

Problem description

Custom class loaders (Classloader) are common and allow us to load class files from custom file system directories, networks, and even various file types of databases (jar, war, zip, etc.). Our project uses an open source class management tool, PF4J, to load the class file in the specified directory. But the strange thing is that when we loaded class and forcefully changed it to the target type, we reported java.lang.ClassCastException, which is obviously the same class!

Analysis of problems

First of all, the error is related to the custom class loader. The last little demo simulates the above error:

Package cn.com.nightfield.jvm.classloader;// defines a class under class path public class Plugin {} package cn.com.nightfield.jvm.classloader;import java.net.URL;import java.net.URLClassLoader;// customizes a class loader public class CustomizedClassLoader extends URLClassLoader {public CustomizedClassLoader (URL [] urls) {super (urls) } protected Class loadClass (String name, boolean resolve) throws ClassNotFoundException {synchronized (getClassLoadingLock (name)) {/ / if it is not a class under a custom directory, it is entrusted to AppClassloader to load if (! name.startsWith ("cn.com.nightfield.jvm.classloader")) {return super.loadClass (name, resolve) } / / if the class under the custom directory is loaded directly, it violates the parental delegation model else {Class c = findClass (name); if (resolve) {resolveClass (c);} return c } package cn.com.nightfield.jvm.classloader;import java.io.File;import java.net.MalformedURLException;import java.net.URL;public class ClassLoaderTest {public static void main (String [] args) throws ClassNotFoundException, IllegalAccessException, InstantiationException, MalformedURLException {/ / specify the loading path of the classloader URL url = new File ("/ Users/zhochi/demo/target/classes"). ToURI (). ToURL () ClassLoader customizedClassLoader = new CustomizedClassLoader (new URL [] {url}); / / load Plugin class Class clz = customizedClassLoader.loadClass ("cn.com.nightfield.jvm.classloader.Plugin") with a custom class loader; System.out.println (clz.getClassLoader ()); Object pluginInstance = clz.newInstance (); / / pluginInstance instanceof Plugin "output false System.out.println (" pluginInstance instanceof Plugin: "+ (pluginInstance instanceof Plugin)) / / report java.lang.ClassCastException error Plugin plugin = (Plugin) clz.newInstance ();}}

The console output is as follows:

Cn.com.nightfield.jvm.classloader.CustomizedClassLoader@60e53b93pluginInstance instanceof Plugin: falseException in thread "main" java.lang.ClassCastException: cn.com.nightfield.jvm.classloader.Plugin cannot be cast to cn.com.nightfield.jvm.classloader.Plugin at cn.com.nightfield.jvm.classloader.ClassLoaderTest.main (ClassLoaderTest.java:19)

To know the root cause of the error, you need to understand the premise that the object can be cast: the object must be an instance of the target class. As you can see from the above output, the result of instance instanceof Plugin is false. Why? Because for any class, it is necessary for its class loader and the class itself to jointly establish its uniqueness in JVM, that is to say, whether two classes in JVM are equal or not depends on whether they are loaded by the same class loader. If not, even if the two classes come from the same class file, they are not equal.

In the above example, the Plugin class is under class path and is loaded by AppClassloader by default, but pluginInstance is an instance of class loaded by CustomizedClassLoader. When JVM tries to convert CustomizedClassLoader.Plugin to AppClassloader.Plugin, it is bound to report an error.

Problem solving

In fact, the reason is that we violated the parent delegation model in the custom class loader CustomizedClassLoader. As we all know, there are three types of loaders in Java: BootstrapClassLoader,ExtClassLoader and AppClassLoader, which constitute a father-son relationship in combination, the former is the "father" of the latter, and has their own "territory": BootstrapClassLoader is responsible for loading Java core class libraries such as rt.jar,resource.jar;ExtClassLoader in JRE responsible for loading {java.home} / lib/ext and java.ext.dirs system directory under the class;AppClassLoader is to load the class path path, that is, we write the class file. The so-called parent delegation model means that when Classloader receives a request to load class, it will first delegate to its father to load, and if the father does not load successfully, he will try to load it. The mechanism of parental delegation is a major guarantee for the security of classes in JVM: even if someone maliciously customizes a String.class, the String is still loaded into the rt.jar by the class loader. The following is part of the source code of loadClass:

Public abstract class ClassLoader {protected Class loadClass (String name, boolean resolve) throws ClassNotFoundException {synchronized (getClassLoadingLock (name)) {/ / 1. If the class has already been loaded, directly return Class c = findLoadedClass (name); if (c = = null) {try {/ / 2. Delegate the parent class to load if (parent! = null) {c = parent.loadClass (name, false);} else {/ / in this case, delegate BootstrapClassLoader to load c = findBootstrapClassOrNull (name) } catch (ClassNotFoundException e) {/ / ClassNotFoundException thrown if class not found / / from the non-null parent class loader} if (c = = null) {/ / 3. Try loading c = findClass (name);}} if (resolve) {resolveClass (c);} return c;}}

However, the parent delegation model is not a mandatory constraint, but a pattern recommended by Java, so when customizing the classloader, we recommend overriding the findClass () method instead of the loadClass () method.

Going back to the original question, analyzing the source code of PF4J, you can guess that it also defines its own classloader PluginClassLoader, and it overrides the default implementation of the loadClass () method, which violates the parent delegation model in order to prevent class version problems.

The classloader in Java is equivalent to the namespace of the class it loads. The two classes are equal. First, make sure that they are loaded by the same classloader. When implementing a custom class loader, do not violate the parent delegation model unless you have a deep understanding of the class loading mechanism and know what you are doing.

This is the answer to the question about what to do with ClassCastException caused by custom Classloader. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.