« WatchServiceが正しいPathを返してくれない | トップページ | いんきゅばすver2 コンセプト »

2011/09/03

NetBeansから実行するとNimbusのJTable中に表示させたJProgressBarに文字列が表示されない

そもそもコンポーネントのサイズが何やら大きいぞ?と使いはじめから思っていたのですが、そのときはNimbusってそんなものなのかな…と考えていました。表題の件もJavadocを見ると

進捗文字列をサポートしない、または進捗バーが不確定モードのときだけサポートする Look & Feel もあります。

なんてことが書いてあったので、仕様なのかも、と考えていました。

 

が、コマンドプロンプトから起動してみたところ、大きさもネイティブのLAFと同じだし、プログレスバーに文字もちゃんと表示されていました。なんでだろ?とNetBeansが使用しているAntのbuild.xmlでrunの部分を見てみたところ、-Dfile.encoding=UTF-8が設定されており、もしやこれが?とおもって検索してみたところ、やはりそうでした。

file.encoding設定値がフォント構成ファイルの情報読み込みに影響を与えるようです。

NetBeans7.0.1とEclipse3.8m1で試してみましたが、ファイルの文字コードをUTF-8に設定すると、双方のIDEで実行時にfile.encodingもUTF-8に設定されてしまうようです。

ユーザ(私)がUTF-8を設定したのはコンパイル前のjavaソースをUTF-8で書きたいからであって、実行時にどうこうしたいからじゃないんですけど、なんで両方のIDEともこんな仕様になってるんでしょうかね。あとfile.encodingって結局何がしたいための定義なのかもよく理解できません(昔からのバグが多く残っているようですし)…

« WatchServiceが正しいPathを返してくれない | トップページ | いんきゅばすver2 コンセプト »

コメント

Eclipse もそのような動きだったのですね。

ソースが UTF-8 の場合、実行時の file.encoding も UTF-8 にしたほうがいいというのは
おそらくこのコメントが理由になっていると思います。

http://netbeans.org/bugzilla/show_bug.cgi?id=166597#c11

これは以前私もそのことに疑問を持ち開発者にコメントしたその回答です。
ソースをUTF-8にしたのだから出力で使うエンコーディングもUTF-8 でなければ
不便でしょ?ということだと思います。たしかに彼らの言ってることはわかるのですが
それがデフォルトの動作ではなくオプションで切り替えられるような作りにしてほしいですよね。

実運用で使う場合はエンコーディングを自分で決められるので問題ありませんが、
IDE から起動したときに見た目が変わってしまうというのはこまりますよね。
JDKはたしかに以前は fontconfig.properties が UTF-8 用には対応しきれていなくて
中国語のフォントが使われていました。これは以下の改善要求として登録し、たしか
JDK6u18 で修正が入ってきました。NetBeans のメーリングリストでのスレッドです。

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6856390
http://netbeans-org.1045718.n5.nabble.com/NetBeans-td3015869.html

Nimbusで使った場合にまだ問題があるということですね?少し調べてみて必要で
あれば担当のものに相談したいと思います。もし差し支えなければ問題の発生する
サンプルコードなど必要な部分のみでかまいませんので提供していただくことは
可能でしょうか。

よろしくお願いいたします。

片貝さん、こんばんは。コメントありがとうございます。

ソースコードをUTF-8で書いているのに標準出力をMS932にしてしまうと、UTF-8 -> MS932マッピング不能な文字が存在する(NetBeans上のエディタ表示とNetBeans上の出力ウィンドウ表示が不一致になる状況が出来る)ので問題がある、なのでNetBeansの"エンコーディング"設定はjavacコマンドの-encodingオプションとjavaコマンドの-Dfile.encodingオプションの値を決める設定となっている、というような理解でよいでしょうか。

…ところで、file.encodingの意味について、本エントリを記載した時点では知りませんでした…
その後調べた結果、Perl
http://osksn2.hep.sci.osaka-u.ac.jp/~taku/osx/perl/perl_utf.html
で言うところのbinmodeとopen(のデフォルト)の文字コードを一括で指定するもの、という理解に至ったのですが、この理解で正しいのでしょうか。
(公式ドキュメントでfile.encodingについて説明しているものを探したのですが見つけられませんでした…もしご存知でしたら教えていただけないでしょうか。)

そうすると、NetBeansから実行した場合とコマンドプロンプトから実行した場合とでFileReader等の挙動が変わるよな、と検索してみたところ
http://netbeans-org.1045718.n5.nabble.com/-td3015288.html (NetBeans)
http://www.javaroad.jp/bbs/answer.jsp?q_id=20101019003659363 (Eclipse)
とやはりハマっている方がいらっしゃるようですね。なるほど、片貝さんが
http://netbeans.org/bugzilla/show_bug.cgi?id=166597#c10
でおっしゃっている内容はこういうことですね。

====

私がNetBeans上で実行した場合(つまり、-Dfile.encoding=UTF-8を指定した場合)とコマンドプロンプトで実行した場合(-Dfile.encoding無しで実行した場合)で挙動が変わっている、と本エントリで述べた事項の再現コードは以下になります。
http://feather.cocolog-nifty.com/weblog/images/nimbus/HelloEncoding.zip
( http://terai.xrea.jp/Swing/TableCellProgressBar.html のコードを拝借しております)

実行した環境は
Windows7(64bit) / Java1.7.0(64bit) 及び Java1.6.24(64bit) / NetBeans7.0.1
です。

同じJFrame継承クラスの2インスタンスをそれぞれSystem LAFとNimbus LAFで表示させるプログラムですが、
NetBeans上で実行する(-Dfile.encoding=UTF-8付きで実行する)と以下のようになります。
http://feather.cocolog-nifty.com/weblog/images/nimbus/compare_laf.png
System LAFのウィンドウでは、JProgressBarの中に文字列が表示されますが、Nimbus LAFのウィンドウでは表示されません。

しかし、同じプログラムをコマンドプロンプトで実行する(-Dfile.encoding無しで実行する)と文字列が表示されます(下図の左)。
http://feather.cocolog-nifty.com/weblog/images/nimbus/compare_encoding.png

また、上図の左右を見比べて頂けると分かると思いますが、JTableのヘッダ、ボタンの大きさが変わっています。

> その後調べた結果、Perl
> http://osksn2.hep.sci.osaka-u.ac.jp/~taku/osx/perl/perl_utf.html
> で言うところのbinmodeとopen(のデフォルト)の文字コードを一括で指定するもの、という理解に至ったのですが、この理解で正しいのでしょうか。

あ、この理解だと、今回の本題「フォント構成ファイル」の話が含まれませんね。
やっぱり理解が不足しているようです…

file.encodingについてはBug Databaseに

Bug ID: 4829797 (spec) Document System property "file.encoding"
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4829797

として挙がっていますね。

公式ドキュメントは存在しない、ということなんでしょうね。

コメントを書く

(ウェブ上には掲載しません)

トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/18902/52638018

この記事へのトラックバック一覧です: NetBeansから実行するとNimbusのJTable中に表示させたJProgressBarに文字列が表示されない:

« WatchServiceが正しいPathを返してくれない | トップページ | いんきゅばすver2 コンセプト »

other sites

  • follow us in feedly
  • github
  • stackoverflow

ソフトウェアエンジニアとして影響を受けた書籍

  • Christain Bauer: HIBERNATE イン アクション

    Christain Bauer: HIBERNATE イン アクション
    理論と実践が双方とも素晴らしい製品であるHibernate。本書はそのプロダクトを書名に冠していますが、Hibernateを使うつもりがなく、ORマッピングの解説書として読むにしても十分な良書です。Second EditionとしてJava Persistence With Hibernateという書籍も出版されていますが、残念ながら現在のところ 和訳はされていません。-インアクションは2.xの、Java Persistence-は3.1の頃のものなので、最新版とはちょっと違うところもあることに注意。 (★★★★★)

  • アンドリュー・S・タネンバウム: 分散システム 原理とパラダイム 第2版

    アンドリュー・S・タネンバウム: 分散システム 原理とパラダイム 第2版
    クライアント/サーバシステムを構築する上で必要となる知識が総論されてます。Web技術者も、フレームワーク部分を開発するのであれば必読。 (★★★★★)

  • Joel Spolsky∥著: ジョエル・オン・ソフトウェア

    Joel Spolsky∥著: ジョエル・オン・ソフトウェア
    前述の書籍「ソフトウエア開発プロフェッショナル」をより砕いたもの、という感じでしょうか。 前書きではプログラマでなくSE向けの本のように書かれているが、プログラマが読んでも面白い本であると思われます。 SEになった新人(あるいはそういう会社に入る/入りたての人)にとっては、これからどういったことが仕事を遂行していく上で起こりえるのか、どのように考えて行なっていけばいいのか決定する助けになると思います。 元は″Joel on Software″というブログの記事で、web上でも一部日本語で読めます。 http://japanese.joelonsoftware.com/ (★★★)

  • ドナルド・C・ゴース,ジェラルド・M・ワインバーグ: ライト、ついてますか

    ドナルド・C・ゴース,ジェラルド・M・ワインバーグ: ライト、ついてますか
    問題解決(一昔前のの流行語で言うところの『ソリューション』)能力は、システムエンジニアのスキルとして備えるべきもののうちのひとつです。しかし、これは難しい。学校で出されるテストと違い、唯一の、(問題提出者が想定している)解を求めるだけが「問題解決」では無いからです。そもそも、何が問題なのか、それは本当に問題なのか、それは本当に解決すべき問題なのか、その問題解決方法は正しいのか、などを解決しなければ、「その解は正しいのか」に辿りつくことができません。この本の最も良いところのひとつは、本があまり厚くないこと。すぐに読めるし、何回も読み返す気になるでしょう。 (★★★★★)

  • スティーブ・マコネル: ソフトウエア開発プロフェッショナル

    スティーブ・マコネル: ソフトウエア開発プロフェッショナル
    コードコンプリートで有名なスティーブマコネルの著書。新人SEに読んで欲しい。個人として業界の中でどうあるべきか、組織としてどうあるべきか、SEのプロ意識とは?SEの心構え概論、といったところでしょうか。また、業界における資格の重要性についても説かれています。この業界では資格が特に軽んじられる傾向がありますが、この傾向はどんな弊害をもたらすのか、将来的にこの業界は資格に対してどのような姿勢で臨んでいくべきなのか。日経BP社では(他の出版社もだが)最近、似たような類いのあまり面白くない書籍が乱出版されていますが、この本は別格だと思うので安心して購入して欲しいと思います。 (★★★★★)

無料ブログはココログ