[Java SE 7] 次世代Ja ..
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型の値を返すとかどうだろう。
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5389日前に更新/224 KB
担当:undef