The Backyard - ClassLoader Diff
- Added parts are displayed like this.
- Deleted parts are displayed
like this.
クラスをロードするクラス。
自己言及的かな?
なぜなら、これこそ本質的なクラスの中のクラスだからだ。
Javaでは、複数のクラスローダが存在する場合がある。
たとえば、Tomcat。
全体のクラスローダと、シェアクラスローダ、そして、WEB-INFの下のコンテキスト固有のクラスローダ。
重要な点は、同一クラスであっても、異なるクラスローダによってロードされると異なるクラスのインスタンス(instance of Class classであって、instance of a classではない。って英語はあってるかなぁ)となることだ。そのため、思いもかけないところで、ClassCastExceptionになったりする。たとえば、クロスコンテキストを利用して取得したServletContextから取得したあるクラスのインスタンスを、単純にあるクラスでキャストすると、その時点で、あるクラスをあるクラスでキャストしたClassCastExceptionになったりする。エラーメッセージを見てもトートロジーなのでさっぱり理解できないことになる。そういう場合は、インスタンス化した元のクラスをロードしたクラスローダが異なっているのが原因だ。
.NETでは、より洗練させて(少なくても僕はそう思う)AppDomainという概念として提供している。したがって、異なるAppDomainだから当然リモート呼び出しになってマーシャル/デマーシャルが必要だというように可視されているため、上のようなわかりにくさは無い、と思う。
自己言及的かな?
なぜなら、これこそ本質的なクラスの中のクラスだからだ。
Javaでは、複数のクラスローダが存在する場合がある。
たとえば、Tomcat。
全体のクラスローダと、シェアクラスローダ、そして、WEB-INFの下のコンテキスト固有のクラスローダ。
重要な点は、同一クラスであっても、異なるクラスローダによってロードされると異なるクラスのインスタンス(instance of Class classであって、instance of a classではない。って英語はあってるかなぁ)となることだ。そのため、思いもかけないところで、ClassCastExceptionになったりする。たとえば、クロスコンテキストを利用して取得したServletContextから取得したあるクラスのインスタンスを、単純にあるクラスでキャストすると、その時点で、あるクラスをあるクラスでキャストしたClassCastExceptionになったりする。エラーメッセージを見てもトートロジーなのでさっぱり理解できないことになる。そういう場合は、インスタンス化した元のクラスをロードしたクラスローダが異なっているのが原因だ。
.NETでは、より洗練させて(少なくても僕はそう思う)AppDomainという概念として提供している。したがって、異なるAppDomainだから当然リモート呼び出しになってマーシャル/デマーシャルが必要だというように可視されているため、上のようなわかりにくさは無い、と思う。