【初心者歓迎】Java質問・相談スレッド65 Update 1

ごめんなさい、あげちゃった。

>>942
NetBeansのGUIエディタにGridBagLayoutエディタがついてて、それをいろいろいじくってるとわかりやすい。
どういうコードが吐かれるか確認しながら使うと、コードの勉強にもちゃんとなるしな。
GUIエディタは勉強のためのツールだから、積極的に使え。
知ってる人が楽するためのツールなら、知らない人にも楽ができる。

>知ってる人が楽するためのツールなら、知らない人にも楽ができる。

楽はできてもミニはつかないな。
俺ならまず、エディタで作ることを薦めるね

ところで次スレまだ〜

コードを目で見て理解したと思える優等生なお方はエンジニア向いてないんだけどな。

自分自身のファイル名を取得するのはどうすればいいのでしょうか？

String filename = File.class.getName();
とか、
String filename = FileVew.class.getName();
とかをやってみたんですが取得できません・・・。
どのようにすれば自分自身のファイル名を取得できるのでしょうか？
よろしくお願いします。

>>956
自分自身のファイルは取れません。単品のクラスファイルかもしれないし JAR で
まとめられてるかも知れないし、ネットワーク上の別のサーバにあるかもしれないし。
あえて言うなら this.getClass().getName()。

>>954
動き確認してから、手打ちすりゃいい。
目で見て実感したほうが身について忘れやすい。
エディタだけでやる方が時間かかるわりに身につきにくいよ。

×忘れやすい
○忘れにくい

>>956
>>930
正しくは>>956なんだけど

そうゆう俺流のススメは無意味で不毛な論議

取れないんですか・・・。
規則に乗っ取ったファイル名をつけてそこから
プログラムが自分の役割を判断するものを作ろうとしたんですが
だめぽそうですね・・・。

ありがとうございました。

>>962
Class.forName("クラス名).newInstance()
Beans.instantiate(クラスローダー, "Bean名");

ちょっと早かったかもしれませんが、次スレ立ててみました。
こんな感じでどうでしょう？
【初心者歓迎】Java質問・相談スレッド65 Update 2
http://pc8.2ch.net/test/read.cgi/tech/1118243553/

>>942
ほい。

http://jubilo.cis.ibaraki.ac.jp/~isemba/PROGRAM/JAVA/java.shtml

次スレ
ttp://pc8.2ch.net/test/read.cgi/tech/1116750427/

>>964
重複してるな。ちゃんと削除依頼しとけよ。

>>946
そうか、じゃあやっぱり AWT オンリーでがんばった方がいいんでしょうかね。

>>948
>プラットフォームフリー、 インストールフリーってなんじゃらほい
>IE内蔵のJavaVM？

ワープロくらいしか使わない職場とか、パソコンが普及しだしたころにとりあえず
買っちゃった個人の家とかにある、ネット接続してないかも知れない、ヘタしたら
Win98 とかのマシンで、ファイルのコピーすら、ままならないような人に、
CD 渡して、何とか CD のドライブ名だけは見つけてもらって、"x:hoge.html"を
実行すれば動くようなもので、Mac でも動くようなもの、です。
あと、たぶん対象者は持ってないと思うけど Linux とかでも動くもの。
まぁ、ほとんどの場合は IE内蔵VM ということになるでしょう。

>>968
JDK1.5で開発して、（アプレットじゃなくアプリケーションで）
JREごと配布するとか

>>968
CDにLinux(knoppixとかberryのような1 cd Linux)を入れて、
それにJREを予め追加しといて、自動起動させるとかどうでしょうか？
そうすればCDにOSが含まれるので、x86でCDDがあればどんなPCでも
動くのではないでしょうか？
データの保存にはUSBメモリやスマートメディア等が使えます。

立った順番から判断して次スレはこれ？

【初心者】Java質問・相談スレッド66【大歓迎】
http://pc8.2ch.net/test/read.cgi/tech/1116690777/

 　　☆ ﾁﾝ
 
 　　　 　 　 ☆　ﾁﾝ　　〃　 ∧＿∧ 　 ／￣￣￣￣￣￣￣
 　 　 　 　 　　ヽ　＿＿_＼（＼・∀・）＜　 >>950-951へのレスまだー？
 　　 　 　 　 　 　 ＼＿／⊂　⊂＿)＿ ＼＿＿＿＿＿＿＿
 　　 　 　 　 　 ／￣￣￣￣￣￣￣／|
 　　　　　　　　| ￣ ￣￣￣￣￣￣:|　:|
 　　　　　　　　|　　　　　　　　　　　.|／

テンｐラパターン使っとけ

>>973
>>925

>>971
こっち↓の方が進んでる

【初心者】Java質問・相談スレッド67【大歓迎】
http://pc8.2ch.net/test/read.cgi/tech/1116750427/

>>969
プラットフォーム毎にインストール手順が違うのも気になるし、そもそもインストール
作業が必要になると、それだけトラブルのリスクが増すと思うので避けたいと
思うのですが。

>>970
マックが、、、

自分は開発のプロではないので、自分の知ってる環境しかわかりませんし、
後々、自分以外の、自分よりコンピュータに詳しくない人間にサポートを
引き継ぐことになると思うので、ワープロだけとか、WWW とメールだけとかしか
知らないオッチャンなんかに渡しても、できるだけトラブルのリスクが少なくなる
ようにしたいのです。

>>976
＞後々、自分以外の、自分よりコンピュータに詳しくない人間にサポートを
＞引き継ぐことになると思う

いろいろ言いたいことはあるけど、
作る必要ないんじゃないか？

プログラミング関連の話とは関係なくて申し訳ありませんが質問させてください。

現在、メインのアプリとしてJava Runtime Environment上で動作する
翻訳支援ソフトを使っています。（Sun 謹製、OS は Win2k）

こいつは、翻訳メモリが蓄積されるに従ってどんどん動作が重くなっていきます。
そこで、できれば動作を高速化したいのですが、このようなアプリケーションには

デュアルCPUまたはデュアルコアが効果的である
のか
単純に高クロック(OfficeProductivityが高い)CPUの方が効果的である
のかを教えて頂きたいのです。

Java Runtime EnvironmentがどのようにCPU能力を占有するかが分かっていないので、
Athlon64 X2でマシンを組もうかどうか迷っています。

できればSunの方にこっそり教えて頂きたいのですが...

>>978
どっちもハズレ。
正解はメモリを大量に積む。
Javaで何かしようと思ったら最低１G積む覚悟は必要。
理想は２G。

>>979
アプリによるだろうが
そういうあほな考え方って以前合ったな・・・と

例の1つのマシンにTomcatメモリ半分にして乗せてGC時間安定させました

というのを思い出した

>>978
そのアプリを作ったやつしかどのように重くしたかがわからんよ
長時間稼動させると重くするというコードが入ってるかもしれんし
普通はネックとなる場所をつぶしてリリースするもんだがな

作ってない人だったらメモリ使用量をチェックして頻繁に殿堂入りするようなfullGCがはしりまくっているかの
確認くらいしかできんかも

1に計測2に計測
ボトルネックがわからずに妄想を続けるのは時間の無駄です

>972
雑感だが
> getStringValに引数を1つ増やしてファイル名も与えるのも
> 利用する方はかったるいし（クラスにしちゃえばコード補完できるから）。
ここイミフメ。どのみちどこかで手書きする必要がある文字列じゃないのかそれは。

そもそも何でそんなにstaticにこだわるのか、インスタンス化を嫌がるのかが分からん。
>プロジェクト変わるとパッケージ名変わってめんどーだなーとか
これがその理由だと言われてもさっぱり分からんままなのだが、
それくらいファイル先頭の一行変えれば済むことじゃないのか?
Environmentを利用するクラスも作り置きのを使いたいということなら若干面倒かもしれんが
それだってエディタで一括置換とかできそうなもんだし、最後の手段として自分個人のパッケージ
(jp.gr.java_conf.hogeでもnet.sf.hogeでも好きなの使えばよろし)に放り込んでしまえば
その問題は解決じゃないか?

>>977
> 作る必要ないんじゃないか？

そういわれても。。。仕事なんで。

>>922
Microsoft VM for Javaを当てにしているのなら、それは間違いだ。
今後サポートされない上に、今のWindowsXPには標準で付いてないから。
将来「何で動かないの？」っていうトラブルを抱えるはず。

>>984
「当てにしている」 というよりも、 「でも動く」 ようにしようと思ったんですが。

JDK 1.1 で作っておけばどこでも動くと思ったんですが、そうじゃないんですか？
不勉強で、将来動かなくなる理由がわかりません。

>>985
いや、だから、そのJRE1.1(またはその相当品)がない環境があったらどうするの？
動かないでしょ？
JRE入れるしかないでしょ？
そしたら、結局はインストールメディアにJREを添付した方がいいでしょ？
どうせ添付するなら 1.1にこだわる必然性はないでしょ？

>>982
レスありがとうございます。
>> 利用する方はかったるいし（クラスにしちゃえばコード補完できるから）。 
>ここイミフメ。どのみちどこかで手書きする必要がある文字列じゃないのかそれは。 
getStringVal("hoge.property", "foo")って設定値を取得する度に
"hoge.property"を書かなければ成らないのが面倒という事が言いたかったのです。
hoge.propertyを読み込んでいる専用のクラスがあれば、そのクラス名を
書いてgetStringVal("foo")で取れると。

>そもそも何でそんなにstaticにこだわるのか、インスタンス化を嫌がるのかが分からん。
そうですね、個人的な感覚なので意見が分かれる所だと思います。
私の場合は、環境変数は取り出し方がシンプルであればシンプルであるほど
扱いやすいと考えるので、staticで実装しています。

>>プロジェクト変わるとパッケージ名変わってめんどーだなーとか 
>これがその理由だと言われてもさっぱり分からんままなのだが、 
>それくらいファイル先頭の一行変えれば済むことじゃないのか?
その通りです。やはりここに落ち着きますか
（ソースコードレベルでの再利用）

すなおにsingletonつかえよ

>>987
名前を変数ではなく、 String を返す static なメソッドとして実装して、
子クラスでオーバライド。

907なら

protected static String name = "parent";

ではなく、

protected static String getName() { return "parent"; }

すみません。勘違いでした。忘れてください。

>>986
「どこでも動く」は言い過ぎましたが，今のところ 1.1 対応の VM が乗ってない
マシンを使ってる人は多くなく，新しい WinXP 使ってる人は，アプレット動かそうと
するとほとんど勝手にインストールしてくれる（ネット経由か，OSプレインストール
マシンならローカルにインストール情報を持ってると思うんですが）と思ったんです。

将来，デフォルトではVM のない環境が多数派になっても，アプレット使ってる Web サイトは
多いので，そのころには一般的な「パソコンの使い方」 の情報として，アプレットを
動かす方法は一般に流れるか，初心者でも困らないように環境が整えられてる
かなとと思うんですが。

>>987
こんなんでも、まだダメなんでしょうか

public class Environment {
private static Properties Property = new Properties();

public static void load(String name) {
try {
Property.load(Environment.class.getResourceAsStream(name));
} catch (IOException ie) {
//Logなりてけとーに
}
}

public static String getStringVal(String key) {
return Property.getProperty(key);
}

public static int getIntVal(String key, int def) {
String val = Property.getProperty(key);
return NumberUtils.stringToInt(val, def);
}
}

>>991
原理主義は聞き流せば良い。

>>991
そこまで激しく不確定な要素をあてにしたくないな。
ちなみにMSのJVMはバグが多く、SunのJVMで動いたものが
MS謹製では動かなかったり、妙な挙動を示したことがあるので
俺なら絶対にやらないと思うが。

まあ自分がやりたいようにやってくれ。

>>992
レスありがとう御座います。

それだと、何がロードされているも分からず、ロードされている
事も保障されず、マルチスレッド環境では悲惨な事に
なると思いますが、いかがでしょうか。

>>993
>>994
いろいろご意見ありがとうございます。

自分はプログラミングのプロではなく，自分の業界のお客さんが便利に
使えそうな，簡単なツールを作って配ろうとしているところです。
なので，開発の知識に乏しく，すごく不安があったのですが，否定意見は
あるにしろなんとか一つの方法として成り立ちそうなので，そういう意味では
少し安心しました。

　　　何よりも類似スレが乱立する中，何とか1000までに一応の結論を得てよかった。。。

>>995
ああ、もうギブ
普通に

public class Env0 {
public static final Properties PROPS = PropertiesFactory.create("Hoge");
}

とかやって、フィールド PROPS 経由で操作
（PropertiesFactory みたいなのは、commons に行けば転がっているだろう）

おおよそ？Properies はスレッドセーフっぽいし、
static final にしとけば、参照も他のスレッドから（コンストラクタが終わった状態で）見れるはず。

Java 1.5 からは スタティックフィールドもインポートできるはずだったから、
これで許して。。

>>995 (907)
つうかstaticにした段階で継承とオーバーライドを使える範疇外になる（そういう言語仕様）なんだから、

staticをつかって継承やオーバーライドやコンポジションやらの利点はあきらめる。つまり
テンプレートメソッドパターンもあきらめる。

しかねえじゃん。言語仕様にいちゃもんつけたところで現実が変わるわけでも無し。
だいたい、そこまで苦労して実現したとしても、ソース上で省略できることって

Environment env = new Environment(); <--- このインスタンス化の一行
String prop1 = env.getXXXXX()
String prop2 = env.getYYYYYY()

の最初の一行だけなんだろ？ この一行でそんなに環境変数取得が面倒になるか？
逆にこっちにすれば、Javaのオブジェクト指向機能のすべてが使えるのに。

999

1000

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。