現代のクラシック音楽

似非「現代のベートーベン」佐村河内の事件が話題になっている。NHKなどテレビで特集され、CDを買った人が10万人以上いるとのこと。自分はもっぱらNHK FMを聞いているので、聞いたことはないのだが、これはたまたまで、NHK FMで流れていれば聞いていた可能性もある。佐村河内のやったことは卑劣な詐欺行為であることは間違いない。しかし、いわゆる現代音楽と言われているものの現状があまりに聴衆からかけ離れてしまっていることは問題だろう。最近NHK FMで池辺晋一郎の作品が放送されていて聞いてみたのだが、あまりの退屈さに長くは聞いていられなかった。交響曲9番というから、作曲家人生の集大成的な意味があると思われるのだが、クラシック音楽がちょっと好き程度の一般人にとっては、好き好んで何度も聞くものではないだろう。クラシック音楽も何度か聞いてなじむと好きになることがあるが、池辺氏の曲には大多数の人が二度目はないだろう。聴衆から離れた現代音楽は死に絶える運命ということだろうか。

paintComponentsに注意

間が空いてしまった。その間はJavaScriptの勉強などをしていた。
結構面白いが、注意すべき点がいくつかある。何らかのまとめは後日。

今日はJavaではまった話。人のSwingプログラムのコードで表示が変になるものがあり、結構長い時間分からなかった。

public void paintComponent(Graphics g) {

     super.paintComponents(g);

となっていたのだ。正しくは

     super.paintComponent(g);

でなければならない。
で、これがコンパイル時も実行時もエラーにはならない。
protected void paintComponent(Graphics g) は javax.swing.JComponent のメソッドだが、
public void paintComponents(Graphics g) は java.awt.Container のメソッドになる。
JComponent は Container を継承しているため、paintComponents も使えるわけである。

LinuxのJava SE 5 (1.5.0_09) で背景色が出ない (3)

「LinuxのJava SE 5 (1.5.0_09) で背景色が出ない」と
「LinuxのJava SE 5 (1.5.0_09) で背景色が出ない (2)」の件。
結局、GTKLookAndFeel では JPanel のデフォルトが opaque が false に
なっているためのよう。
どうもすべてのプラットフォームで共通なデフォルト値はないらしい。
以下の方法のどれかで明示的に opaque を true にすればよい。

(A) メソッド isOpaque() をオーバーライド
JPanelを拡張したクラスで

    public boolean isOpaque() { return true; }

のようにメソッド isOpaque() をオーバーライドする。

(B) インスタンスを生成後、

    インスタンス.setOpaque(true);

のようにして設定する。

(C) 拡張クラスのコンストラクタで setOpaque(true) を呼ぶ。

LinuxのJava SE 5 (1.5.0_09) で背景色が出ない (2)

「LinuxのJava SE 5 (1.5.0_09) で背景色が出ない」に書いた件だが、
試したところ、Javaの標準のLook & Feelでは正常に背景色が出るようだ。
GNOME用の GTKLookAndFeel に設定すると背景色が出なくなる。
GTKLookAndFeel のバグなのか、そういう仕様なのか。
なお、Java SE 5 のバージョンを 1.5.0_10 に上げても状況は変わらない。

LinuxのJava SE 5 (1.5.0_09) で背景色が出ない

Linux (Fedora Core 6) に Sun Java SE 5 (1.5.0_09) を入れ、
GNOME上でSwingアプリケーションを動作させたところ、
JPanel拡張の独自パネルで setBackground で指定した
背景色が出ない。paintComponent をオーバーライドしているのだが、
ちゃんと super.paintComponent を呼び出しており、
Windows環境では背景色が出ている。
原因は不明。

Linux Java 1.5.0_08 Tomcat 5.5.17 でJSTL XMLタグでエラー

新しいLinuxマシンに Java SE 1.5.0_08 と Tomcat 5.5.17 を入れ、
Webアプリケーションの動作テストをしたところ、JSTLのXMLタグでエラーが出る。
JSTL の XML 処理のために追加ライブラリが何か必要なのだろうか?
詳細は調べる時間がなかったため不明。
(ちなみに Tomcat 5.5 系ではデータベース等の Rsource の書き方が
変わったが、それは変更し、データベース関係は動作した。)

今回は、Java 1.4.2_12、Tomcat 5.0.28 という従来の環境をインストールし
動作させた。この環境ではJSTLのXMLタグも全く問題なく動作する。

JDK 5.0 Update 8 (続: 日本語J2SE 5.0のダウンロードサイト)

日本語J2SE 5.0のダウンロードサイトがアクセスするパソコンによってはブランクページしか表示されないと書いたが、
     JDK 5.0 Update 8
がリリースされ、その不具合もなくなった模様。

日本語J2SE 5.0のダウンロードサイト

日本語 J2SE 5.0 のダウンロードサイト
だが、ここ一ヶ月くらいアクセスするパソコンによってはブランクページしか表示されない。
ブラウザ等の設定によるものか、原因は不明。

難読化ツールProGuardを試す

Javaプログラムのサイズ縮小・最適化・難読化機能のあるProGuardを試してみた。
確かに、逆コンパイルしてもかなり読みにくい様になる。
まあ、少し読みにくいだけで、機械語のアセンブリコードを読むよりはずっと
わかりやすいだろうが...

オプションとして以下のようなものを使う。
     -injars で入力jarファイル
     -outjars で出力jarファイル
     -libraryjars でJava SDKのjarファイル(インストール先の jre/lib/rt.jar)
     -keep でメインクラスとmainメソッドを指定

     -defaultpackage でパッケージの区別もなくしてくれる。

出力ファイルのサイズも縮小される。
試した簡単なGUIアプリケーションでは、元のjarファイル30KBに対して
適用後のファイルサイズは10KBになった。

Javaの逆コンパイラの威力を実感

Javaの逆コンパイラのJadを試してみた。バージョンは v1.5.8g のWindows版。
jarファイルは直接逆コンパイルできないが、展開すればディレクトリ以下をごっそり逆コンパイルできる。
出力されるコードも元のものが分かるくらい近いもののようだ。

簡単なGUIプログラムをJ2SE 1.5.0_07 でコンパイルした後、
Jadで逆コンパイルし、さらにそれをコンパイルしてみた。
問題点は1個だけだった。
内部クラスのコンストラクタで親クラスthisのメンバの設定が入っていて(これは本来は暗黙に含まれるべきもの)、その後 super()が呼ばれており、
super()は最初になければならないというエラーが出た。
親クラスthisのメンバの設定を削除したら問題なくコンパイル・実行できた。

こうも簡単に逆コンパイルできてしまうとは...
かなり衝撃的だ。

Jad は C++ で記述されているとのことだが、逆コンパイラには他にJODEというJavaで書かれたものもあるらしい。