07/08/01 15:02:46
>>125
つ Pnuts・・・
128:デフォルトの名無しさん
07/08/01 17:08:04
スクリプトだし、質とか速さとかどうでもいいよ。
とりあえず、Javaが動くスクリプトエンジンを実装してくれ。
129:デフォルトの名無しさん
07/08/01 17:13:49
言語としてのJavaならスクリプトエンジン作るよりも
コンパイラAPIの拡充の方が良い。
メソッド宣言時のシグネチャだけみたいな細かい単位で
構文解析＆名前解決してくれればそれで良い。
ツール作る時とか、そっちの方が都合良いし。
130:デフォルトの名無しさん
07/08/01 18:31:03
そんなこといってちゃ、いつまでたってもjavax.scriptでJavaはサポートされないよ。
自分の都合だけで考えるのもいいけどね。
131:デフォルトの名無しさん
07/08/01 20:05:04
俺は両方欲しいぜ、ベイベ
わがままな、俺の願いを聴いてくれよ
イエー
132:デフォルトの名無しさん
07/08/01 20:15:11
>>126
具体的には？
133:デフォルトの名無しさん
07/08/01 21:04:43
何につかうんだよそんなもの
134:デフォルトの名無しさん
07/08/01 21:36:56
>>130
標準添付されないというだけで、javax.scriptでJavaはサポートされてるわけだが。
135:デフォルトの名無しさん
07/08/01 22:35:59
>>132
具体的にはって標準添付されてんのRhinoしかないじゃないか。
136:デフォルトの名無しさん
07/08/01 22:37:07
標準で入ってないと意味ないし、無駄な努力なのだが。
137:デフォルトの名無しさん
07/08/01 22:40:17
SPI使えるんだから、クラスパスに含めるだけで新しいスクリプト言語使えるようにできるんだが……
138:デフォルトの名無しさん
07/08/01 22:42:38
おれは、C言語をスクリプトで実装して欲しいぜ！
それもC99を！
139:デフォルトの名無しさん
07/08/01 22:45:08
>>137
ん？俺が無知なだけなのか・・
140:デフォルトの名無しさん
07/08/01 23:13:33
まあ実際無知なんだろうな。
141:デフォルトの名無しさん
07/08/02 05:09:30
>>135
いや、オレもRhinoしか添付されてないと思ってたのだが、それだと野良スクリプトエンジンの方が品質がいいってのがひっかかる。
Rhinoよりいいスクリプトエンジンって何だ？
142:デフォルトの名無しさん
07/08/02 05:10:04
>>136
いらん。
143:デフォルトの名無しさん
07/08/02 12:28:23
>>141
普通にビルドしたRhino。
144:デフォルトの名無しさん
07/08/02 14:28:20
>>141
つ Pnuts
145:デフォルトの名無しさん
07/08/03 00:08:05
>>138
個人的にはFORTRANが良い
146:デフォルトの名無しさん
07/08/03 00:12:18
たしかSunがFortressっての開発中だったと思う。
並列計算に特化したJavaとFortranを参考にしたスクリプトっての。
147:デフォルトの名無しさん
07/08/03 00:12:52
>>144
pnutsそんなにいい？
まだこなれてない感じバリバリなんだけど。
yieldの挙動とか。
148:デフォルトの名無しさん
07/08/03 04:44:27
あんま関係ない話で恐縮なんだけど、javax.script バブルの火付け役が php だって噂は本当なん？
149:デフォルトの名無しさん
07/08/03 06:10:32
msのcliに対抗するため
150:デフォルトの名無しさん
07/08/03 06:16:58
C言語やC#にある値型の struct はいつサポートされるの？
151:デフォルトの名無しさん
07/08/03 08:37:18
>>148
script言語の共通基盤になるチャンスを見逃すわけがない。
javascript, php, python, ruby実装環境をごっそり頂きかも知れない。
コンパイラ基盤もちらほら出てきているし。
152:デフォルトの名無しさん
07/08/03 12:00:15
>>150
なぜそんなものが必要なのか？理由を明確に
153:デフォルトの名無しさん
07/08/03 12:54:23
リンゲージがその関数内であるオブジェクトに対して、イチイチnewしないで済むことが言語として保障されることになる。
154:デフォルトの名無しさん
07/08/03 13:02:33
>>153
コンパイル時に最適化情報がバイトコードに埋め込めればいいんだよね～
そしたら、ガンガンエスケープ解析できる
155:デフォルトの名無しさん
07/08/03 13:28:43
>>151
いや、知り合いから
「php を java vm 上で動かそうって話が最初で、そのあと他の軽量言語が追従した」
って話を聞いたんだけど、本当なのかなって。
156:デフォルトの名無しさん
07/08/03 13:54:15
>>154
そういう小手先解析よりも、普通に言語としてサポートしろってこと。
struct Point {
double a,b
};
どう考えても需要あるだろ。
157:デフォルトの名無しさん
07/08/03 13:56:16
>>155
それだけ需要があるなら、PHPがまずサポートされるはずじゃないか？
VMで他の言語が動けばいいのであって、どうでもいいけど。
158:デフォルトの名無しさん
07/08/03 14:24:28
>>156
その程度なら不要。
値型の利点は、newが必要とかより、
代入が必ずコピーになることによって、
同一オブジェクトに対応する変数が一つであることを保障できることだと思うんだが。
159:デフォルトの名無しさん
07/08/03 16:26:23
>>158
需要の論点ではPointで示したが、利点としては例えが悪かった。
では必ずコピーになる利点のために導入するのではどうだ？ほしいだろ？
160:デフォルトの名無しさん
07/08/03 16:41:03
いや別に
161:デフォルトの名無しさん
07/08/03 17:45:57
値型が導入されたら、今度はポインタ演算を欲しがるに違いない
162:デフォルトの名無しさん
07/08/03 19:10:24
C#はstructの導入に失敗したからNullableが出来たんでしょ
恥ずかしい実装まで追従する必要ないから、別に要らないなぁ
どうしてもってのならByteBufferをラップすりゃいいし
163:デフォルトの名無しさん
07/08/03 19:34:17
値型ってメモリ効率に関する利点のために導入するもんだろ。
164:デフォルトの名無しさん
07/08/03 19:36:02
それが理由ならエスケープ解析が導入されたから今後は不要でしょ
165:デフォルトの名無しさん
07/08/03 21:11:05
>>161 それはない。
166:デフォルトの名無しさん
07/08/03 21:17:46
>>164
複雑じゃなくていいから、普通にCと同じのでいいよ。
メソッドもCの関数ポインタみたいに、staticのみでいい。
エスケーポ解析よりも言語に導入のほうが楽だと思うけど、そうでもないのか
まあ、そのうちちゃっかり導入されるんだろうけど。
167:デフォルトの名無しさん
07/08/03 22:14:07
JDK7 build17
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)
168:デフォルトの名無しさん
07/08/04 00:41:24
いまさら導入されても、C の register 変数と同じ運命をたどる予感。
169:デフォルトの名無しさん
07/08/04 02:00:02
register にも、一応アドレスを取れないという効果はあるんだぞ！
170:デフォルトの名無しさん
07/08/04 07:19:54
>>157
PHPみたいなどうでもいい言語をまずサポートする必要性がみあたらない。
171:デフォルトの名無しさん
07/08/04 08:47:45
structのメモリー効率のよさってのは、オブジェクト廃棄時のコスト云々じゃなくて、
newに頼ってオブジェクト生成するときのコストがまったくないってことだろ。
関数呼び出しでスタックに自動生成されるのであって、newによるオーバーヘッドは
かからないいってこと。
172:デフォルトの名無しさん
07/08/04 08:51:14
オブジェクトがほかのメソッドに伝播される可能性を考えると、エスケープ解析で自動的にやってくれるのが一番効率がよさそうだな。
173:デフォルトの名無しさん
07/08/04 08:52:09
structは、コピーによって、ここのオブジェクトの同一性の確保も
そのとおり利点ではあるが、エスケープ解析の小手先技なんぞに頼らないで
優先的に言語でサポートするのが妥当だろ。
assert, enumとかよりも先にさ。
Javaの文法は、結局Cの文法を真似てるだけってことを忘れて、
「エスケープ解析もできる俺ってすごいだろ」っていい気になってるだろ？
174:デフォルトの名無しさん
07/08/04 08:52:42
エスケープ解析ってのはそれをやるんだよ。
C#のstructと同じような最適化がされることになり、
逆にC#2.0で対応するはめになったNullableのようなstructの欠点も無い
175:デフォルトの名無しさん
07/08/04 08:54:47
>>171
まあ、メリットはあっても、それが"大きく"効いてくるのはかなり特殊なケースで、
そういうのが大量にある応用の時は、ハイバネでいい、ってのが今の流れなんじゃないの?
176:デフォルトの名無しさん
07/08/04 08:55:56
JavaのenumはCのenumとは違うぞ。
定数そのものに振る舞いを持たせることが出来るし、
なおかつタイプセーフだ。
177:デフォルトの名無しさん
07/08/04 08:57:25
メモリーの効率とかじゃなくて、
structを使いたいプログラマーの切実な要望には答えられないのかね？
そういうエスケーポ解析の新技術はどうでもいいからさ。
178:デフォルトの名無しさん
07/08/04 08:58:34
>>173
で、エスケープ解析に比べたstructの利点ってなんなの？
179:デフォルトの名無しさん
07/08/04 08:58:58
structの欠点の無いむしろメリットとなるようなカラクリがあれば導入されるかもな。
180:デフォルトの名無しさん
07/08/04 09:02:12
ちなみに、structなど値型を使いたい場面は、
forや関数呼び出しで100万回以上まわす。
そういう小型オブジェクトの短期生成は、newでは向いてないし、役不足だろ。
またエプケール解析とかいうのか？
GCの新技術はJava以外のVM使うスクリプトにもメリットあるだろうが、
そういうのは使うほうからみてどうでもいいから、まずはJava言語で導入しろ。
181:デフォルトの名無しさん
07/08/04 09:02:38
>>177
メモリーの効率とかじゃないなら、structを使いたいっていう切実な要望っていうのは、新技術以上にどうでもいいんじゃないかと思う。
182:デフォルトの名無しさん
07/08/04 09:03:54
>>180
使う方から見てどうでもいいのがstructだと結論づいてるのに何を・・・
183:デフォルトの名無しさん
07/08/04 09:04:17
>>176
使うほうからすれば、C,Javaどちらのenumも同じ。
いつ使えるようになったかといえば、Javaはサポート遅すぎ。
184:デフォルトの名無しさん
07/08/04 09:04:37
>>180
エスケープ解析で十分です。どうもありがとうございました。
185:デフォルトの名無しさん
07/08/04 09:05:49
>>183
全然違うっての。お前のいう「使う人」って誰だよ。お前限定じゃねーか。
お前はCだけ使ってろ。
186:デフォルトの名無しさん
07/08/04 09:06:52
>>181
きみ、structとclassは実質同じってことを知ってるのか？
187:デフォルトの名無しさん
07/08/04 09:08:35
>>186
C++のデフォルトアクセスレベルの話で言ってる？
同じものなら要らないだろ
188:デフォルトの名無しさん
07/08/04 09:09:11
structを否定するってことは、classつまり、構造体型（集合型）を否定しているようなものだけど・・
君の理解じゃ、ポインタがどうとかってあたりで止まってるんだろうな。
189:デフォルトの名無しさん
07/08/04 09:09:20
>>186
だから、なに？メモリ効率以外に、structの利点ってあるの？
190:デフォルトの名無しさん
07/08/04 09:10:21
>>188
なんで？
きみ、エスケープ解析の意味ちゃんとぐぐってる？
191:デフォルトの名無しさん
07/08/04 09:15:05
なんか、エスケープ解析をわかってないやつがいるみたいなんで書いておくけど
for(int i = 0; i < 10; i++){
Point p = new Point();
p.x = i * 2:
p.y = i * 4;
System.out.println(p.x + ":" + p.y);
}
が
for(int i = 0; i < 10; i++){
int px = i * 2:
int py = i * 4;
System.out.println(px + ":" + py);
}
に最適化される技術な。
192:デフォルトの名無しさん
07/08/04 09:34:02
まとめると、「エスケープ解析の意味がわかんないやつが暴れてましたとさ」でいいの？
193:デフォルトの名無しさん
07/08/04 10:12:30
>>180
エプケール解析て…これは釣りだろ。
それから値型もnewされることに変りはないぞ。
194:デフォルトの名無しさん
07/08/04 10:20:21
Java版のaptみたいなのがそろそろ出てきてもいい頃合だね。
各種IDEやmavenの資産、そしてJAMの登場によって下地は十分のはず。
JDKに同梱されれば、環境構築のコストが激減しそう。
195:デフォルトの名無しさん
07/08/04 11:09:02
SunがOpenSolaris用のパッケージ配布機構を発表したぞ。
ZFSに基づくサービス、実装らしい。
Sun、『OpenSolaris』でバイナリパッケージ配布モデル採用へ
URLﾘﾝｸ(japan.internet.com)
196:デフォルトの名無しさん
07/08/04 11:55:05
またエスケープ解析が得意の彼か
彼の言い分も一理あるが、単純に彼は自分の技術を自慢したいだけだから、ほっとけ
197:デフォルトの名無しさん
07/08/04 11:55:58
>>193
そもそも struct とか言う奴は大抵釣り。
198:デフォルトの名無しさん
07/08/04 12:01:23
JOGLやjinputとかをJDKから簡単に取り寄せられたら便利だね
199:デフォルトの名無しさん
07/08/04 12:18:37
下手にやると複数バージョンのjarが入り混じってカオスになるけどね
200:デフォルトの名無しさん
07/08/04 12:25:12
>>196
そういう話は、的確な議論してから言ったほうがいいと思う。
201:デフォルトの名無しさん
07/08/04 13:47:09
struct ： スタックに値を割り付ける
エスケープ解析 ： スタックにオブジェクトを割り付ける最適化手法
オブジェクトが対象のエスケープ解析の勝ちでおｋ
structは時代遅れの産物
202:デフォルトの名無しさん
07/08/04 14:13:45
>>196
自分の視点でしか判断できないのが彼のような技術者ってもんだし、
他人の要望とかまったく無視で自分の技術一点張りだな、こいつは。
つまりは、一人でコソコソとエスケーポ解析してろってこったな。
あー、ねくら、ねくら
203:デフォルトの名無しさん
07/08/04 14:17:20
>>201
おまえはばかか？勝手にしこってろ。嫌ならCをべんこうしなおせな。
204:デフォルトの名無しさん
07/08/04 14:22:58
>>202
C C++ アセンブラのときでも、小手先技使って最適化大好きって輩がいるけど、こういう根っからの技術者って人の話聞かないしね。こういうねくらは、あんまり表にしゃしゃり出てこないで中にこもって解析していて欲しいよ。
205:デフォルトの名無しさん
07/08/04 14:31:59
有能な学生をいじめたらだめれす！
206:デフォルトの名無しさん
07/08/04 14:36:57
>>201
おまえのその論理だと、Java標準のlong doubleなどプリミティブ型は時代遅れなのか？
そして解析手法を駆使する方が今風なのか？
おまえ、そんなことしてるよりコンパイラ作ってみろ。そうすれば分かる。
207:デフォルトの名無しさん
07/08/04 14:39:43
>>206
暇ならコンパイラとVMに struct実装して OpenJDKあたりにパッチ送ってみれば？
どれぐらいメモリ効率が良くなるかみたいなデータも示せば採用されるかもよ？
208:デフォルトの名無しさん
07/08/04 14:46:21
>>206に コンパイラやVMを書き換えるだけのスキルがあるとは思えないが
209:デフォルトの名無しさん
07/08/04 17:08:16
ひさびさに高品質の夏厨があらわれたな。
210:デフォルトの名無しさん
07/08/04 21:46:11
>>173
＞「エスケープ解析もできる俺ってすごいだろ」
惚れました
211:デフォルトの名無しさん
07/08/05 00:44:29
>>191みたいな馬鹿に突っ込める奴は、
ここにはいないのかｗｗｗ
エスケープ解析とは、ソースコードを解析してバイトコードの最適化を行う話じゃない。
Javaのコンパイラはソースコードとバイトコードの対応付けが規定されているので、
そもそもバイトコードの最適化はありえない。
メソッド内で生成されたインスタンスが、
メソッドの外へ「逃げるか逃げないか」を判断する技術だ。
returnや引数やフィールドに参照が渡されるコードがあれば、
「メソッドの外に逃げる」と判断されて、
インスタンスはヒープに確保される。
逆に「メソッドの外に逃げない」と判断されたら
インスタンスはスタックに確保される。
わかったかいｗｗｗ？>>191
212:デフォルトの名無しさん
07/08/05 00:44:39
くそ天皇 くそ天皇 くそ天皇 くそ天皇
いい加減死ねっつってんだろ屑ニートくそ天皇が
相変わらず病的な粘着っぷりだな屑ニートくそ天皇が
毎日毎日毎日粘着出来て良いでちゅねくそ天皇
くそ天皇さっさと死にやがれゴミが
東京に在住している精神病珍米糞ニートくそ天皇君の末路
さっさと精神病院逝くか首吊って逝くか選べや糞天皇が
早く死ねよ糞ニート天皇が
粘着精神病屑ニート天皇君は自らニートくそ天皇であると公言しました
さっさと死ねやくそ天皇が
早く死ねっつってんだろ屑ニートくそ天皇が
お前みたいなゴミクズ天皇は息してるだけで空気が汚れるからさっさと死ねや
とっと死に晒せや糞ニート天皇が
213:デフォルトの名無しさん
07/08/05 01:22:48
>>211
引数に渡すだけでもエスケープと判断されるのか。
オブジェクトの生存期間がスタックのそれに制限されているだけじゃだめなのね。
214:デフォルトの名無しさん
07/08/05 01:30:19
渡したメソッドがインライン展開されてれば大丈夫
渡した先でそのオブジェクトがどこに保持されて生き延びるかわからんからね
215:デフォルトの名無しさん
07/08/05 01:32:40
>>213
引数がListで、そのListに生成したインスタンスを追加したりとか。
216:デフォルトの名無しさん
07/08/05 01:33:12
>>214
それってつまり実行して見るまで分からんってこと？
217:デフォルトの名無しさん
07/08/05 01:35:41
エスケープ解析の間違ったネタが書き込まれているし・・・
それに誰も突っ込まないし・・・
そもそもエスケープ解析は次世代ネタじゃないし・・・
終わってね？
218:デフォルトの名無しさん
07/08/05 01:38:48
当時の流れて下手に突っこんだら粘着に餌与えるだけだけどな
219:デフォルトの名無しさん
07/08/05 01:40:32
>>216
HotspotVMは実行時にコンパイルするんだから大丈夫
220:デフォルトの名無しさん
07/08/05 09:39:23
>>211はここを見るべき
URLﾘﾝｸ(www-06.ibm.com)
221:デフォルトの名無しさん
07/08/05 10:18:29
>>220
おまえ191だろｗｗｗ
そんな記事は知ってるわ。
そもそもインライン化とエスケープ解析は違う。
222:デフォルトの名無しさん
07/08/05 13:22:13
>>211
> Javaのコンパイラはソースコードとバイトコードの対応付けが規定されているので、
> そもそもバイトコードの最適化はありえない。
（ ﾟдﾟ）ﾎﾟｶｰﾝ
223:デフォルトの名無しさん
07/08/05 14:45:58
>>221
そうだね、エスケープ解析した結果として、スタックアロケーションしたりインライン化したりするんだね。
違う階層の言葉だったね。
224:デフォルトの名無しさん
07/08/05 14:47:26
if(true)が無視されてバイトコードに埋め込まれないのは、バイトコードの最適化といわないのかな。
225:デフォルトの名無しさん
07/08/05 14:54:08
メソッドに仮実装がある場合で、その処理を通さずメソッドの先頭で値だけ返したい場合とか
if (true) を未到達エラー回避にたまに使うな。C#はboolを変数化しなきゃいけなくて面倒だ。
ああ、まるで脱線した話題だけどね。
226:デフォルトの名無しさん
07/08/05 14:59:07
インライン化はエスケープ解析の結果じゃないけど、まぁいいや。
もうちょっとスレタイトルにふさわしい話題ないの
227:デフォルトの名無しさん
07/08/05 15:02:44
ならクロージャとJAM以外で見所のある機能があれば紹介して。
228:デフォルトの名無しさん
07/08/05 15:03:08
template萌えな私を叱ってください。
229:デフォルトの名無しさん
07/08/05 16:24:56
JITは標準のコンパイル結果に対して最適化するように動くので、
バイトコードへコンパイルするときは、
明らかな最適化が可能なもの意外は何もしないよ。
バイトコードへコンパイルする時に、
Javacが生成しない最適化されたバイトコードを生成すると、
JITは最適化の対象外になるからかえって遅くなる。
Javacを無視してバイトコード生成するのはJikesぐらい
230:デフォルトの名無しさん
07/08/05 16:29:39
ん？javacって最適化方針まで規格化されてるの？
231:デフォルトの名無しさん
07/08/05 16:31:19
規格化なんかされてないでしょ。
特定の実装の話じゃないの？
232:デフォルトの名無しさん
07/08/05 16:33:24
javacが生成しない最適化されたバイトコードって話がどこからでてきたのかがわからん
233:デフォルトの名無しさん
07/08/05 17:44:13
そもそも今のjavaの動的コンパイル技術はJITじゃなくてHotSpotだろ。
>>141
jdkのRhinoはMozillaのRhinoコードが実行できないほどの超絶劣化品。
あれらのエンジン間に互換性はないよ？
Rhinoの実装ライブラリがsun.*パッケージに移動されてるから
Rhinoに含まれるセキュリティーライブラリがどの常に利用できるとも限らんし、
バイトコード吐かないから常にインタプリタモードで動いて遅いし。
E4Xないし。上げ出したら切りがない。
234:デフォルトの名無しさん
07/08/05 21:45:36
>>233
HotSpotは、実行時間食ってる箇所を見つけてJITコンパイルする。
もしくは、あんまし実行されない箇所のJITコンパイルを抑制する。
大雑把な議論をする場合はJITでもHotSpotでもどっちでも良い。
変な拘り持ってる奴を相手にするんでなければ。
235:デフォルトの名無しさん
07/08/05 22:06:34
3回動くとコンパイルが走ると感覚的に判断してるから、
ベンチマーク前は、10回は回してからやってる。
server vmってのは何時間も動かすと更に最適化されたりするんだろうか
236:デフォルトの名無しさん
07/08/06 03:18:49
>>234
でもそれって最適化方法が同じ実装の場合に限られない？
サーバー向けVM製品とかの中にはHotSpotと同じ適応型最適化コンパイルするけどVM実装の都合で
あえて変わったタイミングでコンパイルしたりする奴居るよ。
>変な拘り持ってる奴を相手にするんでなければ。
てのはこいつらのこと？
237:デフォルトの名無しさん
07/08/06 08:15:35
>>235
感覚に頼んじゃなくて -XX:+PrintCompilation とか -Xbatch とか使ったほうがいいと思うけど
238:デフォルトの名無しさん
07/08/06 09:30:04
>>236
一切JITコンパイルしない最適化方法の事をJITって言ってたら
話が通じなくなるから問題だけど、タイミングが変わるぐらいなら問題ないでしょ。
239:デフォルトの名無しさん
07/08/06 11:41:02
>>236
> あえて変わったタイミング
kwsk
240:デフォルトの名無しさん
07/08/06 16:57:02
>>239
たまたま見つけたんで製品名は知らんが
アプリケーションが１度走り出したら負荷のかかるGC/動的コンパイルを
徹底的に発生させないために実行初期にとっとと見切りプロファイルしてマシン語吐いちゃってシステムの稼働を優先させるタイプのVMをどっかで見た。
でも、実行初期段階からボトルネック見つけたりパフォーマンスを平均化する技術を使ってるらしくAOTじゃないみたい。
民生用じゃないVMなんかはそういう変わった実装見るよ。
>JITコンパイルしない最適化方法の事をJITって言ってたら
MEベンダの中にはただのインタプリタ最適化を"独自の"JIT技術と呼んでるところもあるんだなｗ
漁ると結構変なVMっていっぱい。
あと、JITをただの動的コンパイル（OR最適化）のことだと思ってる奴とか。
241:デフォルトの名無しさん
07/08/06 17:00:03
語義的には Just In Timeで何かしてたら、なんでもJITになるわな。
242:デフォルトの名無しさん
07/08/06 17:23:51
JITコンパイラと名乗ってなければ、
> ただのインタプリタ最適化を"独自の"JIT技術と呼んでる
なんの問題もないだろ。
243:デフォルトの名無しさん
07/08/07 15:30:39
JSR-308に関してこんなん見つけた。
URLﾘﾝｸ(pag.csail.mit.edu)
正式リリースからは削除予定だけど、JDK7の開発期間中は暫定的に、
/*@Readonly*/ Object x;
みたいのがあると、アノテーションとして認められるらしいんだけど、
これJDK6以前とJDK7以降で共用のライブラリ書くとき便利だから
言語仕様として残して欲しかったり……
JMLみたいな既存のツールが既に/*@...... */ ってタイプのコメント使ってるので
言語仕様に組み込むのはダメって話らしいんだけど。
244:デフォルトの名無しさん
07/08/08 03:26:00
コメントに書くのは邪道。
245:デフォルトの名無しさん
07/08/08 19:26:13
>>243
そーゆー事やりたいんだったら、JDK7以降用にソースを書いておいて、
Tree API とか使ってアノテーション落とした方が良いかもね。
246:デフォルトの名無しさん
07/08/09 11:58:02
エスケープ解析って、*.javaを解析するのか、*.classを解析するのかどっちなの？
247:デフォルトの名無しさん
07/08/09 12:35:59
>>246
.javaはまず無い。バイトコードにスタックにオブジェクトアロケーション
する命令なんか無いんだから。おそらくバイトコードをJITコンパイルする
段階でエスケープ解析していると思われる。
248:デフォルトの名無しさん
07/08/09 13:00:12
>>243
> @Readonly Object x;
> if (x instanceof Date) { ... } // error: incompatible annotations
> if (x instanceof @Readonly Date) { ... } // OK
> Object y;
> if (y instanceof Date) { ... } // OK
> if (y instanceof @NonNull Date) { ... } // error: incompatible annotations
これ必要なんだろか？ 型アノテーションってインスタンス毎に
ついてるわけじゃなくてerasureなgenericsと同じような扱いでしょ。
こんなん付けても無駄に長くなるだけなんじゃ……
249:デフォルトの名無しさん
07/08/09 13:10:08
エスケープ解析って、
＞バイトコードをJITコンパイルする 段階
の技術だったのか。よくわかった。
ただ、「思われるとか」憶測で語っているのはどうかと。
250:デフォルトの名無しさん
07/08/09 13:32:15
思われなくても、JITコンパイル時の処理です。
251:デフォルトの名無しさん
07/08/09 13:47:33
>>248
if (list instanceof ArrayList<String>) { ... }
とかはコンパイルエラーになるのにな。
一貫性がないっつーか……
252:デフォルトの名無しさん
07/08/09 13:49:34
>>250 よくよくわかった。
253:デフォルトの名無しさん
07/08/09 14:00:37
>>243
なんつーか互換性重視だった 1.5 までと、
どっちかっつーと互換性軽視 機能追加重視の最近の風潮で
ねじれが出てるような気もする。
こんぐらい無節操に機能追加される（予定だ）とプリプロセッサ使いたくなるよな。
>>245 のも発想的にはプリプロセッサだし……
254:デフォルトの名無しさん
07/08/09 14:30:29
アノテーション使わなければ、互換性あるんだからいいんじゃね？
255:デフォルトの名無しさん
07/08/09 14:36:28
どの互換性を軽視だって？
256:デフォルトの名無しさん
07/08/09 14:45:12
>>255
write once compile any version が出来ない、
もしくは無理にやろうとすると、新機能使えなくて不便になるって話。
257:デフォルトの名無しさん
07/08/09 15:03:26
内部でクロージャが使えない、とかは我慢すれば良いとしても
古いバージョンもサポート対象に入ってて JSR-308みたいのが使えないと
新バージョンで使う時に型情報が減るからな。
258:デフォルトの名無しさん
07/08/09 15:22:20
>>256
（ ﾟдﾟ）ﾎﾟｶｰﾝ
259:デフォルトの名無しさん
07/08/09 15:38:30
>>256
まぁ、言語として複数バージョンに対応するための配慮なんかは一切無いな。
#ifdef 使えばソース汚くても複数バージョンに対応できるみたいな救済策もないし。
260:デフォルトの名無しさん
07/08/09 15:39:23
相手に合わせようとするのは、JAVAらしくないな。
逆に、相手がJAVA（JVM）に合わせろってところにJAVAの互換性がある。
261:デフォルトの名無しさん
07/08/09 15:40:54
>>256
クラスワーキング・ツールキット: 古いJVMでJ2SE 5.0の機能を使う
URLﾘﾝｸ(www-06.ibm.com)
JavaのGenericsに関しては、上位互換性(下位互換性ではなく！)を満たすために
Erasure方式で実現したから、コンパイルオプション指定でJDK1.4でも動くはずだが。
262:デフォルトの名無しさん
07/08/09 15:40:54
>>257
まず型ありきの言語で型情報減るのは痛いよな。
263:261
07/08/09 16:02:17
javac -source 1.5 -target 1.4 Test.java
javac: リリース 1.5 のソースにはリリース 1.5 のターゲットが必要です。
と言われてしまった。偽情報スマソ。
一応、Retroweaverを使えば可能なようだが．．．
Retroweaver supports most 1.5 features while running on 1.4.
* generics
* extended for loops
* static imports
* autoboxing/unboxing
* varargs
* enumerations
* annotations
JDK1.4でコンパイルされたライブラリを、
JDK1.5 以降でGenericsなライブラリとして利用するのは可能だよな．．．
というかこれが無理なら何のためのerasure方式採用なんだよって感じだが。
264:デフォルトの名無しさん
07/08/09 16:02:53
>>261
-target jsr14 だっけ？ 文書化されてないんだよね、これ。
265:デフォルトの名無しさん
07/08/09 16:05:35
>>263
> JDK1.4でコンパイルされたライブラリを、
> JDK1.5 以降でGenericsなライブラリとして利用するのは可能だよな．．．
可能っちゃ可能だけど、パラメタ型の情報無いよ
266:デフォルトの名無しさん
07/08/09 16:14:57
>>264
-target jsr14を使うと可能でした。ｔｈｘ。
Java の理論と実践: Java 5 の言語機能を以前の JDK で使う
URLﾘﾝｸ(www-06.ibm.com)
列挙型以外はほぼ問題ないようだ。
267:デフォルトの名無しさん
07/08/09 17:24:49
>>266
JDK5以降のライブラリや、メソッドを使うときに注意。
Autoboxingなどはちゃんと処理される。
268:デフォルトの名無しさん
07/08/10 01:25:21
win32 apiとか触るの面倒だし、だれかjvm上で.netが動くの作ってくれないかな
C＃をインタプリタ実行するのでもいいからさ
269:デフォルトの名無しさん
07/08/10 01:26:53
>>268
それはそれで凄まじいな
……考えてみるか。
270:デフォルトの名無しさん
07/08/10 01:51:45
C# を Java バイトコードにコンパイルする方が楽じゃない？
271:デフォルトの名無しさん
07/08/10 02:08:05
エスケープ解析は、*.javaに対して行っておくほうが実行効率がいいけど、その情報を*.classに残す手段がないので、実行時の最適化でしか使われていない
272:デフォルトの名無しさん
07/08/10 02:12:52
>>249
>>247だが、実際にソースまで追って確認したわけじゃないので
そういう表現になっただけで、JITコンパイル段階でやってるのは
ほぼ間違いないよ。まあ、厳密に言えばインタープリタモードでも
やってる可能性もあるけど、メリットが考えられない。
273:デフォルトの名無しさん
07/08/10 03:03:50
手段がないわけじゃないと思うけど。
stackmapっぽい新しい属性をクラスファイルに追加すればいいんだし。
ただ、静的に解析しても効果が弱いと思う。
メソッドの非仮想化やインライン展開を終えた後にやる方がいい。
274:デフォルトの名無しさん
07/08/10 03:17:31
>>273
それは、メソッドの非仮想化とインライン展開がエスケープ解析に与える影響がすごく大きいってこと？
そうは思えないんだけど。
275:デフォルトの名無しさん
07/08/10 03:46:33
>stackmapっぽい新しい属性をクラスファイルに追加すればいいんだし。
これは上で出てきたstructをJava言語でサポートするんじゃなくて、
JVMでサポートするってのに実質的に近いんじゃないか？
276:デフォルトの名無しさん
07/08/10 03:55:03
>>274
例えばさ、
public Object[] foo()
{
Vector v = makeVector();
v.add("bar");
v.add("hoge");
return v.toArray();
}
public Vector makeVector()
{
return new Vector();
}
みたいなコードがあったとするじゃない。 (例がやや作為的だけど、そこは目を瞑っていただきたい。)
いっけん v は foo の外にエスケープしてないように見えるけど、add とか toArray とかの中で this をどこかの static 変数に保存しているかもしれない。
誰も Vector クラスのソースを見たことあるわけじゃないし (あるかもしれないが)、 Vector がそういう変な実装になってないとは断言できまい？
そういうわけで、この時点では v をスタック上にアロケートしてしまうわけにはいかない。
(this をどこかの static 変数に保存したりできなくなってしまう。スタックは foo を抜けたら消滅するんだし。)
でも add とか toArray とか makeVector とか Vector コンストラクタを全部インライン展開できれば、v が foo の外にエスケープしてないかどうかがはっきりする。
エスケープしてないと判れば、もう別に Vector を new する必要なんかなくなって、 Vector の全フィールドをみんなスタック上に展開してしまえる。
makeVector は final じゃないから実はオーバーライドされてて他のクラスを返してるかもしれないが、これも非仮想化されてればインライン展開できる。
・・・って思ってるんだけど、現実のJVMがどこまでやってるかは知らない (´･ω･`)
277:デフォルトの名無しさん
07/08/10 04:44:16
>win32 apiとか触るの面倒だし
ここらへんあるから実質C#はマルチプラットフォームじゃないよね。
278:デフォルトの名無しさん
07/08/10 09:53:41
>win32 apiとか触るの面倒だし
それだけだったら、win32 api を触らなくて済むようなGUIフレームワークとかを使えばいいだけと違うん？
279:デフォルトの名無しさん
07/08/10 09:56:34
>>273
> ただ、静的に解析しても効果が弱いと思う。
> メソッドの非仮想化やインライン展開を終えた後にやる方がいい。
二行目は静的/動的と関係ないじゃん。
280:278
07/08/10 09:57:41
って、.C# か・・・ じゃあ GTK# とか・・・ びみょかな・・・
281:デフォルトの名無しさん
07/08/10 11:35:35
>>279
静的に＝.javaのコンパイル時にって意味で書きました
.javaコンパイル時に非仮想化・インライン展開とかできないでしょ
わかりにくくてごめんなさいね
この暑さでちょっと疲れてるんだ
282:デフォルトの名無しさん
07/08/10 11:49:09
出来ないことないじゃん。もうInner classあるんだから。
283:デフォルトの名無しさん
07/08/10 11:54:25
Inner class って、なんか関係が？
284:デフォルトの名無しさん
07/08/10 11:59:12
インナー・クラスの非仮想化・インライン展開はソース・コンパイル時に出来る。
285:デフォルトの名無しさん
07/08/10 12:21:17
--- Outer.java ---
public class Outer {
class Inner {
int foo( ) { return 1; }
}
void bar( Inner inner ) {
System.out.println( inner.foo( ) );
}
}
インナークラスってこういうのでしょ。
inner.foo( ) をインライン展開するつもり？
--- Main.java ---
public class Main {
public static void main( String[] args ) {
Outer outer = new Outer( );
Outer.Inner inner = outer.new Inner( ) {
int foo( ) { return 2; }
};
outer.bar( inner ); // → 2 を出力する
}
}
286:デフォルトの名無しさん
07/08/10 12:42:11
そもそもprivate:ならインライン展開し放題じゃない。
287:デフォルトの名無しさん
07/08/10 12:45:06
それはまぁね。
288:デフォルトの名無しさん
07/08/10 17:18:14
で、実際デフォルトで（知らないところで）インライン展開はされているのか？
それも、メモリ上に展開なのか、ソースコード（.class）のバイト数が増加しているのか。
289:デフォルトの名無しさん
07/08/10 17:20:42
> で、実際デフォルトで
（ ﾟдﾟ）ﾎﾟｶｰﾝ
290:デフォルトの名無しさん
07/08/10 17:45:00
はいはい、あげあし君はさようならで
291:デフォルトの名無しさん
07/08/10 17:58:23
似たようなことを議論してるよ。
stack allocateについては、
アノテーションで指示するか、
ByteBufferでアドレッシングしてくれってことのようだ。
URLﾘﾝｸ(bugs.sun.com)
292:デフォルトの名無しさん
07/08/10 18:31:07
>>291
そこの議論の対象はC/C++の struct で作られたような
データ構造にアクセスする事であって、
言語仕様的に stack allocated object が欲しい場合は
URLﾘﾝｸ(bugs.sun.com)
URLﾘﾝｸ(bugs.sun.com)
どっちかにvoteしろって書いてあるよ
293:デフォルトの名無しさん
07/08/10 18:35:28
C# だと各メンバに FieldOffset が指定できるよね
>>291 はそういう話じゃないの？
294:デフォルトの名無しさん
07/08/10 18:54:29
>>292
で、君はそっちのREFをチェックしてからものを言ってるわけなのかな？
>>293
C#がどうしたって？
ざっとみてスタックがどうとか言う議論になってたから似たようなの出してみたのだけど。
295:デフォルトの名無しさん
07/08/10 19:02:35
いや、データをバイト列にパックする話とスタックアロケーションは別の問題だから。
296:デフォルトの名無しさん
07/08/11 03:07:02
君の都合にあわないからといって、いちいち相手にｹﾁをつけるところは君の悪い癖だな
297:デフォルトの名無しさん
07/08/11 16:11:19
なあ、全員「デフォルトの名無しさん」じゃねえか
同一人物間でケンカ自演してるのってどうよ
って突っ込んでるオレも同一人物な訳だが
298:デフォルトの名無しさん
07/08/11 16:22:00
夏休み的なツッコミだな
299:デフォルトの名無しさん
07/08/11 19:00:47
ボケだろ、ボケ
300:デフォルトの名無しさん
07/08/13 15:24:33
ノリツッコミか
301:デフォルトの名無しさん
07/08/18 04:47:25
JDK7 build18
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)
細かいバグ修正とか。
302:デフォルトの名無しさん
07/08/19 07:15:13
java LnFっていずれocanからSwing new LnFと謳ってるNimbusになるのかね？
303:デフォルトの名無しさん
07/08/19 08:19:46
Nimbusはスクロールバーがヤだ
304:デフォルトの名無しさん
07/08/19 15:38:42
確かにへぼいな
305:デフォルトの名無しさん
07/08/19 16:52:27
javaのスレでC#の話をするなボケども
306:デフォルトの名無しさん
07/08/19 17:31:28
JSR 310ってどうよ
307:デフォルトの名無しさん
07/08/19 19:22:01
>>302
Nimbusはごっつい雰囲気が強すぎて微妙ー
Aquaとかみたいな甘いデザインにしてくれと思う。
>>306
各所のブログでJSR 310は入れてほしくないと言われているな。
どうなんだろう・・・
308:デフォルトの名無しさん
07/08/19 19:34:49
使うことはあまりないだろうな。
309:デフォルトの名無しさん
07/08/19 20:46:56
>>306
オレは JSR-310 スライドに入ってる
> What's wrong with Date?
> ・Uses two digit years from 1900
> ・January is 0, December is 11
のセンスを見て、なんだかなー と思った。
この辺って、たぶん Cの標準ライブラリの
struct tm と同じ方式になってるだけでしょ。
きちんと文書化してあれば大して問題になるとも思えんし……
310:デフォルトの名無しさん
07/08/19 21:28:31
>>306
URLﾘﾝｸ(jsr-310.dev.java.net)
311:デフォルトの名無しさん
07/08/20 17:49:33
>>309
いや、正直、1月が0とかは文章にしていてもあり得ない。
使うたびにAPIをその仕様で設計したヤツに殺意を覚える。
ライブラリの使い方からCと違うんだから中途半端にわかりにくくしてるだけ。
312:デフォルトの名無しさん
07/08/20 18:02:22
文章化してあるから問題なしって・・・
313:デフォルトの名無しさん
07/08/20 18:56:22
>>311
分かりにくいっても、C言語使った事あれば1月が0になる事もあるってのは予測可能だし。
不勉強な上に不注意な連中が躓く原因であるのは確かだろうけど、
たぶん、そういう連中は 月フィールドが 1オリジンになったら Calendar と互換性なくなって躓くだろう。
ゼロから新しいAPIを作るならともかく、既存の Calendar と共存するつもりなら、
新しいクラスを作って、そのクラスの月フィールドを 1オリジンにしたぐらいじゃ幸せにはなれない。
314:デフォルトの名無しさん
07/08/20 19:37:12
>>311
まぁ有り得ないとか殺意を覚えるってのは程度の差だからなんとも言えんけど。
オレとしては 1月を 1 にしたければ、とりあえずユーティリティメソッド1つ作れば良いと思うんだわ。
で、オレの感覚からすれば、ユーティリティメソッド1つで解決するような問題を掲げて
わざわざ新API作ろうって感覚の方が有り得ないんだわ。
スライド見て感じた事ってのはそーゆー事。
315:デフォルトの名無しさん
07/08/20 19:43:10
今から新しく作るんなら、enumにすればいいんじゃまいか。
public enum Month { JANUARY, FEBRUARY, ... }
316:デフォルトの名無しさん
07/08/20 21:05:04
そして旧暦閏月で困ると。
317:デフォルトの名無しさん
07/08/20 21:21:43
閏月対応してるクラスってあったっけか？
318:デフォルトの名無しさん
07/08/20 23:19:30
Timeの方は刹那とかに対応しないかなと思ってみたりｗ
10^-18なんて精度表せないだろうが。単位として扱えたら面白そう。
319:デフォルトの名無しさん
07/08/20 23:25:25
誰が使うんだ、そんなもん……
320:デフォルトの名無しさん
07/08/20 23:41:02
ナノ時間取得はコストが高すぎるんだよな・・・
321:デフォルトの名無しさん
07/08/21 01:23:50
>>319
坊さん用ソフト開発なプログラマｗ
24時間=30牟呼栗多=900臘縛=54,000怛刹那=6,480,000刹那という変換するとか。
スウォッチインターネットタイムも欲しいな。
322:デフォルトの名無しさん
07/08/21 01:33:32
坊さん用なら卒塔婆プリンタの方が喜ばれそうだが。
っつか、Wikipedia漁って適当な事言ってるだけじゃね？
323:デフォルトの名無しさん
07/08/21 08:50:41
URLﾘﾝｸ(www.atmarkit.co.jp)
同じくフォーチュン1000企業のWebサイトを対象とした調査で、
アプリケーションサーバのシェアはASP/ASP.NETがトップで51.5％のシェアと2年前から7.9ポイントの上昇。
J2EE、JSP、WebLogic、WebSphere、TomCatなどのJavaプラットフォームが2位で12.7％。
そのほか、PHP（6％）、ColdFusion（3.2％）、Perl（1.9％）、Python（0.2％）などとなっている。
とりあえず、ASP.NETの普及が断トツに進んでいる。
Javaは新規プロジェクトで採用される可能性はほとんどなくなってきてるしな。
324:デフォルトの名無しさん
07/08/21 09:53:51
そろそろJava終了のアナウンスがSunからあるのかな
まぁいい思い出になったよ
325:デフォルトの名無しさん
07/08/21 10:20:43
>>323
ASPとASP.NET合計で51.5％か。意外に低シェアだな。
>>324
Sunあぼーんして、IBM & Google が実権を握ってくれる方が嬉しいなぁ。
326:デフォルトの名無しさん
07/08/21 10:23:58
>>315
一応、Calendar.JANUARYとか定数ならあるよ。
そっち使うでしょ普通。
327:デフォルトの名無しさん
07/08/21 10:24:54
あ、そっち使うでしょ、ってのは0とか1とかじゃなくて、って意味。
enumならなおよろしいけど、互換の問題がねぇ・・・。
328:デフォルトの名無しさん
07/08/21 13:37:56
>>327
日付扱うときは、だいたいユーザー入力だから無意味。
プログラム中でJANUARYとか指定することなんてあまりないんじゃね？
329:デフォルトの名無しさん
07/08/21 16:31:57
ユーザー入力を文字列として持ち回すと難儀だよね。
でも、WEBアプリにしろSwingにしろ、フレームワークとか
日付入力コンポーネントとかでDate型で最初から
扱える奴あるし、今時大概そうじゃないのかな。
プログラムの中で月決め打ちってのは確かにあまりないですね。
テストコードくらいか。
330:デフォルトの名無しさん
07/08/21 17:51:54
>>314
いや、ラッパークラスを用意すればいいってのはユーザ側の対応になる。
それはつまり、現状のDate型の変更に依存する訳だし
自分が書いたコードはラッパークラスを必ず含まなくてはならなくなる。
それならコアAPIに入っててくれよ、と思わないか？
今のDate型の実装だと、実装者自身が作り直したいと考えても
仕方がないような作りが多々ある。Calendarを追加して手当したけど
時間、日時を扱う場面は多くある。
これだけJavaが使われてその問題点が明らかになったんだから
新しくより合理的なAPIができてもいいと思う。
言うなればJava3とでもいうものへのへの緩やかな変化。
基本的なモノだからこそ改良が重要になってくるとは思うんだ。
アトは失敗しないようにしっかりと作ろうってところだろうか。
331:デフォルトの名無しさん
07/08/21 18:15:12
Calendarいらないってがんばっている人もいる。
URLﾘﾝｸ(d.hatena.ne.jp)
URLﾘﾝｸ(d.hatena.ne.jp)
これが本当に通ってくれれば
憂いなしで嬉しいな。
332:デフォルトの名無しさん
07/08/21 18:29:39
つか、きしださんまで月間違ってるし！
333:デフォルトの名無しさん
07/08/21 19:05:53
>>330
ラッパークラスで解決しようというのはダメだろ。
Calendar の set やら get を ラップして 1月が1になるようにしても、
自分の目の届く範囲だけなら構わないけど、
第三者が作ったクラスに渡す場合には、そのまま渡したら 1ヶ月ずれる。
そんなゴミをコアAPIに入れられたら、 Calendar をやり取りする
メソッド作る場合に、必ず instanceof とかでチェックしなきゃいけなくなる。
334:デフォルトの名無しさん
07/08/21 19:08:21
>>331
無理じゃね？
java.util.Date は Serializeable だし、
Date の TimeZone対応とかやったら、
シリアライズされたデータの互換性なくなるんじゃないか？
335:デフォルトの名無しさん
07/08/21 19:10:30
W3C-DateTimeからRFC2822-DateTimeに用意に変換できるようなものが欲しい。
RFCのほうはCWFSのおかげでやたらパースがしにくい。
336:デフォルトの名無しさん
07/08/21 19:23:34
>>330
> これだけJavaが使われてその問題点が明らかになったんだから
> 新しくより合理的なAPIができてもいいと思う。
あっても良いけど、closure とかに比べると優先度は低いよね。
それに「問題点」ってのも個人個人で違うわけで、1月 が 0 なのがダメなのか、
setter の戻り値の型が void だから、1行に詰め込んで書けないのが問題なのか
それ以外なのか。
現状では愚痴とか不満は出てるけど、
それらを一つに纏めて、多くの人が納得でき、多くの人が幸せになれるような
解決策が提示されているかっていうと、少なくとも JSR-310 は違うと思う。
337:デフォルトの名無しさん
07/08/21 20:22:16
>>335
まえにjavascriptの実装がどっかのブログで公開されてたぞｗ
338:デフォルトの名無しさん
07/08/21 22:16:24
>>336
いや、JSR-310はまだ固まってないし。
そういう動きがある、ということしか言えないと思う。
なんで、これからの頑張り次第でしょ、という話。
それとも、「日付関係の新しいAPIは要らないぜ」という話？
339:デフォルトの名無しさん
07/08/21 23:24:14
>>338
1月が 1 と書けるようになっただけ、の Calendar みたいなクラス作られても
あっちのフレームワークでは互換性のために旧Calendar要求され、
こっちのフレームワークでは機能性のために新API要求され、
みたいに手間が増えるだけになる可能性が高い。
かと言って、Calendar が解決しなかったニッチな要求のためだけのAPI作ったら
わざわざ標準APIに突っ込む必要ないって話にもなるし。
既存のDate＆Calendarがある状況で
日付関係の新しいAPIを作るのは凄く難しいと思ってるんだけど、
1月が 0 なのがキモイみたいな事かかれると、
マトモなものが出来るのか心配になるって話。
340:デフォルトの名無しさん
07/08/21 23:27:03
動画再生用のSwingコンポーネントが標準化されたりしたら嬉しいのだけど、
JavaFX Scriptに合わせて対応してくれたりせんのかねぇ。
Flashは次のバージョンでH.264にも対応するとか発表してるし、
本気でRIA市場に乗り込むならここらへんを抑えてくれないと支持しにくい。
341:デフォルトの名無しさん
07/08/21 23:36:53
つ JMF
342:デフォルトの名無しさん
07/08/21 23:38:58
JRE以外にインスコしてもらえるわけないじゃんｗ
343:デフォルトの名無しさん
07/08/21 23:51:58
jarに全部突っ込んでマニフェストでパス指定するか。JWSでいいだろ。
けどJMFのH.264コーデックがまだIBMのプロプラライセンスものしかなかった気がする。
344:デフォルトの名無しさん
07/08/22 09:04:57
>>339
相互変換はコンストラクタ一発なんだから問題ないんじゃね？
345:デフォルトの名無しさん
07/08/22 09:09:49
SilverlightやFlashに比べて、JREはインストール面で不利すぎる気がするのですが
軽量プラグインとか出す予定はないのでしょうか？
346:デフォルトの名無しさん
07/08/22 09:24:14
何を削るかで揉める事必至だろうなぁ・・・
いっそのことJ2MEのランタイムを作ってそれを軽量プラグインにするとか
347:デフォルトの名無しさん
07/08/22 11:31:10
分割ロードの方が良さそうだなあ。
Javascriptは何でも一つのファイルにぶち込むのが流行ってきているけれども。
348:デフォルトの名無しさん
07/08/22 14:09:41
>>345
Java Kernel と呼ばれているものを jdk6 update 4 で出す予定
URLﾘﾝｸ(weblogs.java.net)
URLﾘﾝｸ(weblogs.java.net)
349:デフォルトの名無しさん
07/08/22 14:24:44
>>344
Date と Calendar はコンストラクタ一発で変換できてないじゃん。
それと同じ事が起こる事は十分予測可能。
350:デフォルトの名無しさん
07/08/22 14:30:23
>>349
っつーか、コンストラクタ一発で変換できても煩雑なのは変わらんのだがな。
351:デフォルトの名無しさん
07/08/22 20:01:17
”よく知られた日付型”がこれ以上混在されてもうざいだけだよ。
DateにCalendarにsql.Dateと、”よく知られた日付型”は、もう既に食傷気味です。
所詮は64bit unix epocと割り切ったユーティリティメソッドが拡充される方がよほど嬉しい。
352:デフォルトの名無しさん
07/08/22 21:21:02
なるほど。
良くあるパターンに特化したユーティリティメソッドを用意してくれる方が
ありがたい気がする。
353:デフォルトの名無しさん
07/08/22 21:49:03
JREのインスコなんてウィザードに従えば良いだけだろ。
それより、システム管理全体がside by sideへ以降してきてメンテにエンドユーザーの負担が掛かってると思う。
354:デフォルトの名無しさん
07/08/23 01:19:58
JSR 310はいいと思う。
ユーティリティ・クラスとしても上出来。
355:デフォルトの名無しさん
07/08/23 03:08:43
>>354
そうなん？
>>310 に JSR-310 のAPIリファ来てるけど、
これどんな時に便利なのかサンプルコードとか書いてくれん？
っつか、オレには Moment や Period のサブクラスが
年、月、日、時、分、秒と分かれてる必要性がイマイチわからん。
356:デフォルトの名無しさん
07/08/23 04:03:13
タイムベースの処理が必要でそのフレームワークを自前で作らなきゃいけないときに下のライブラリとして使えそうだな。
357:デフォルトの名無しさん
07/08/23 04:06:51
>>310がJSR-310のリンクになっていることに
今になってようやく気が付いた。
なんか黄色ナンバーの車を1日10台見たとか
ワーゲン見たとかその程度にちょっと幸せ。
358:デフォルトの名無しさん
07/08/23 08:11:21
>>355
ぶっちゃけ、>>310より>>331の方が良いと思う……
359:デフォルトの名無しさん
07/08/23 08:43:24
>>356
逆に言うと、それ以外の目的に使えなさそうじゃね？
360:デフォルトの名無しさん
07/08/23 08:46:22
どっちがいいとかそういうもんじゃないだろ。
310はベースとなる時刻クラスを提供するんだから。
361:デフォルトの名無しさん
07/08/23 08:49:25
今のままだったら Date ＆ Calendar の方が下位層で
JSR-310 はそれに乗っかるだけの上位層になりそうだが
362:デフォルトの名無しさん
07/08/23 08:50:20
（ ﾟдﾟ）ﾎﾟｶｰﾝ
363:デフォルトの名無しさん
07/08/23 08:52:26
おまけに使用用途が酷く限定されている、と。
364:デフォルトの名無しさん
07/08/23 09:01:34
>>360
んじゃ言い直そう。
JSR-310 のスライドにあがってる、
What is wrong with Date and Calendar?
の解決策としては、今のところ>>331の方が良さそうに見える。Date の
Could not be successfully localized とか Most methods deprecated、
SimpleDateFormat の Calendar cannot be directly formatted
は解決できそうだ。
365:デフォルトの名無しさん
07/08/23 09:25:39
>>360
310が提供するベースとなる時刻クラスってどれよ？
366:デフォルトの名無しさん
07/08/23 11:36:39
文字列からのファクトリメソッドは、
別クラスにした方がいいんじゃないの？
L10N考えると劇重プロジェクトだし。
GNU dateコマンドみたいな時間指示を考えると、やること一杯ある。
367:デフォルトの名無しさん
07/08/23 11:46:17
これはひどい
ベースとなる時刻クラス・・・ Instant かねぇ
でも CalendarDay や TimeOfDay との相互変換はできそうになく
既存の Date や Calendar との繋がりもない
どうやって使うんだこれ
368:デフォルトの名無しさん
07/08/24 00:25:02
310はまだ、かなりドラフトな感じだが、
PeriodとMomentとその実装クラスを細かく分けるのは、
安全でかつ読みやすくなるのでよいと思う
例えばMomentにMomentは追加できないがPeriodは追加できるとか
369:デフォルトの名無しさん
07/08/24 01:23:17
Instant と fully defined な SingleMoment を区別する理由と、
Period と Interval を区別する必要とか、
Duration とか良く分からん。
Duration と Inteval はまだ出来てないみたいだけど。
>>368 も同意っちゃ同意なんだけど、
それって Moment と Period が別になってる理由にはなっても、
Moment や Period のサブクラスが 年、月、日、時、分、秒と
細かく分かれてる理由にはならんよね。
370:デフォルトの名無しさん
07/08/24 01:58:25
>> 369
>Moment や Period のサブクラスが 年、月、日、時、分、秒と
>細かく分かれてる理由にはならんよね。
なんで?
Days days = ...;
days = days.plus(Days.days(3));
とか具体的な型が決まっていたら安全かつ読みやすいじゃん。
しかしメーリングリストだとなんかいろいろ提案とか出されたり、まだまだな感じがしてきた。
sunの中の人が書いてるが、
URLﾘﾝｸ(blogs.sun.com)
既存のAPIとの互換性とか国際化も考えると大変そうだね。
371:デフォルトの名無しさん
07/08/24 02:02:32
>>369
後者については type safe のためとか？
もしくは、
Moment moment = build(dayOfMonth(1), hourOfDay(3));
とかやると、毎月 1日午前 3時 をあらわすようになるとか……
372:デフォルトの名無しさん
07/08/24 02:05:26
>>370
おいおい……
一見型安全かもしれないけど、
それだけだと、逆に Period で 1カ月と3日とか複合的な指定できなくなるんですけど……
373:デフォルトの名無しさん
07/08/24 02:10:03
>>371
あぁなるほど。可変長引数のビルダーメソッドで纏めるとか
そーゆー場合には別々のクラスになってないとダメだな。
>>370
これはひどい
374:デフォルトの名無しさん
07/08/24 02:34:16
>>372
Periodとしての一ヶ月というのは日数として組み合わせて扱えない気がするが。
375:デフォルトの名無しさん
07/08/24 02:37:46
（ ﾟдﾟ）ﾎﾟｶｰﾝ
376:374
07/08/24 02:48:29
今のAPIを見る限り、複数のPeriodを組み合わせたPeriodというのはない気がする。
Monthsに関しては月によって日数は変わるので、months.plus(Days.days(3))みたいな計算は書けないと思うが。
しかしCalendarDayはplus(Period...)というのを持ってるので、一ヶ月と3日後とかを計算できると思う。ただMinutesとSecondsとの変換とかできそうな気がするのにできないように見えるのはよくわからない。
377:デフォルトの名無しさん
07/08/24 02:51:08
>>372
そーゆーのは、まだない Interval でやるって話なんじゃね？
しっかし、凄く分かりにくい API だな、これ。
そこそこ経験がある奴でもサンプルコードが無いと一行も書けないぞ。
378:デフォルトの名無しさん
07/08/24 02:55:09
>>373
instanceof で比較するところを enum と switch で置き換えれば
良いだけだから、別々のクラスになってる必要は全くなかったりする。
379:374
07/08/24 03:03:40
やっぱりわかりにくいのだろうか?
変換とかファクトリとかのメソッドがどこにあるかわからず、分かりにくい、というのはあるかもしれないが、
そもそも日付と時間の長さなどを区別して扱うこと自体が複雑で、結局intとかで扱っても値の種類を把握していないといけないのでは。
ある程度、単位を型でエンコードして分かりやすくすることで安全で読みやすいコードになる方がよいと思うのだが...
380:デフォルトの名無しさん
07/08/24 05:59:11
Sun が NASDAQ での銘柄記号を SUNW から JAVA にかえるんだそうな。
URLﾘﾝｸ(blogs.sun.com)
URLﾘﾝｸ(blogs.sun.com)
いや、次世代Javaと関係ないけど。
っつーか、これジョークじゃないの？ 4月1日じゃないけどさ。
381:デフォルトの名無しさん
07/08/24 07:09:27
Dateみたいな基本的なところに今から手を入れるのがアリなら、
Numberもどうにかしてくれんかな。
やっぱり Integer inherits Double であってほしいし、BigDecimalで
持っている四則演算メソッドはNumberすべてで使いたいが。
382:デフォルトの名無しさん
07/08/24 07:17:34
>>380
JAVAの株があがったとか下がったとかが問題になってくるわけか。
そしたら、JAVAと大文字で書くやつはJavaのことを知らないという伝説が強くなるわけだ。
383:デフォルトの名無しさん
07/08/24 07:43:01
>>381
Numerics関係は難しいんだよな、後からいじるの。
非互換の影響が大きすぎて。
仕様お目付け役だった、Guy Steeleさん、この辺が弱い。
384:デフォルトの名無しさん
07/08/24 16:04:46
元がSUNWならJAVAWにすればいいのにコンソール出ないし・・・。
385:デフォルトの名無しさん
07/08/24 16:57:17
>>381
メソッド追加はありでも継承関係は変えられないだろうな
386:デフォルトの名無しさん
07/08/29 21:26:22
そろそろ deprecated のクラスやメソッドを一掃してほしい
387:デフォルトの名無しさん
07/08/29 22:30:24
Cloneable を Clonable に直してほしい
388:デフォルトの名無しさん
07/08/30 02:13:33
creat....
389:デフォルトの名無しさん
07/08/30 23:47:25
catch必須例外を堂々と無視できるプラグマを追加してほしい。
390:デフォルトの名無しさん
07/08/31 03:25:48
アホか例外処理の意味ないだろ。
握り潰すことすら面倒くさいか？ｗ
391:デフォルトの名無しさん
07/08/31 12:32:21
JDK7 build19
URLﾘﾝｸ(www.java.net)
URLﾘﾝｸ(download.java.net)
forumで話題になっていた
4811096 Allow mixing of heavy and lightweight components
が入った様子。
SwingとAWT混ぜるなっていうのが古い話になるわけだ。
あと、レポジトリ管理、Teamwareを完全撤廃？SCCSキーワードの削除ってのが結構あった。
公開してるのも、Subversionでだしね。OpenSolarisで採用してる、Mercurialはないんだろうか？
392:デフォルトの名無しさん
07/08/31 21:15:56
>>390
めんどくさい。
どうでもいいコンソールプログラム書くときは
全部例外がトップレベルに流れて死んでくれていい。
あと、どうせならインタフェースの実装も堂々と無視できるプラグマも欲しい。
適当にnullとか0とかfalseとか、あるいはNotImplementedException投げるとか。
IDEにやらせればいいんだけどさ。
393:デフォルトの名無しさん
07/08/31 21:52:53
>>392
お前はCの方が合ってるんじゃないか？
つーかその程度の捨てアプリならスクリプトで実装すれば良いだけじゃん。
394:デフォルトの名無しさん
07/08/31 22:32:46
mainメソッドにthrows ExceptionってすればOK
395:デフォルトの名無しさん
07/09/01 02:07:00
Javaの例外処理の面倒くささはMatzがどっかで言及してたね
396:デフォルトの名無しさん
07/09/01 02:21:10
silentClose(Closeable) みたいなメソッド作るとか
使い捨てアプリ作る時は throws Exception つけるとかすれば
そこそこ改善すると思うんだけどね
397:デフォルトの名無しさん
07/09/01 02:29:38
>>395
むしろその例外処理の面倒さがないからこそ
他の言語があぶなっかしくて使えない。
コード品質重視だと特に。
398:デフォルトの名無しさん
07/09/01 06:37:06
むしろ投げる例外をdoc,code上で明文化されてないと何拾って良いか分からないだろ。拾えないと例外に対処できない。
throw,throwsでthrowable以外が飛んでくるのもおかしいし。
399:デフォルトの名無しさん
07/09/01 16:45:03
ExceptionはThrowableである。以上。
400:デフォルトの名無しさん
07/09/02 09:52:45
例外処理の仕組みが問題というよりも
IOExceptionとかSQLExceptionのようなレベルの例外を
チェック例外にしてるのが問題だと思う
SpringやS2やHibernateなら、これらの例外をランタイム例外にラップしてくれるし
JavaEE5ではランタイム例外を多用してるけど
肝心の、JavaSEのコアなAPIがチェック例外だらけだからな
>>397
現実には、Javaのチェック例外記述のめんどくささに嫌気がさした開発者が
catch (Exception e) {
e.printStackTrace();
}
とか書いて、返って品質悪化するパターンの方が高い気がするorz
401:デフォルトの名無しさん
07/09/02 11:41:41
あと InterruptedException も握りつぶされて困りやすいチェック例外だ
あー
InterruptedIOException とか、きっと知らんうちに IOException もろとも握りつぶしてる気がしてきた
try {
......
} catch (InterruptedIOException e) {
Thread.currentThread.interrupt();
} catch (IOException e) {
......
}
なんて、書いた覚えがないよ
402:デフォルトの名無しさん
07/09/02 11:50:49
例外のためのEffective Javaみたいなのがあれば読んでみたい。
こういうのはお習字の世界だから仕様としてどうこう変えるもんでもないし。
403:デフォルトの名無しさん
07/09/02 13:29:09
>>400
IOExcepotionとかは>>396みたいなメソッドがあれば解決する問題
後半に関して言えば
そーゆー奴は面倒くさいので例外処理しないし
他人のために必要な例外関連のドキュメントも書かない
ので検査例外をあってもなくてもそれほど品質は変化しないと思うが
404:デフォルトの名無しさん
07/09/02 13:39:45
何が言いたいのやら・・・必死なことだけは解るが
405:デフォルトの名無しさん
07/09/02 13:48:59
IOExceptionやSQLExceptionがチェック例外なのは当然だろ？
外部リソースに依存してんだから、チェックし無い方がどうかしてる。
DAOならそれらをcauseにして、DAOExceptionみたいに新たなチェック例外にくるむがよろし。
406:デフォルトの名無しさん
07/09/02 13:55:57
closeが例外なげるバカなAPI
407:デフォルトの名無しさん
07/09/02 14:04:03
close は flush を伴うからエラーが発生する可能性はある
408:デフォルトの名無しさん
07/09/02 14:07:19
closeが例外なげるのがバカってどんだけゆとり脳なんだ
409:デフォルトの名無しさん
07/09/02 14:14:18
思うに、チェック例外をキャッチしないと
警告出すだけの仕様だったらどうなっていただろうか？
410:デフォルトの名無しさん
07/09/02 14:26:33
throws SQLException って書いてないのに throw new SQLException() するような
混ぜるな危険メソッドが書き放題で検査例外の意味がなくなる。
それでいてソースに SuppressWarnings("ignorecheckedexception") とか
コンパイル時に -ignorecheckedexception とか必須だと手間がかかるだけ。
中途半端で役に立たないソリューションの見本だな。
411:デフォルトの名無しさん
07/09/02 14:30:17
んなもんソースレビューで片付けろよ
412:デフォルトの名無しさん
07/09/02 14:44:28
closeが検査例外を投げるバカなAPI
413:デフォルトの名無しさん
07/09/02 14:49:51
>>411
第三者の作ったライブラリやフレームワーク使う時は
それらも全部ソースレビューすんの？
414:デフォルトの名無しさん
07/09/02 14:51:10
必ずソースが見れるとは限らんし
415:デフォルトの名無しさん
07/09/02 15:05:42
>>405
IOExceptionとかって多くの場合リカバリできるの?
リソースの解放はfinallyでやるからチェック付き例外とは関係ないと思うし
なるべく例外がチェックできるべきだという意見は多い様に見えるが、一般的にそれらの例外がほとんどリカバリできる処理を書けないならば >>400の言うようにAPIの設計の問題では?
416:デフォルトの名無しさん
07/09/02 15:10:27
ソケット使って読み書きしてる時にIOExceptionが発生したらリトライするとかあるよね
417:デフォルトの名無しさん
07/09/02 15:53:29
>>416
そういう特定の事情のために、すべてのIO処理で面倒なコードを書かないといけないのはアホ
418:デフォルトの名無しさん
07/09/02 15:56:09
というか、例外が出ないコードで例外の補足が必要になるのが、設計ミス
System.in.read()
とか
419:デフォルトの名無しさん
07/09/02 15:57:17
面倒っても、throws IOException を宣言するくらいのもの。
その場で対処しない例外は上へ送る。
420:デフォルトの名無しさん
07/09/02 16:02:53
System.in.read() ってプラットフォーム側の標準入出力の実装方法によっては
例外が出る可能性があるんだが
421:デフォルトの名無しさん
07/09/02 16:10:33
俺としてはNumberFormatExceptionが実行時例外なのが許せないくらいなんだが。
外側のことは一切信用しないという性悪説プログラミングが心情だとね。
422:デフォルトの名無しさん
07/09/02 16:18:48
俺はUserTransactionのメソッドを使ってみたとき、
Javaのチェック例外は、API側が使い方を根本的に間違ってると痛感したよｗ
423:デフォルトの名無しさん
07/09/02 16:24:01
>>412みたいな事を言う奴から間違ってると言われても
424:デフォルトの名無しさん
07/09/02 16:31:07
>>419
それで上へ送った例外は結局どうなるわけ?
throws IOExceptionをまき散らして、
RuntimeExceptionになるか握りつぶされるぐらいじゃないの?
>>421
一切信用しないというのはいいが、それはどうやって処理される?
他の値で代用するのは多くの場合問題がある気がするし、
再度入力を促すことになると思うが、
可能な場合と不可能な場合(処理を中断するしかない場合)があると思う
...NumberFormatExceptionに関しては微妙な気がしてきた
RuntimeExceptionでよい場合も多いと思うが...
425:デフォルトの名無しさん
07/09/02 16:54:22
最近じゃ例外もAOPで処理するし、リソースはfinallyで閉じるからあまり関係ないしな
matz氏がブログで、例外をぎりぎりまで捕捉しないのがRuby流って書いてたけど
結局はそれがいちばん効率的で、開発者に都度catch処理を強制するよりも品質が上がるんだよね。
例外処理がなくても、異常終了で落ちるからテスト時にすぐわかるが、
catchで不用意に握りつぶされた例外はやっかいだし
426:デフォルトの名無しさん
07/09/02 17:06:07
何層か下のフレームワーク/ライブラリが投げてくる実装依存の例外もやっかいだけどな。
面倒くさいから検査例外は無い方が良いとか考えてる奴は、
例外関連のドキュメントなんて書かないから品質ズタボロのコードを量産する。
427:424
07/09/02 17:27:46
>>425
アプリケーション(基本的なライブラリでない)でのチェック付き例外は有用と見られているはずだ
アプリケーションレベルではリカバするべき例外を決めることができて、チェック付き例外で強制できる
アスペクトを使うことでIO例外をアプリの例外へ変換とかはうまく書けるが、
各メソッドごとの例外処理を常にうまく分離して書けるわけではない
テスト時にすぐわかるというのは理由にならないはずだ
再現が難しい例外だってあるから
それよりも発生したときなにもできないことが多いというのが理由だと思う
428:デフォルトの名無しさん
07/09/02 17:28:11
なんか次世代関係なくなってね？
JAVAの例外について勉強するスレとかたててそっちでやれ
429:デフォルトの名無しさん
07/09/02 18:30:35
例外処理が煩わしいのであれば、
例外処理を包含したテンプレートパターンを適用して処理すればいい。
APIは面倒か面倒じゃないかではなく、安全か安全ではないかが重要。
APIは極力安全に使えるように「馬鹿向け」に作られているが、
本当の馬鹿にはその意味すらわからないらしいｗ
430:デフォルトの名無しさん
07/09/02 18:57:24
わずらわしいどうの以前にその例外をどう扱うべきかというパターン自体が俺みたいな初心者にはわからない
使われる側でチェック例外を投げてから使う側で遺言を言ったあとRuntimeExceptionでラップするとか、
キャンセルなどの特殊な状況を処理するために使うとか、なんだろうか
431:デフォルトの名無しさん
07/09/02 21:40:59
捕捉する場所によって扱い方も異なるとしか言い様がないな。
ライブラリ書いてるなら、抽象的な例外でラップして投げなおすだろうし。
フレームワークならコントローラで一括処理で、それ以外では全部投げっぱなし。
432:デフォルトの名無しさん
07/09/02 21:49:00
個人的にはチェック例外＝病気の診断、ランタイム例外＝安楽死とか思ってる
で、今直せる見込みのない病人がいるとして、いろんな病院をたらいまわしたり（チェック例外のままthrowsしまくる）、
病気ではないとして放置したり（例外を握りつぶす）、
秘密裏に抹殺したり（System.exit(0)）、
するよりはランタイム例外にして安楽死させたほうがいいような気はするんだけどな。
でもそのあたりの常識やパターンやガイドラインみたいなものがないと実際何をやっていいのか分からないし、
URLﾘﾝｸ(www-06.ibm.com)とか見る限り、
今のAPI仕様でそれが完璧に行われているかというとそうでもない気がする。
どう診断すればいい医者であるか、と言う問題についてはもっと語られてもいい気がする。
433:デフォルトの名無しさん
07/09/03 00:54:17
病気になったら即安楽死＝良い医者だと？
434:デフォルトの名無しさん
07/09/03 00:56:05
スレ誘導しようとしたらいつのまにか例外処理スレが落ちてた。
435:デフォルトの名無しさん
07/09/03 04:46:11
>>420
その程度ならRuntimeExceptionで十分
436:デフォルトの名無しさん
07/09/03 07:58:03
>>435
その程度なら throws IOException 書いておけば十分。の間違いじゃね？
437:デフォルトの名無しさん
07/09/03 08:17:25
>>435
もっかい URLﾘﾝｸ(www-06.ibm.com) 読んでくれば？
438:デフォルトの名無しさん
07/09/03 08:53:56
>>432
ロッド＝ジョンソンの本の説明が出てるな
自分も彼のJ2EE本読んで、チェック例外に対する見方を改めた口だ
439:デフォルトの名無しさん
07/09/04 11:17:45
例外処理がもれなくSystem.exit(0)オンリーなソースを
押し付けられた俺涙目
440:デフォルトの名無しさん
07/09/04 11:21:35
例外処理が全部 System#exit(int) ってのもアレだが、
異常終了してんのに 0戻すってのも相当アレだよな。
441:デフォルトの名無しさん
07/09/04 11:36:48
終了するというコードが正しく実行できたので正常！
と。
曲がった先の信号が青だから曲がれる、という理屈に似てます。
>>439
まあ握りつぶされるよりはいいんじゃないか？
例外処理に関しては、パッケージ単位とか、今度出来るはずのモジュール単位で
包括して処理できる仕組みがあったら便利じゃないかなぁと思う。
442:デフォルトの名無しさん
07/09/04 14:31:16
>曲がった先の信号が青だから曲がれる、という理屈
これめちゃくちゃ危ないんだが・・・特に内輪差考えないで突っ込んで来る馬鹿な大型車とか。
443:デフォルトの名無しさん
07/09/04 22:43:55
>>439
脈絡ないけど、exit()の前にfree()は要らないってのを思い出してしまった。
444:デフォルトの名無しさん
07/09/04 23:43:03
>>432
一理あると思うが、マルチスレッドの場合はランタイム例外もきちんと
捕捉しとかないと握りつぶしたのとたいして変わらないことになるんだよな。
そのへん整合性あるガイドラインならいいんだが。
あと、安楽死というからには本当はやっぱり後始末もちゃんとしておきたいところ。
445:デフォルトの名無しさん
07/09/05 14:32:56
あのfree論争ってさ、
「とりあえずfreeはしておくべき」的な教条的理想論
「どうせ終了と同時にメモリ開放するんだからいいじゃん、っていうかfreeしたって実際何もしてないのとほぼ同じだし」っていう感じの現実論
って理解でいいんだよな？そりゃ永遠に話は平行線だ罠
446:デフォルトの名無しさん
07/09/05 14:37:30
例外ってさ、単純な入力ミスで出るようなはっきりいって例外処理までしてやりたくないようなどうでもいい例外か
出てる時点でもうもうどうしようもない例外が多いような気がする
447:デフォルトの名無しさん
07/09/05 15:06:10
外部からの入力ミスなら対処しないとダメだろ。
使い捨てアプリ作ってんなら、throws Exception 付けといて良いだろうし。
448:デフォルトの名無しさん
07/09/05 15:16:29
>>445
マトモな奴は、free論争なんかする暇があったら他の事をやる。
449:デフォルトの名無しさん
07/09/05 15:25:06
>>445
>>448 の2つに直交する「どっちでもええがな」論があって、これが現実解。
450:デフォルトの名無しさん
07/09/05 15:46:51
parseIntで数字じゃなかったときの処理を例外でやんないといけないとか、ひどすぐる。
451:デフォルトの名無しさん
07/09/05 16:05:21
>>450
なら、どうしたら良いと思う？
parseInt の戻り型を long にして数字以外なら int の範囲外が返ってくるとか、
parseInt の戻り型を Integer にして数字以外なら null 返すとかしても、
例外よりマシになるとは思えないけど。
452:デフォルトの名無しさん
07/09/05 16:11:43
＞parseInt の戻り型を Integer にして数字以外なら null 返す
それやるとオートボクシングしたつもりがヌルポになったりすっからなあ
isValidInteger()みたいなチェックメソッドを作ってやるとかどうよ。二度手間だが
453:デフォルトの名無しさん
07/09/05 16:15:34
>>452
安全なコードを書くためにそのメソッド使った
if文を書くことを強制しないといけない。
ならコンパイラでチェックしてやろうというのが
検査例外な訳で。
どこまで人間を信じるかだな。
454:デフォルトの名無しさん
07/09/05 16:15:42
> isValidInteger()みたいなチェックメソッド
なんという銀の弾丸
455:デフォルトの名無しさん
07/09/05 16:18:36
int[] parseInt(String)
返値は
{ パースした数字, エラーコード }
俺もparseIntについては何とかならないかと思ってた。
parseできないってのは、想定内の状況だからExceptionにするのはどうかな、と感じてて
例外と言うより１状況として扱いたいと思ってる。
ただ、上のようにしても何かしっくり来ない。
Exception以外に、例外状況をメソッドの返りで扱えるようになればいいな、と思う。
Exception処理が重すぎるというのが元凶なんだが、
RuntimeExceptionでないものに関しては
parseIntのように、stackTraceなんて重いものは要らなくて、
その場で処理してしまう例外状況って多いじゃないですか。
何とかならないのかなぁ。
言語構造的に、Throwable一本ってのが簡単なのは分かるんだが・・・
456:デフォルトの名無しさん
07/09/05 16:25:02
>>453
＞if文を書くことを強制しないといけない。
ここに関しては
Nullチェックに対するNullPointerException
Iterator#hasNext()に対するNoSuchElementException みたいなRuntimeException派生を投げれば済むと思うんだけど
二度手間なんだよね。このチェック。
457:デフォルトの名無しさん
07/09/05 16:29:35
>>456
hasNextはそのチェック自体が軽いからいいけど
parseIntは、parseしちゃってるからねぇ・・・二度手間ですよねぇ・・・・
458:デフォルトの名無しさん
07/09/05 16:29:50
>>455
> parseIntのように、stackTraceなんて重いものは要らなくて、
> その場で処理してしまう例外状況って多いじゃないですか。
parseInt の場合だと、
・ユーザー入力を parseIntした場合はユーザー入力が遅いのでExceptionが重くても問題ない。
・ファイル読み込んでparseIntした場合、パースできないケースは例外を使うべき状況なので問題ない。
だと思うが。
459:デフォルトの名無しさん
07/09/05 16:33:25
自己レス>>457
あ。parse結果をキャッシュできればいいのか。内部で。
って、コトは、staticメソッドじゃ駄目だな。
Stringのインスタンスメソッドになれば何とかなる、という所か・・・・
460:デフォルトの名無しさん
07/09/05 16:35:35
>>456
要するに、検査例外だと
コードがごちゃーとするのがやだから
実行時例外にして欲しいって事でしょ？
どっちにしろ、人間をどこまで信じるかだな。
461:デフォルトの名無しさん
07/09/05 16:37:04
>>460
paeseInt の話なら、NumberFormatException は実行時例外だが。
462:デフォルトの名無しさん
07/09/05 16:44:43
>>455
最近の言語であるみたいにJavaが多値を返せる言語だったら良かった
んだけどなあと思う。
(int, StatusCode) parseInt(String input)
とか。
ちょっとキモイが
interface ParseResult { }
class ParseSucceed implements ParseResult { }
class ParseFailure implements ParseResult {}
というクラスを用意して、ParseResult型の値を返すとかどうだろう。
463:デフォルトの名無しさん
07/09/05 16:48:13
>>462
後半、ただのEnumでよくね？
464:デフォルトの名無しさん
07/09/05 16:48:49
そんなややこしいことやるくらいなら Integer を返して null かどうかで判定できればそれでいいよ
465:デフォルトの名無しさん
07/09/05 16:52:55
>>464
だからそういうのやるとコードの変なところでヌルポが出そうで怖いんだって
オートボクシングするだけで出るし正体不明のバグ増やすだけ
466:デフォルトの名無しさん
07/09/05 16:56:38
じゃあ @CheckForNull 付加で
467:デフォルトの名無しさん
07/09/05 16:57:55
>>462
StatusCodeチェックしない場合はパースに失敗してても intの値が得られちゃうし、
その上現状よりキモくなってるしで、あんま良い事ないんじゃね？
468:デフォルトの名無しさん
07/09/05 17:02:33
>>462
多値を返すという話はだーいぶ昔からBugParadeでやられてて
話に参加してみたものの結局、やらないよーという結論。
まあ、どうしてもやりたきゃ、今は配列をつかえってところ。
それなら俺は、配列に違う型を含められるようにしてくれ、と思い・・・
でも、その場合型チェックはコンパイル時には難しいわけで
Objectの配列使うのと変わらないわけで・・・・
じゃあ、じゃあstructがあったらいいんじゃ・・・・っていうと、
アレ？それってクラスじゃね？と・・・・
型チェックが緩くてもともと実行時にしか型がきまらない
スクリプト型言語なら、複数返値も考えることあんまり無くていいんだろうけどねぇ
469:デフォルトの名無しさん
07/09/05 17:24:54
>>468
いやいや。型に厳しい関数型言語(MLやHaskell)などでは、
昔からタプルという形で多値が扱えたから、それと同等の
仕様にすればいいだけだと思うんだがな。
470:デフォルトの名無しさん
07/09/05 17:28:34
>>463
実装は省いたけど、ParseSucceed型からはパーズ結果の値を、
ParseFailure型からは失敗の原因を取得できるようにする意図が
あったので、ただのEnumだとよくない
471:デフォルトの名無しさん
07/09/05 17:47:44
>>469
>>455 だと Exception重いからException使わないようにしようって話でしょ。
タプルとか使って正常系の処理も重くしたら意味無いんじゃね？
472:デフォルトの名無しさん
07/09/05 17:55:24
>>470
パフォーマンス上の理由なら、そんなもんいちいちnewして返すぐらいなら、例外投げればいいと思う。
単にコードを簡潔にしたいだけなら、
static boolean parseInteger(String text, AtomicInteger out);
みたいなのをどっかに用意してやればいい。
AtomicIntegerは、他に標準でintを参照渡しできるインターフェイスが無いからなんで、
適当なintをsetできるインターフェイスならなんでもいいと思う。
コードを簡潔にするっていっても、結局正しくパースできたかのチェックは必要なんだから、
例外で十分でしょ。
473:デフォルトの名無しさん
07/09/05 18:06:05
しかし事前チェックが出来ないにもかかわらず実行時例外を投げてよろしいものだろうか
同じく文字列を解析して取得するタイプのClass#forNameが発行するClassNotFoundExceptionはキャッチ例外だよね？
474:デフォルトの名無しさん
07/09/05 20:31:41
>>472
パーズ失敗というのは、自分にとっては正常系の処理なんで
例外使うのは違和感があるんだ。感覚的な問題なんだけど、
Map<K, V>#get(K key)がkeyがエントリに存在しない場合に
例外を投げられると嫌なのと似た理由で。
475:デフォルトの名無しさん
07/09/05 20:35:55
>>474の補足だけど、Mapから値を取得しようとしたときにキーが存在しない場合
というのは、正常系の処理であることが多いから、もしもJavaのAPIの設計が、
例外投げるようになってたとしたらうっとおしいだろうなあということ
476:デフォルトの名無しさん
07/09/05 20:44:31
parseIntの場合も、本音で言うと多値よりnull返す方が良いと思ってる。ただ、
現状のJavaでは、nullを許容する/しないを型で表現できないという欠点が
あるので、微妙なところではあるけど。
477:デフォルトの名無しさん
07/09/05 20:46:57
はぁ？
478:デフォルトの名無しさん
07/09/05 20:55:41
C#のNullableは安易にstructをサポートしたがために招いた失敗仕様の名残じゃないか
オートボクシングでラッパーオブジェクトと用意に相互変換可能な現状で、んなもん無用の長物
479:デフォルトの名無しさん
07/09/05 21:53:06
使用できる範囲は限定されるが
int parseInt( String numberInString, int defaultValue )があればよかった。
パーズこけたらデフォルト値を返す。
480:デフォルトの名無しさん
07/09/05 21:55:44
そんなに1行で書きたいんですか
481:デフォルトの名無しさん
07/09/05 21:58:55
ラッパークラスに例えばisConvertable(String)みたいなメソッドがないのがねぇ。
2回パースするくらいなら例外でいいっしょｗｗｗｗｗｗって設計思想はちょっと。。。。
482:デフォルトの名無しさん
07/09/05 21:59:23
>>479
ドトネトのTryParseだな。
URLﾘﾝｸ(www.atmarkit.co.jp)
483:デフォルトの名無しさん
07/09/05 22:06:09
>>482
Javaだと参照渡しがないし、標準でmutableなintのラッパークラスも無いから作りにくい。
484:デフォルトの名無しさん
07/09/05 22:08:38
俺はjava.util.prefs.Preferencesのget()を思い出した
485:デフォルトの名無しさん
07/09/05 22:13:18
>>483
プリミティブを参照渡しさせない仕様なんだから
可変にしちゃったらラッパークラスにならないぞ
486:デフォルトの名無しさん
07/09/05 22:18:43
>>483
つ java.util.concurrent.atomic.AtomicInteger
っても、atomicな更新のためのクラスだから
mutableなintのラッパークラスとして使うのはアレな感じもするけど
487:デフォルトの名無しさん
07/09/05 23:17:23
org.omg.CORBA.IntHolder
CORBAのクラスなのがあれだが
488:デフォルトの名無しさん
07/09/05 23:25:19
>>478
C#のNullableは単に値型でnull許容可能にするための代物。
俺が言ってるのは、値型/参照型区別無くある型の変数に
nullを許容する/しないを指定できる代物。しかも、nullableな型は
non-nullableの型にそのまま代入しようとしたらエラーになって
コンパイラによるチェックを強制されるようなの。具体的な言語で言うと、Nice
URLﾘﾝｸ(nice.sourceforge.net)
がそれをサポートしてる。使ってみればわかるけど、この機能はかなり便利。
489:デフォルトの名無しさん
07/09/05 23:36:14
ウザいと思われるかもしれんけど、続けて書く。Niceで書くと定義はこんな感じで
書ける。
int? parseInt(String input) {//nullを含む可能性があるint型
try {
return Integer.parseInt(input);
}catch(NumberFormatException e) {
return null;
}
}
使用する方はこんな感じ。if(parsedValue != null)によるガードが無いと
コンパイルエラーになるのでNullPointerExceptionの心配は無い。
int? parsedValue = parseInt(inputValue);
if(parsedValue != null) {
//parsedValueを使った処理
}
490:デフォルトの名無しさん
07/09/05 23:39:25
この機能が無いからNullObjectが出来たんだな
491:デフォルトの名無しさん
07/09/05 23:45:26
>>489
それ、何が嬉しいのか分からん。
parseInt だと実行時例外で例外処理を強制できないから、
nullチェック強制できる >>489 の方が良いって話？
492:デフォルトの名無しさん
07/09/05 23:47:05
よく考えてみたらオートボクシングめんどくせえなｗ
これ
493:デフォルトの名無しさん
07/09/05 23:54:52
>>491
パーズ失敗を例外で扱うのに反対で、返り値でパーズ失敗を扱いたいんだけど、
nullでパーズ失敗を表すとしたらNullPointerExceptionの危険性があるし、意図が
あいまいになる危険性もある。で、この機能があればnullを許容するという事を
明示できるし、NullPointerExceptionの危険性も無いから欲しいなあということ。
494:デフォルトの名無しさん
07/09/06 00:01:56
コンパイルエラーを期待してって考えなら分からんでもない。
javaならメソッド側にアノテーションで実現することになりそうだ。
@NilExclude int parsedValue = parseInt(inputValue);
if (parsedValue != null) {
// このブロック以下でのみparsedValueへはアクセス可能
}
// このスコープでparsedValueへはアクセスできない
をコンパイルすると拡張構文よろしく等価コードに展開されるみたいな感じか。
int parsedValue = 0;
Integer parsedValue$ = parseInt(inputValue);
if (parsedValue$ != null) {
parsedValue = parsedValue$.intValue();
// ...
}
495:デフォルトの名無しさん
07/09/06 00:03:19
結論はおまえにはjavaは合ってないって事だな。
話聞いてると考え方が短いコードで実現させるタイプの動的言語の発想だ。
496:デフォルトの名無しさん
07/09/06 00:04:38
で、何故parseInt()のパーズ失敗を例外で扱うのに反対かというと、parseInt()は
引数から返り値が一意に定まるので、たとえパーズ失敗でも例外的な状態と
言えないと考えるから。
497:デフォルトの名無しさん
07/09/06 00:06:27
>>495
なんで動的言語が関係してくるの？むしろ静的にチェックできる機能が
欲しいって話をしてるわけで、動的言語とは対極の発想だよ。というか、
短いコードが好ましいってのは動的言語特有の発想でもないでしょ。
498:デフォルトの名無しさん
07/09/06 00:07:59
> メソッド側にアノテーションで実現することになりそうだ。
メソッド側にってのは余計。構成してて放置したままだった。
499:デフォルトの名無しさん
07/09/06 00:15:42
契約的言語。
500:デフォルトの名無しさん
07/09/06 00:21:29
アノテーションひとつで
if (n != null) { /* n アクセス */ } と
if (n == null) { return; } /* n アクセス */
のどちらかを選択（および強制）できるのなら歓迎かな。
@Overrideの親戚みたいなもんだ。
501:デフォルトの名無しさん
07/09/06 00:43:04
例外を「例外的な状態でのみ使うべき」というのは言葉が同じだからもっともらしく
聞こえてしまうだけで、何の助けにもならない方針。
URLﾘﾝｸ(www.boost.org)
URLﾘﾝｸ(boost.cppll.jp)
502:デフォルトの名無しさん
07/09/06 00:48:46
>>500
FindBugsをどうぞ
URLﾘﾝｸ(findbugs.sourceforge.net)
503:デフォルトの名無しさん
07/09/06 01:03:12
>>493,496
単に自分の考えと合わないってだけ？
それって自前のクラスメソッド書いて、そっち使うんじゃダメなんか？
なんつーか、>>448-449 あたりが結論になりそうな話じゃねーかと。
504:デフォルトの名無しさん
07/09/06 01:14:56
>>503
もちろん自前のクラスメソッド書いて使うことになると思うよ。
実際にJavaプログラム書くときの解決策としては。単に言語の
拡張まで含めて許されるならどういう設計にするのが良いかという思考実験。
あと、free論争とは文脈が違うので一緒にされるのはちと心外だな。
どういう方針でライブラリ設計をするかという話は使い勝手に関わって
くる。もちろん、ここで議論しても実際のJava APIの設計が改善されない
という意味では無益なのはそうだけど。
505:デフォルトの名無しさん
07/09/06 01:26:05
>>496
理解できない
すべての失敗する引数はnullが返ることで一意に定まるということ?
例外的な状態かどうかはparseInt単体でなく、呼出し側がどうしたいかでも異なるはずだ
デフォルト値が定まる場合と定まらない場合、とか
んで、とりあえず保守的にパーズ失敗を例外として扱うと言う設計でよいと思う
checkedかどうかは微妙なとこだが
506:デフォルトの名無しさん
07/09/06 01:26:52
単に好き嫌いの問題で、パフォーマンスとか関係ないんでしょ？
free論争と大して変わらんと思うが。
507:デフォルトの名無しさん
07/09/06 01:30:33
>>504
parseInt の使い勝手を改善する事により、Java での開発効率が 10％向上するんだ！
とか考えてるなら 一生懸命考えるのも頷けるんだけど……
ぶっちゃけ瑣末な問題じゃね？
508:デフォルトの名無しさん
07/09/06 01:40:40
例外を握りつぶすユーティリティメソッド作ればOK。
509:デフォルトの名無しさん
07/09/06 02:03:58
>>505
> すべての失敗する引数はnullが返ることで一意に定まるということ?
そういう意図で書いた。正確に言うと、外部の状態に依存せずに
入力*のみ*から返り値が決定される、ということ。その逆の
典型的な例としてはIOExceptionを発生させるような関数や
コンストラクタがある。これらの関数は入力だけでなく外部の
状態によって成功したり失敗したりする。
>>507
parseIntだけの問題として考えればぶっちゃけどうでもいいけど、
一般的な問題としてある関数が失敗を返り値で通知するか
例外で通知するか、というのは瑣末な問題じゃないと思う。
510:デフォルトの名無しさん
07/09/06 09:42:29
ユーティリティメソッド作ればOKってのは、思考停止以外のなにものでもない。
511:デフォルトの名無しさん
07/09/06 09:46:39
parseInt を改変しようとか考えるのは暇人以外のなにものでもない。
512:デフォルトの名無しさん
07/09/06 09:53:09
>>511
そうか？
513:デフォルトの名無しさん
07/09/06 10:14:54
>>511
つきあってた連中も暇人以外のなにものでもない。
514:デフォルトの名無しさん
07/09/06 11:20:14
改変は、ちゃんと考えてbugparadeにあげるなどすれば、なにがしかの影響は与えられる。
ここで改変について語るのも、そういったヤツのインスピレーションになることもあるだろうし、本人が書き込むこともあるだろう。
無駄ではないよ。
515:デフォルトの名無しさん
07/09/06 11:39:06
なにがしかの影響って……
>>509 も parseInt に関してはどうでもいいって言ってるんだが。
そんな瑣末な問題に関わらせる事で
JDK開発者のモチベーションを下げたいって事か？
free論争ってさ、やってる当事者は引っ込みがつかなくなってるだけかと思ってたけど
案外、>>514みたいに「この議論は無駄ではない」とか思ってる人も居るのかも知れないね。
516:デフォルトの名無しさん
07/09/06 11:41:41
parseIntの例外が例に挙がって
- コードを短く書きたい
- 例外で扱う状況とは思えない
という2点の争点があると思う。
さらに後者の視点は、
- 例外を扱うべき状況を設計の美しさから考える
- 例外を扱うべき状況をException処理の重さから考える
という2つの立場がある
俺は、parseIntに例外の記述が出てきてもいいが、重いException処理が
いやだなぁ、という点から、こういうのがあればいいんじゃないかと思う。
定義済Exception/ StaticException / 短距離Exception /LightWeightException ?
今、Exception処理が重いのは、Exceptionオブジェクトの生成にある（スタックトレース生成など）
つまり、生成処理をなくしてやれば大幅にパフォーマンスは改善するはず。
なので思い切って、stackTraceとかが空っぽのExceptionで
すぐ直上のcatch節で捉える決まりで、
さらにThrowの必要があるときは別のExceptionにしなくてはいけないようなもの。
気軽に例外が投げられるようになって、正常系の処理が例外でトリッキーに実装されるように
なっちゃうかもしれないけど、こういうのってどうですかね。
517:デフォルトの名無しさん
07/09/06 11:47:27
>>515
相手にするから調子に乗るんだろ。ほっとけ。
518:デフォルトの名無しさん
07/09/06 12:05:24
>>516
> 重いException処理がいやだなぁ、という点
いやなだけなのか。
これこれこういう使い方をすると、
（パーズ失敗する）parseInt の呼び出しがボトルネックになって困る、
そして、このような使われ方をする事が多いので標準APIを改善して欲しい、
ってんなら議論の余地もあるけど、それって単なる好き嫌いの問題じゃね？
519:デフォルトの名無しさん
07/09/06 12:39:29
>>518
包丁一本で、何でも作るのって大変じゃないかな、って話です。
URLﾘﾝｸ(sourcepost.sytes.net)
のコード書いて、Exception生成のコストを見てみました。
ウチのマシンでの結果です（かかった時間）
Try[1]:422
Try[2]:10469
Try[3]:78
Try[4]:10875
１つめが、Throwableを継承して、Overrideで色々ぶった切ったクラス。
２つめが、単なるException。
３つめが、単なるObject。
４つめが、NumberFormatException。
Objectのnewに比べて、Exceptionのが大幅に重い処理となっています。
NumberFormatExceptionもそうです。
もし、ファイルを読む処理をするときに、数字でないものも大量に含むフィールドがあれば
Exception処理が時間を食うことが予想されます。
Exceptionの機能を大幅にカットすれば、２桁のオーダーで処理を軽くすることができるわけです。
現在の仕組みを使って、実装するならこうなりますがシステムとしてサポートしてくれても
いいかなぁ、と思ったわけで。