トップページ⇒tech
1001コメント326KB

Java標準低速GUI 6 AWT/Swing

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2007/09/26(水) 20:51:18
ハードウェアの高スペック化、描画アルゴリズムの変更、JavaVMの高速化に伴い、パフォーマンスの問題は改善されています。
しかしながら、"Java"というだけで未だに敬遠されるのが現状。
そんなSwingと引き続き付き合っていくみんなのスレッドです。
Java低速GUI Swing 5 （前スレ）
http://pc11.2ch.net/test/read.cgi/tech/1161139809/
Java低速GUI Swing 4
http://pc8.2ch.net/test/read.cgi/tech/1140533866/
Java低速GUI Swing 3
http://pc8.2ch.net/test/read.cgi/tech/1121700954/
Java低速GUI Swing 2
http://pc8.2ch.net/test/read.cgi/tech/1095398949/
Java低速GUI Swing
http://pc5.2ch.net/test/read.cgi/tech/1062271447/l50
0074デフォルトの名無しさん2007/10/05(金) 18:11:45
>>73
そんないかれた仕様にするならどちらかをモディファイアキー有りにするかポップアップメニューにしてくれ…
# シングルクリック時にタイマーを設定してダブルクリック時にタイマーをキャンセルとかすればできなくはないか…
0075デフォルトの名無しさん2007/10/05(金) 18:14:16
>>73
ダブルクリック1回のつもりが失敗してシングルクリック2回になってしまうことはよくある。
その逆もよくある。
そういうゲームならともかく、ミスったら終わりみたいなユーザインタフェイスはやめた方がいいと思う。
0076デフォルトの名無しさん2007/10/05(金) 18:33:36
UI設計論の話してんじゃないから、文意をくみ取ってちょ。

>>74
まあタイマー使うことになるよね。

>>75
ワンクリでアイテム選択、ダブクリでアイテムプロパティ設定とか、よくあるでしょ。
MSのパワポとか。
0077デフォルトの名無しさん2007/10/05(金) 18:34:12
>>71
こんなのは？ シングルクリックの動作が遅れるのは
原理的にダブルクリックとの判別にそれだけ時間をかけないといけないからなので仕方がない
四角の描画は別スレッドなのでシングルスレッドルールに反してはいけないときはEDTに描画を投げるようにして
まあ基本的にこういうふうにクリック回数で処理を分けるUIはよくないと思うが
private final int mci = ((Integer)Toolkit.getDefaultToolkit().getDesktopProperty("awt.multiClickInterval")).intValue();
private boolean flag;
public void mouseClicked(MouseEvent evt) {
int count = evt.getClickCount();
if(count == 1) {
new Thread(new Runnable() {
public void run() {
flag = true;
try { Thread.sleep(mci); } catch (InterruptedException e) {}
if (flag) {
//四角を描画
}
}
}).start();
} else if(count == 2) {
flag = false;
//三角を描画
}
}
0078デフォルトの名無しさん2007/10/05(金) 18:50:12
前々から思ってたんだけど

AWTは知らないけど、少なくともSwingのコンポーネントの多くはそのコンストラクタで
オーバライド可能なメソッドを呼び出したり、
そのインナークラスをイベントリスナーとして登録してるんだけど、
どう考えればいいのかな。

コンストラクタが終了する前に this を漏洩することは、
オブジェクトが整合性を整える前にメソッドが呼び出される可能性がある。
とりあえず、基本EDT限定なので、まあ、別スレッドから呼び出される心配はないかもしれないが、
それを差し引いても、例えばリスナー登録の瞬間にコールバックされたりなど
シングルスレッドでも、コンストラクタ完了前に呼び出される危険がある。

とりあえず、今考えているのは、Swingを使う場合は
自前コンポーネントでthisを漏洩しないよう（ファクトリメソッドを作るとか）複雑にしても、
既に親クラスが漏洩しているので、複雑にした分だけ損。それなら、毒を食らわば皿までということで、

１．コンストラクタでイベントハンドラの登録やオーバライド可能なメソッドの呼び出しはOKとする
２．イベントの仕組みを作る場合は、イベントを登録した瞬間にコールバックしない
　　（標準で用意されているSwingのコンポーネントはそうなってるのかなあ？）
３．オーバライドを前提としているメソッド（paintComponent()など）以外は、絶対オーバライドしない

というルールでカバーできるのかなと思っているのだけど、どなんでしょうか
0079デフォルトの名無しさん2007/10/05(金) 18:51:47
>>76
エクスプローラとかパワポとかテキストエディタは、実際にワンクリ目の動作 （項目選択とかカーソル移動とか） を実行してる。
その後にダブクリの動作を実行するけど、そういう流れで問題ないユーザインタフェイスになってるからな。
0080デフォルトの名無しさん2007/10/05(金) 18:51:58
>>77
おー、シンプルでいいね！
漏れが考えたのはもう少し冗長だった。
勉強になりますた！
0081デフォルトの名無しさん2007/10/05(金) 18:59:28
>>79
言われてみればそうだね。
クリック回数で処理を分けるのは、よほどの理由がないかぎり
やらないほうが良いのかもしれない。
0082782007/10/05(金) 21:27:33
メソッドの呼び出しがイベントを発生する可能性があるから、

４．リスナーの登録はコンストラクタの最後にする。

が必要か。リスナーの登録メソッド自身がイベントを発生したら木阿弥だけど。
いいのかこんなので
0083デフォルトの名無しさん2007/10/05(金) 22:59:32
this参照の漏洩を防止するためにはコンストラクタからイベントリスナを決して登録すべきではない
0084デフォルトの名無しさん2007/10/05(金) 23:41:33
イベントリスナが this を（直接的にも間接的にも）参照してなければ
コンストラクタで登録しても問題ない
0085デフォルトの名無しさん2007/10/06(土) 00:15:19
Swingのイベントの話してるのか

・SwingコンポーネントのイベントはAWTスレッドでしか発行しない

これだけでおけでは？

ところでDesktopがWindowsXPで動かないわけだが、これはいったいどういうコードになってるんだ？
0086デフォルトの名無しさん2007/10/06(土) 00:33:40
solarisチェックが入っている
0087デフォルトの名無しさん2007/10/06(土) 00:50:29
>>85
ttp://www-06.ibm.com/jp/developerworks/java/050826/j_j-jtp07265.shtml
ttp://www-06.ibm.com/jp/developerworks/java/020823/j_j-jtp0618.html
0088デフォルトの名無しさん2007/10/06(土) 01:03:45
>>86
同じXPでも動くマシンと動かないマシンがあるのだ
すべてJREは同一という不思議

>>87
俺が言いたいのはコンストラクタをAWTスレッドでしか生成しないと問題は少ないという意味なんだが
生成中にthis公開するのが変というのは常識だろ

>>78の前提がおかしいのは当たり前で
それをふまえてそのままのコードでいかに問題なく動かせるかの話じゃないの?

そして現在の実装において問題が発生することはないはず（5.0までは）

結局AWT/Swingなんてソース見ればわかるとおりほとんどVM依存コードの塊なんだけど、
SunのVMで実行しているかぎり問題は表面化していないというのが正しいか
0089デフォルトの名無しさん2007/10/06(土) 01:54:54
ぬるぽが発生しなさそうで、発生しそうなコード

final AtomicReference<String> lastSetText = new ...

@Override
public void setText(Strint text) {
super.setText(text);
lastSetText.set(text);
}
0090デフォルトの名無しさん2007/10/06(土) 16:17:20
暇なので書き込み

public class NPO extends JTextField {
public NPO(String text) { super(text); }
>>89 のコード
}

として、nullでない文字列を使ってクラスNPOのインスタンスを生成すると、
その時点で、ぬるぽになる。
オーバライド可能なメソッドをコンストラクタで使うことは、
生成中にサブクラスに this を漏洩しているのと同じでやってはいけない。

このような常識を Swing は平然と破っている。したがって、Swing を使うには、
「このメソッドは、（心の目でみると） final が付いているからオーバライドしてはいけないんだ！」
などという脳内変換ルールが必要なのは明らか。
0091デフォルトの名無しさん2007/10/06(土) 16:24:07
NPOって何かと思ったらNPEのことか
0092デフォルトの名無しさん2007/10/06(土) 17:09:08
nuru-poとnull pointer exceptionか？
0093デフォルトの名無しさん2007/10/06(土) 17:54:36
あんまりぬるぽぬるぽいうから間違えちゃったのね。
0094デフォルトの名無しさん2007/10/08(月) 13:48:57
NullPointerObject
0095デフォルトの名無しさん2007/10/10(水) 06:22:58
JFrame#pack()はsetVisible(true)の前に実行することが推奨されていますか？

ふと以前何処かでそういう文章を読んだことを思い出し、とりあえず盲目的にそれを追記してみた所、
バキュームベッドから空気を掃除機で全部吸い取った様に空間の余裕が消え、ピッチピチに圧縮されました。
setBounds()でウィンドウサイズを設定していたのにたまったもんじゃないです。
しかしまぁそれで大体どういう動きをするメソッドか分かりました。

ただピチピチにパックするだけでは無いだろうと思い調べてみたのですが、
それ以上の情報は見つからず、必ずパックしろといった記事も見つかりません。
今までパックしていなかったにも関わらず何事も無く動いていたので、何かの勘違いだったんでしょうか。
それとも偶々運良く動いていただけなんでしょうか。
0096デフォルトの名無しさん2007/10/10(水) 08:58:37
>>95
余白が欲しければちゃんとBorderなりをセットしてからpackしろ
setBounds()で固定サイズとかダメすぎ
0097デフォルトの名無しさん2007/10/10(水) 11:19:45
>>95
大体とか言わず、正確に理解しといた方がいいと思うよ

http://java.sun.com/javase/ja/6/docs/ja/api/java/awt/Window.html#pack()
＞サブコンポーネントの推奨サイズおよびレイアウトに合わせて、この Window をサイズ変更します

余裕が欲しいコンポーネントには推奨サイズを設定 (setPreferredSize) しておけば、そのサイズに合わせてくれる
0098デフォルトの名無しさん2007/10/10(水) 14:27:26
>>97
合わせてくれるかどうかはレイアウトマネージャ次第。
推奨サイズなんだから無視されても文句は言えない。
>>96のようにBorderでマージンとるのを推奨。
0099デフォルトの名無しさん2007/10/10(水) 20:26:34
スレタイ存続の危機？
次期Java 6、Direct3Dの概要が明らかに - WindowsでのSwing 2D描画を高速化
ttp://journal.mycom.co.jp/news/2007/10/09/021/index.html
0100デフォルトの名無しさん2007/10/10(水) 20:34:26
いやいや、まだまだ低速のタイトルは外せません＞＜

# いや、そういうコトなら結構昔に変わってるはずで・・・
0101952007/10/10(水) 20:44:20
EmptyBorderをセットしてpack、と実装したところうまく行きました。
今までモヤモヤしていた部分が引き締まったようで、とってもすがすがしいです。
>>96さん、>>97さん、どうもレスありがとうございました。
0102デフォルトの名無しさん2007/10/11(木) 00:12:05
>>99
デフォルトでオンはいいよね。MacではOpenGLがオンになるんだろうか・・・。
0103デフォルトの名無しさん2007/10/11(木) 00:29:46
Mac では Java2D は Quartz で描いてたはずかと
0104デフォルトの名無しさん2007/10/11(木) 00:38:44
レンダリング品質はどうなるのだろうか･･･
現状だとDirect3Dモードにすると品質がかわるので使い物にならない
0105デフォルトの名無しさん2007/10/11(木) 01:08:52
>>103
それがさ、Java SE 6からSunのレンダラがデフォルトになる予定なのよ。
0106デフォルトの名無しさん2007/10/11(木) 04:10:28
今までのwin版sun JVMなら-Dsun.java2d.ddraw=trueがデフォルトだったな。
-Dsun.java2d.d3dは支援がまともに得られないから無効だった（パフォーマンス落ちる）
当然-Dsun.java2d.openglはバグ回避で無効。
しかし、D3D9ベースになるのかPS2.0も使うみたいだしVGAとドライバ依存がでかくなるな。

それよりNimbusはマルチバイト文字通るようになるの？ｗ
0107デフォルトの名無しさん2007/10/11(木) 13:03:09
>>105
去年でたDeveloperPreviewでは、PSフォントのレンダリングがガタガタだったんだけど
それ以来、DeveloperPreview無しのまま。
ttp://pc11.2ch.net/test/read.cgi/mac/1138543708/172
>>106
JDK6u5では、日本語通ってるよ。
org.jdesktop パッケージのは古いよ。
http://download.java.net/jdk6/
では、パッケージ自体が変わってる。
sun.swing.plaf.nimbus.NimbusLookAndFeel
ね。
org.jdesktop.swingx.plaf.nimbus.NimbusLookAndFeel
のヤツは化ける。
0108デフォルトの名無しさん2007/10/11(木) 20:02:53
そうなのかスナップショット版だと直ってるのか。>Nimbus

けど、-Dsun.java2d.d3d=trueがデフォになるってことはJOGLでプログラマブルシェーダー使うときは明示的にfalseにしないとOpenGLのシェーダーが効かなくなるな。
（win版JVMはd3dとddrawがtureだと効かない、他はDirectXがないので関係ない）
けど、バックエンドがD3D9とPS2.0に変更になっただけで
描画アルゴリズムは今まで通り、OpenGL版と同じだからパフォーマンスは対して変わらんだろうなぁ。
むしろ、OpenGLパイプラインの一部がJOGLと共通化されてOpenGL使った方がJOGLやSwingにはメリットあるんだよな。

けど、個人向けVGAのOpenGLドライバはNVIDIAもATIもバグが回避出来んしなぁ。

もういっそ、J/Directをｒｙ・・・ｗ

それよりjdk6に密かに入ってるJava Smart Card IO APIのjavax移動はﾏﾀﾞｰ!?
jdk6はいろんなモン隠しすぎｗ
0109デフォルトの名無しさん2007/10/11(木) 20:21:44
>>108
JDesktop側のweeklyビルドの方が古い様子。
どうも、JDK6u5が一番始めに組み込まれてるんじゃないかと。
JDK7にもまだ入ってないし。
0110デフォルトの名無しさん2007/10/11(木) 23:58:07
OpenGLでもDirect3Dでもいいが、そろそろJava2Dでαブレンディングまともに実装してほしい
0111デフォルトの名無しさん2007/10/15(月) 22:49:48
スレ違いなんだが、Mistralって画像ライブラリ？でアニメーションＧＩＦを動かすにはどうすりゃいいんだろうか

読み込んで表示まではいけたんだが、最初の１フレームだけ表示してる感じ

アニメーションＧＩＦだけMistralを使わないとか、もう全部Mistral使わないでやったほうがいいんだろうか
0112デフォルトの名無しさん2007/10/16(火) 01:09:07
マルチイメージのフレーム取得なんて標準で出来るじゃん。
0113デフォルトの名無しさん2007/10/16(火) 01:40:30
>>112
？
0114デフォルトの名無しさん2007/10/16(火) 03:08:55
image I/Oだっけか
確かpngはできないけどgifできたような気がする
0115デフォルトの名無しさん2007/10/16(火) 03:15:32
アニメーションGIF表示するだけなら、ToolkitでloadImageしてdrawImageの最後の引数に表示先コンポーネント指定してやれば勝手にアニメーションする
0116デフォルトの名無しさん2007/10/16(火) 03:15:34
気がする！！！！！！
0117デフォルトの名無しさん2007/10/16(火) 03:55:17
MIDPはするけど、SEやCDCはしなかった気が・・・

>>114
pngのアニメーション仕様なんて画像ビューアーにすら忘れ去られてる存在だから気にしないｗ
対応してるのは次期Fxくらい。
0118デフォルトの名無しさん2007/10/16(火) 04:03:18
Mozillaの出したAPNGは対応入るのかな？
0119デフォルトの名無しさん2007/10/16(火) 19:04:35
mozillaは標準規格の普及に力入れてるな・・・。
jpeg2000は使われることなく次世代策定中かorz
実際、jpeg2000の拡張仕様まで実装したらPNGどころじゃない超万能規格なんだが。

ウェーブレットいいよ、ウェーブレット！
0120デフォルトの名無しさん2007/10/16(火) 22:07:55
jpeg2000はjpegよりブロックノイズとかの面で優れてるけど
良い面を全部帳消しにするぐらい現在のCPUでも結構重いってのがな……
0121デフォルトの名無しさん2007/10/16(火) 22:17:58
確かにデコード重いな。PNGより重いからな。
0122デフォルトの名無しさん2007/10/16(火) 23:24:27
そろそろJAIのメモリリークは直った？
0123デフォルトの名無しさん2007/10/16(火) 23:33:46
標準APIであるDesktopが動かないバグが放置なのに
JAIがまともになるはずないだろ・・・
0124デフォルトの名無しさん2007/10/17(水) 02:22:17
1.3あたりから無視されてるバグもあるしなぁ
0125デフォルトの名無しさん2007/10/17(水) 14:13:04
それは、Bug Paradeには乗ってるの？
0126デフォルトの名無しさん2007/10/18(木) 08:49:07
さて流れを読まず俺がしょぼい質問する…
JFileChooserのcancelボタンに表示する文字を変えるにはどうすればいい？
ApproveButtonは変えれるのに、キャンセルはなぜ変えれない？
0127デフォルトの名無しさん2007/10/18(木) 11:12:57
自分でダイアログを作って、その中に JFileChooser を放り込んで、JFileChooser のボタンは非表示にして自分でボタンを置くってのでどうだ
0128デフォルトの名無しさん2007/10/18(木) 16:42:55
GUIの部品に日本語使いたくなるの俺だけ？(w

JTextFields 名前 = new JTextField();
JRadioButton 女 = new JRadioButton("女");
JRadioButton 男 = new JRadioButton("男");
JButtonGroup buttonGroup.add(女);
JButtonGroup buttonGroup.add(男);

Javaの変数名はダブルバイト可だし、自然言語風に書くのがスタイルなんだし。
0129デフォルトの名無しさん2007/10/18(木) 16:45:33
下２行まちがえた。
ButtonGroup buttonGroup = new ButtonGroup();
buttonGroup.add(女);
buttonGroup.add(男);
0130デフォルトの名無しさん2007/10/18(木) 16:52:32
>>128
ファイルシステムに依存しやすいクラス名と違ってフィールド名やローカル変数は問題は出ないよ

DBでも日本語名のカラムを使うかどうかという話と同じく宗教だから気にすんな
クラス名でつかうのはさすがにとめる
0131デフォルトの名無しさん2007/10/18(木) 17:23:17
文字コードの問題は、機種やOSに依存するからな。
マルチプラットホームのJavaではまさに致命的だし、うかつに手を出せん。
0132デフォルトの名無しさん2007/10/18(木) 17:41:37
変数名で機種依存の問題になるのか？
0133デフォルトの名無しさん2007/10/18(木) 18:21:43
理論上unicodeで表せれば問題ないがフォント側しだいだな。
0134デフォルトの名無しさん2007/10/18(木) 18:24:02
>>132
まあ、無駄に怖がってるのかも試練がな。
だが、linuxなんかで文字コードに苦しんだ俺としては、
少しでもリスクを減らしたい。
0135デフォルトの名無しさん2007/10/18(木) 18:33:24
つーか

変数名に日本語使えるのか！しらんかった！
0136デフォルトの名無しさん2007/10/18(木) 20:23:17
具体的には、
Character.isJavaIdentifierStart(char)
Character.isJavaIdentifierPart(char)
で調べられる。
識別子の頭に使えるかと頭以外で使えるかがチェックできるよ。
0137デフォルトの名無しさん2007/10/19(金) 00:17:38
漢字の変数名はコンパイル通ればOKじゃね？
クラス名はクラスファイルで問題出る可能性があるけど

String 半角カナ = StringConverter.get半角カナ( 全角ひらがな );
氏名フィールド.setText("ほげほげ");
JMenu ファイルメニュー = new JMenu("ファイル(F)");
JMenuItem 開くアイテム = new JMenuItem("開く");
ファイルメニュー.add(開くアイテム);

みたいな使い方もできるから、大胆に使ってみたいんだが、
やっぱりなんか気がひける。w
Java言語のスタイルとしては、ある意味、正しいように思うけど。
0138デフォルトの名無しさん2007/10/19(金) 00:19:14
>>137
入力がうざそうだなぁｗ

俺カナタイパーだから、IMEオンのままコード打つの難しいし
0139デフォルトの名無しさん2007/10/19(金) 00:20:47
うへぇいちいち入力切替なんてやってられんわ
0140デフォルトの名無しさん2007/10/19(金) 00:33:55
俺もカナタイパーなんだけど、鍛えたんで打つのは苦にならんのよ。w
DOS/VキーでATOKの話だけど、タッチタイプで親指で[変換]キーを叩いて、
全角/半角の切替をマスターしたらけっこう楽に入力できるよ。

チームの中で一人だけ漢字でメソッド名つけたりする人いるのはまずそうだが。w
0141デフォルトの名無しさん2007/10/19(金) 00:39:53
JMenuItemのやJTextFieldの数が増えてきたとき、日本語で書いておくと
けっこういい感じなんだけどね。わかりやすい。
本番で採用したことはないけど。
英語圏の人には災難。
0142デフォルトの名無しさん2007/10/19(金) 00:41:07
>>139
ローマ打ちの人に「面倒じゃない？」ってよく言われる

ローマ打ちの方が遅いから、「平気、っーかよくわかんない」
0143デフォルトの名無しさん2007/10/19(金) 00:41:14
>>137
スマン！気が引ける事もなく最近じゃ普通に使ってる。
プロジェクトとして利用を推進してる。
ホント分かりやすいよ。
>>138-140
補完されるから日本語を全部打つ事はあまりない
>>140 ではないが、Macの流儀に合わせて変換キーで全角モードに入るようにしている
0144デフォルトの名無しさん2007/10/19(金) 00:42:46
>>143
まーじーかー

どうせリファクタリングでゴリっと直せるんだし、挑戦してみようかな
0145デフォルトの名無しさん2007/10/19(金) 00:51:14
>>143
おーっ、勇気あるなーww

Javaはもともとダブルバイトを変数名やメソッド名に許しているんだからして、
そういう作法もありだとSunも暗黙に認めてるってことじゃないかと。
将来には見たこともないフォントで書かれたソースコードが
出てくるような気がするんだよね。
0146デフォルトの名無しさん2007/10/19(金) 00:57:15
>>137のようなコードをあんまり見たこと無いからだろう。
個人的に使う分にはまったく問題ないし。
0147デフォルトの名無しさん2007/10/19(金) 00:58:28
もしIDEでちゃんんと補完が効くのなら入力もそれほど苦じゃないかもね
0148デフォルトの名無しさん2007/10/19(金) 01:20:31
>>145
ちょっと気になったので・・・・フォントと文字自体は、別のものですよ。
見た目と意味、くらいの違いがあります・・・・
老婆心ながら、ちょっと調べておいた方がよいかと・・・
0149デフォルトの名無しさん2007/10/19(金) 01:21:39
メソッド名にはあまり日本語を使いたくないな、気分的にw
Javaを全て日本語で書くとかいう研究がどっかであったけど、
ソースがあまりにもカッコ悪くて、プログラミング言語のほとんどが英語で良かったと思っている
0150デフォルトの名無しさん2007/10/19(金) 01:31:10
アニメーションＧＩＦをImageIconとして読み込んで、JLabelにアイコンとして設定したらちゃんとアニメーションしてくれたのね
で、JLabelを継承して、paint(Graphics g)をオーバーライドしたら、拡大縮小回転を楽しめたんですよ。

ここで質問です。
paint(Graphics g)が呼ばれたときに、
アニメーションＧＩＦの何フレーム目を表示しようとしてるか検出できますかね？

拡大縮小回転のさせたBufferedImageを保存して再利用したいんだけど、
今何フレーム目とかわからないと、再利用できない気がするんだぜ
0151デフォルトの名無しさん2007/10/19(金) 01:50:12
>>149
気分とかカッコいいとかそういった主観に基づい行うもんじゃないだろ。
便利なのか必要なのかどうかで違ってくる。
それも言語仕様でサポートされてるから安心して使えるし。
0152デフォルトの名無しさん2007/10/19(金) 03:48:14
日本語ってなかなかにグルー言語よね
0153デフォルトの名無しさん2007/10/19(金) 07:37:14
>>151
同意！
0154デフォルトの名無しさん2007/10/19(金) 07:46:07
>>148
文意を理解してよw
ギリシア語やタイ語の文字のグリフで変数名が書かれているかもしれないってこと。
0155デフォルトの名無しさん2007/10/19(金) 08:45:12
日本語とハングルを同時表示するには両方に対応しているフォントが必要じゃね？
0156デフォルトの名無しさん2007/10/19(金) 09:44:44
SDCだったかでハングルでコメント入ったソースコードは見たことある。
日本語環境のIDE上で表示できるかどうかはしらんけど。
0157デフォルトの名無しさん2007/10/19(金) 12:18:44
>>140
エキサイト翻訳ででてきた意味不明な英語がはいるよりは漢字のほうがましだと思う
そのアプリは日本国外での開発で、海外で売る気があるのかい？と

数年後メンテをやらなくてはならない場合に
ドキュメントが残ってない場合把握しやすいというメリットもある

DBで日本語の項目名いれてNetBeansなりでJPAを生成でもすれば
日本語名のプロパティが見事に生成されるわけだが、わりとみやすいし
いざとなればリファクタリング一発だから問題はねぇな
0158デフォルトの名無しさん2007/10/19(金) 12:19:33
>>150
とりあえず軽量コンポーネントでpaintそのものをオーバーライドするのやめれ
0159デフォルトの名無しさん2007/10/19(金) 14:17:33
>>157
NetBeansだとGUIまわりのリファクタリングはひっかかるケースが多いけど。
0160デフォルトの名無しさん2007/10/19(金) 14:44:40
Javaのバイトコードって変数名なんかも保存してるんじゃなかったっけ？
変数名に日本語使えばバイトコードにも残るの？
0161デフォルトの名無しさん2007/10/19(金) 15:14:30
UFT8に変換されて残るからソースのエンコーディングがなんであれ問題なし。
0162デフォルトの名無しさん2007/10/19(金) 16:18:19
ローカル変数も残るんだっけか？
0163デフォルトの名無しさん2007/10/19(金) 16:24:36
テストケースのメソッドは日本語がたいへんよろしい。
0164デフォルトの名無しさん2007/10/19(金) 16:26:36
デバッグ情報として残すことも残さないこともできる
0165デフォルトの名無しさん2007/10/19(金) 21:02:52
ローカル変数やGenericsの型指定は残らないと思った。
C#だとGenerics型は残るらしいね。
Javaのはキャストしてるだけってのが理由だろうけど。
0166デフォルトの名無しさん2007/10/19(金) 21:22:05
ローカル変数はフレームごとに領域(とlongとかあるので型のサイズ)だけ
確保されてたはず。
0167デフォルトの名無しさん2007/10/19(金) 21:42:43
どっちにせよ日本語変数は問題なさそうだな
0168デフォルトの名無しさん2007/10/19(金) 22:25:36
>>159
NetBeansのGUIコンポーネントの話はしてないよ
リファクタリングはJPAのほう
GUIのコンポーネントのリファクタリング問題は4.1あたりで直すとか言ってたのだが
絶賛放置中

>>167
なさそうではなくて問題ない
問題が出るとしたらマッピングがおかしい場合だけ
0169デフォルトの名無しさん2007/10/20(土) 00:50:24
>>159
Netbeansは、リファクタリング無しでも日本語が使えないGUIエディタまわりがあるな。
Javaで作って、何でそうなるのか問い詰めてやりたい。
0170デフォルトの名無しさん2007/10/20(土) 04:02:05
そりゃ日本語使ってないやつが作ってんだからそうなるだろ。
使わないものがどうなっていようとそれは仕様です。
0171デフォルトの名無しさん2007/10/20(土) 04:45:28
aho
0172デフォルトの名無しさん2007/10/20(土) 06:30:17
>>170
確かに国際化は意識して対応しないとまともに動かないけど
それってsunは他言語のことなんて知りません、手抜きですって告白してるようなものなんだが
0173デフォルトの名無しさん2007/10/20(土) 06:52:51
Sunは、NetBeansを支援しているだけ。建前上は。
0174デフォルトの名無しさん2007/10/20(土) 21:09:54
国際化で一番ひっかかるとこってどこだろうね。
やっぱフォントまわりかな。
文字列はダブルバイトでも1文字でカウントしてくれるし、
ファイルにはUnicodeで書き出するようにすればてっとり早い。

でもアプリの性質にもよるか。
エディタのように文字を扱うのは問題おきやすいかもね。
■ このスレッドは過去ログ倉庫に格納されています