Sun-Java(JRE/JDK)のバージョンが上がりました。

Sunは買収されたので、Oracleというべきかもしれませんが、
Gentooでのパッケージ名は sun-jre-bin,sun-jdk と sunの名がついたままです。

ライセンスが変更されたため、/etc/make.conf の
ACCEPT_LICENSE= に Oracle-BCLA-JavaSE を追記します。

私の場合は
ACCEPT_LICENSE="dlj-1.1 sun-bcla-java-vm AdobeFlash-10.1 PUEL"
となっていたのを
ACCEPT_LICENSE="dlj-1.1 Oracle-BCLA-JavaSE AdobeFlash-10.1 PUEL"
に変更しました。

それだけでなく、

[ebuild    FU  ] dev-java/sun-jre-bin-1.6.0.29 [1.6.0.26]
[ebuild    FU  ] dev-java/sun-jdk-1.6.0.29 [1.6.0.26]

と、F(fetch)が出るので、手動でダウンロードしなければなりません。

ブラウザでhttp://www.oracle.com/technetwork/java/javase/downloads/index.html
から、Java SE 6 Update 29 の、JRE/JDK　[Download]をクリック
x86(32bit)の場合は、jdk-6u29-linux-i586.bin, jre-6u29-linux-i586.bin
amd64(64bit)の場合は、jdk-6u29-linux-x64.bin, jre-6u29-linux-x64.bin
をダウンロードして
/usr/portage/distfiles/
に格納します。

ダウロードの際には、Oracle Binary Code License Agreement for Java SE を読んで
● Accept License Agreement にチェックを入れる必要があります。

/usr/portage/distfiles/ に入っている（fetch済み)と

[ebuild    fU  ] dev-java/sun-jre-bin-1.6.0.29 [1.6.0.26]
[ebuild    fU  ] dev-java/sun-jdk-1.6.0.29 [1.6.0.26]

になりますから、あとは普通に# emerge できます。

何気なく、窓の杜(http://www.forest.impress.co.jp/)を眺めていたところ

全17件の脆弱性を修正したランタイム「Java Runtime Environment」v6 Update 26
“CVSS”による深刻度が最高の“10.0”と評価された脆弱性9件を含む
http://www.forest.impress.co.jp/docs/news/20110608_451479.html

という記事がありました。

おっと、これは危ないのかも、と
# emerge -pv sun-jre-bin
で見てみると、amd64 では
[ebuild R ] dev-java/sun-jre-bin-1.6.0.24
と、ちと古い。
sun-jre-bin-1.6.0.26.ebuild はあるのですが、~amd64 x86 となっていました。
（x86 では、普通に emerge -u world していれば 26 になっているハズ）

取り急ぎ、/etc/portage/package.keywords に
=dev-java/sun-jre-bin-1.6.0.26 ~amd64
を追記して
# emerge -u world

実行後、やれやれと記事をよく見ると 脆弱性は Microsoft Windows だけみたいです。
ありゃ？と、
http://www.ipa.go.jp/about/press/20110610.html
を見ると

「Java Web Start」における3件のセキュリティ上の弱点（脆弱性）の注意喚起

てなタイトルで、Java Web Start つーのは、Windows にしか無さそう。
という事は、アセってやらなくてもよかった様です。

まぁいいか、と、sun-jre-bin-1.6.0.26 のまま Eclipse を動かしてみると
なにやら、ソースがまっ赤赤。
プロジェクトから、JREが消えてしまっていました。
sun-jre-bin-1.6.0.24
に戻して、Eclipseを再起動しても状況変わらず。これには参りました。
sun-JREのpathが失われた様です。。。対策模索中。

なんとか復帰しました。
↓ 【続きを読む】

JavaでGUIプログラミングをする際に、使用するクラスライブラリは
独断で大別すると、AWT と Swing の２つがあります。

Swing は、たいてい J で始まります。
Frame, Label ... AWT
JFrame,JLabel .. Swing
という感じ。

私の理解では、
AWT は、OS に近いもので、見栄えは OS によって異なったりします。
Swing は、Java自身でOS差を吸収するような処理をしていて、
見栄えは上品（？）です。そのぶん、少々重い（遅い）かもしれません。

で、私は AWT 派 なのですが、ちょっと気づいたことがあり
Label と JLabel の差を確認中です。

現時点で、試したのは、Gentoo-Linux と、MAC OS X の２つ
だけです。（他のOS(Windows/Ubuntu等)ではどうなるかは
未確認なので「確認中」と表記しています）

Gentoo では、
Label ... でかい文字はギザギザが目立ち美しくない
JLabel .. アンチエリアスがかかる様ででかい文字も美しい
※ でかい文字とは、new Font("Monospaced",Font.PLAIN,38);等です。

MAC OS X では、AWT(Label) でもでか文字にアンチエリアスが
効いて美しい。ただし
Label ... 文字が縦(Y)方向で上寄せになる
（Gentoo では、縦(Y)方向は中央になります）

JLabel .. 縦(Y)方向は中央になる

AWT と Swing の混在は可能なので、Fameの中にJLabelを
突っ込んでも大丈夫みたいです。

速度の懸念はありますが、Label は使わずに JLabel にした方が
よさそうな感じです。

ちなみに、JLabel の場合は、横(X)方向の中央寄せは
jlabel.setHorizontalAlignment(JLabel.CENTER);
です。
（Label の場合は
label.setAlignment(Label.CENTER);
です）

あるプログラムの一部の処理で、ファイルダンプの様な事をやろうとしました。
ファイルの一部を１６進数で表示したかった訳です。

例えば

  90:74 6c 61 62 2f 54 69 6d 65 52 65 63 24 37 2e 63   tlab/TimeRec$7.c
  A0:6c 61 73 73 50 4b 01 02 14 00 14 00 08 00 08 00   lassPK..........
  B0:a8 82 3c 3d 40 e9 fa e5 48 0d 00 00 db 17 00 00   ..<=@...H.......

という感じの表示。

ファイルは、
ra=new RandomAccessFile(filename, "r");
で、openして

byte buf[]=new byte[BUFFSIZE];
なるバッファに
ra.seek(offset);
ra.read(buf, 0, BUFFSIZE);
で読み込む。

あとは

	int k=0;
	while(k<BUFSIZE) {
		System.out.printf("%4X:", k+offset);
		for (int i=0; i<16;++i) {
			c=buf[k];
			System.out.printf("%02x ", c);
			if ((c>=' ')&&(c<='z'))  b[i]=c;
			else b[i]='.';
			++k;
			if (k>BUFFSIZE) break;
		}
		System.out.println(); // b[]を文字列にするには？？
	}

と、ここまで組んで
ふと、b[]に入れたバイト列を文字列にする方法に悩みました。

b.toString() としたら、何やら変な文字列になる。

分かってしまえば、「なーんだ」なのですが
正解は

System.out.println("  "+new String(b)); // new String(バイト列)で文字列になる！

でした。

JavaのGUIプログラミングには AWT と Swing を使う方法があります。
（SWTなどもありますが）

見栄えは Swingを使った方が格好良いものができるのですが
なぜか（慣れの問題でしょう） AWT ばかり使っています。

GUIで、文字や数値入力するのに、TextField を使います。
（Swing だと JTextField）

このTextFiledは、入出力文字列が「左詰め」になり
フォントによっては、左端の枠と接して見づらい気がします。

Swingの JTextFiledでは

setHorizontalAlignment(JTextField.CENTER);

とすることで、中央寄せにできるのですが
（参考 ActionListener付きTextFieldクラス　[2009.06.11]）
AWT では指定できない様です。

そこで、擬似的な中央寄せ／右詰めにする TextField のクラスを作ってみました。
以前作った空白（スペース）を左に付加（パディング）して、位置を調整する手法です。

下記のサンプルコードでは、コンストラクタで横幅(ww)をセットして
右詰め(setNum)の時はその値を使っています。

中央寄せ(setNumc)の時は、幅を指定するようにしてみました。
（好きな様に変更してください。）
フォントは、Monospaced にしておいた方が良いでしょう。

では、ソースコードです。 【続きを読む】