ClassCastException深刻分析

ClassCastException是JVM在檢測到兩個類型間轉換不兼容時引起的運行時異常。此類錯誤一般會終止用戶請求。在執行任何子系統的應用程序代碼時都有可能發生ClassCastException異常。經過轉換，能夠指示Java編譯器將給定類型的變量做爲另外一種變量來處理。對基礎類型和用戶定義類型均可以轉換。Java語言規範定義了容許的轉換，其中大多數可在編譯時進行驗證。不過，某些轉換還須要運行時驗證。若是在此運行時驗證過程當中檢測到不兼容，JVM就會引起ClassCastException異常。例如：

Fruit f;

Apple a = (Apple)f;

當出現下列狀況時，就會引起ClassCastException異常：

1.        Fruit和Apple類不兼容。當應用程序代碼嘗試將某一對象轉換爲某一子類時，若是該對象並不是該子類的實例，JVM就會拋出ClassCastException異常。

2.        Fruit和Apple類兼容，但加載時使用了不一樣的ClassLoader。這是這種異常發生最多見的緣由。在這裏，須要瞭解一下什麼是ClassLoader？

ClassLoader

         ClassLoader是容許JVM查找和加載類的一種Java類。JVM有內置的ClassLoader。不過，應用程序能夠定義自定義的ClassLoader。應用程序定義新的ClassLoader一般出於如下兩種緣由：

1.        自定義和擴展JVM加載類的方式。例如，增長對新的類庫(網絡、加密文件等)的支持。

2.        劃分JVM名稱空間，避免名稱衝突。例如，能夠利用劃分技術同時運行同一應用程序的多個版本(基於空間的劃分)。此項技術在應用服務器(如WebLogic Server)內的另外一個重要用途是啓用應用程序熱從新部署，即在不從新啓動JVM的狀況下啓動應用程序的新版本(基於時間的劃分)。

ClassLoader按層級方式進行組織。除系統BootClassLoader外，其它ClassLoader都必須有父ClassLoader。

在理解類加載的時候，須要注意如下幾點：

1.        永遠沒法在同一ClassLoader中從新加載類。「熱從新部署」須要使用新的ClassLoader。每一個類對其ClassLoader的引用都是不可變的：this.getClass().getClassLoader()。

2.        在加載類以前，ClassLoader始終會先詢問其父ClassLoader(委託模型)。這意味着將永遠沒法重寫「核心」類。

3.        同級ClassLoader間互不瞭解。

4.        由不一樣ClassLoader加載的同一類文件也會被視爲不一樣的類，即使每一個字節都徹底相同。這是ClassCastException的一個典型緣由。

5.        可使用Thread.setContextClassLoader(a)將ClassLoader鏈接到線程的上下文。

基於以上的基本原理，能夠加深你們對ClassCastException的理解，和在碰到問題時提供一種解決問題的思路。

ClassCastException and ClassLoader Puzzle

2/21/2013   PIERRE-HUGUES CHARBONNEAU   2 COMMENTS

The following question and puzzle will test your knowledge on Java class loaders and more precisely on one of the Java language specifications. It will also help you better troubleshoot problems such asjava.lang.NoClassDefFoundError.

I highly suggest that you do not look at the explanation and solution until you review the code and come up with your own explanation.

You can download the Java program source code and binaries (compiled with JDK 1.7) here. In order to run the program, simply use the following command:

<JDK 1.7 HOME>\bin\java -classpath MainProgram.jar org.ph.javaee.training9.ChildFirstCLPuzzle

** Make sure that you also download the 3 JAR files below before you run the program.

• MainProgram.jar contains the main program along with super classProgrammingLanguage.
• ProgrammingLanguage.jar contains the super class ProgrammingLanguage.
• JavaLanguage.jar contains the implementation class JavaLanguage, which extendsProgrammingLanguage.

Question (puzzle)

Review closely the program source and packaging along with the diagram below reflecting the class loader delegation model used for this program.

Why can’t we cast (ChildFirstCLPuzzle.java @line 53) the Object javaLanguageInstance of type JavaLanguage , into  ProgrammingLanguage ?

...............................                   

// Finally, cast the object instance into ProgrammingLanguage

/** Question: why is the following code failing with ClassCastException given the fact JavaLanguage is indeed a ProgrammingLanguage?? **/

ProgrammingLanguage programmingLanguage = (ProgrammingLanguage)javaLanguageInstance;

............................... 

Propose a solution to allow the above cast to succeed without changing the original source code. Hint: look again at the class loader delegation model, packaging and diagram.

Answer & solution

The Java program is attempting to demonstrate a Java language specification rule related to class loaders: two classes loaded by different class loaders are considered to be distinct and hence incompatible.

If you review closely the program source, packaging and diagram, you will realize the following facts:

• Our main program is loaded to the parent class loader e.g. $AppClassLoader.
• The super class ProgrammingLanguage is also loaded to the parent class loader since it is referenced by our main program at line 53.
• The implementation class JavaLanguage is loaded to our child class loader e.g. ChildFirstClassLoader which is following a 「child first」 delegation model.
• Finally, the super class ProgrammingLanguage is also loaded to our child class loader.

The key point to understand is that the super class is loaded by 2 different class loaders. As per Java language specification, two classes loaded by different class loaders are considered to bedistinct and hence incompatible. This means that ProgrammingLanguage loaded from the 「child firs」 class loader is different and not compatible with ProgrammingLanguage loaded from the parent classloader. This is why the cast attempted at line 53 failed with the error below:

ChildFirstCLPuzzle execution failed with ERROR: java.lang.ClassCastException: org.ph.javaee.training9.JavaLanguage cannot be cast to org.ph.javaee.training9.ProgrammingLanguage

Now how can we fix this problem without actually changing the source code? Well please keep in mind that we are using a 「child first」 delegation model here. This is why we end up with 2 versions of the same ProgrammingLanguage class. The solution can be visualized as per below.

In order to fix this problem, we can simply ensure that we have only one version of ProgrammingLanguage loaded. Since our main program is referencing ProgrammingLanguage directly, the solution is to remove the ProgrammingLanguage.jar file from the child class loader. This will force the child class loader to look for the class from the  parent  class loader, problem solved! In order to test the solution, simply remove the ProgrammingLanguage.jar from your testing folder and re-run the program.

I hope you appreciated this puzzle related to 「child first」 class loader delegation model and class loader rules. This understanding is especially important when you are dealing with complex Java EE deployments involving many class loaders, exposing you to this type of problems at runtime.

Please do not hesitate to post any comment or question on this puzzle.