「Javaのプログラムはどうやって動いているの?」古いパズルを試した。
【初学者向け】JJUG ナイトセミナ 「Javaのプログラムはどうやって動いているの?」
https://www.youtube.com/watch?t=23&v=QNJBcrSayME
これを見てずっと前にさっぱり理解できなかったパズルがあって今なら少しだけなら解るような気がするかもしれないと思い試してみた。
元ネタは JAVA PUZZLERS の優れたパズラー パズル４４：授業をサボる(Cutting Class)です。
このパズルを元に試してみたのですが時既に遅し・・・
Java SE 8 では既にパズルにはならなくなっていました。（Java SE 6 から）
なので、J2SE5.0 を使うことにしました。（ヲヒ
今回このパズルを試すのに組んだコードはこれです。
Love クラスはコンパイル時には存在していてちゃんとコンパイルされるものとします。
ただし、このプログラムの実行時には Love クラスは消えていることとします。
さて、どういった実行結果になるか想像できますか？
Lost Love が表示されるように思われますが残念な結果になります。
衝撃の事実をご覧ください。
なんでこうなるの？
バイトコードを覗いてみます。
バイトコードの怪しそうなところを見ていきましょう。
11: astore_1 とmain()メソッドのコードにあるのが問題の原因です。
これは catch ブロックでキャッチされたキャッチパラメータ e を VM 変数 1 に保存しています。
既に 7: astore_1 と Love クラスのローカル変数 love が VM 変数１に保存されています。
VM 変数１に上述の二つがマッピングされています。
このプログラムを実行すると JVM が起動、そしてクラスのロード、リンク、初期化、main 実行となります。
このプログラムはリンクのベリフィケーションで例外が発生してしまっています。
VM 変数１にマッピングされている二つのクラスをベリファイアはマージしようとする時にベリファイアは Love クラスのスーパークラスを決定するために Love クラスをロードしようとします。
しかし、 Love クラスは消えているのでロードに失敗してしまって NoClassDefFoundError がスローされます。
悲しいことにこの例外はベリフィケーション中にスローされていますのでクラスの初期化される前、main実行開始前ということでこのような残念なことになってしまいます。
本当に VM 変数１へのマッピングだけが問題かどうか確かめてみます。
プログラムを次のように変更します。
Love クラスのローカル変数の宣言を try – catch ブロックの外に出します。
プログラムを実行させて確認します。
期待通りの動作となって Lost Love と出力されています。
キャッチパラメータ e も VM 変数 2 にマッピングされています。
11: astore_2
これでリンクのベリフィケーションも解決されて初期化、main実行で catch ブロックが実行されました。
このエントリーの冒頭にも記述しましたが現在の Java ではこのような問題は発生しません。
おそらくリンクの処理が賢くなってしまったんでしょう。
ついでだからプログラムのコードを戻して Java SE 6 で確認しておきます。
問題ないですね。
VM 変数１に Love クラスのローカル変数 love と catch ブロックでキャッチされたキャッチパラメータ e がマッピングされてもちゃんとベリフィケーションされるようになったようです。
JVM のことは詳しく解らないので間違っているかもしれませんがこうやってバイトコードを覗いてみるのもおもしろいですね。
例外テーブルの動作も表示されているし、BASIC のような goto 文まで。
詳しくは元ネタの本を読んでください。(^_^;)
今日の教訓：「Love が消えてしまうと悲しい！」
違う！
今日の教訓：「古い Java より新しい Java で幸せに！」
TAGS: Java | 2015年5月1日5:41 AM
Trackback URL