[Java SE 7] 次世代Javaの動向 5 [dolphin]

1 名前：デフォルトの名無しさん [2007/05/12(土) 08:25:15 ] 前スレ [mustang/Java SE 6] 次世代Javaの動向 4 [dolphin] pc11.2ch.net/test/read.cgi/tech/1163986696/ [mustang] 次世代Javaの動向 3 [dolphin] pc8.2ch.net/test/read.cgi/tech/1157227790/ 次世代Javaの動向　２ pc8.2ch.net/test/read.cgi/tech/1147881822/ 【Java】次世代Java・J2SE1.6の動向【Mustang】 pc8.2ch.net/test/read.cgi/tech/1081698555/ 267 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 17:24:49 ] >>266 JDK5以降のライブラリや、メソッドを使うときに注意。 Autoboxingなどはちゃんと処理される。 268 名前：デフォルトの名無しさん [2007/08/10(金) 01:25:21 ] win32 apiとか触るの面倒だし、だれかjvm上で.netが動くの作ってくれないかな C＃をインタプリタ実行するのでもいいからさ 269 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 01:26:53 ] >>268 それはそれで凄まじいな ……考えてみるか。 270 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 01:51:45 ] C# を Java バイトコードにコンパイルする方が楽じゃない？ 271 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 02:08:05 ] エスケープ解析は、*.javaに対して行っておくほうが実行効率がいいけど、その情報を*.classに残す手段がないので、実行時の最適化でしか使われていない 272 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 02:12:52 ] >>249 >>247だが、実際にソースまで追って確認したわけじゃないので そういう表現になっただけで、JITコンパイル段階でやってるのは ほぼ間違いないよ。まあ、厳密に言えばインタープリタモードでも やってる可能性もあるけど、メリットが考えられない。 273 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 03:03:50 ] 手段がないわけじゃないと思うけど。 stackmapっぽい新しい属性をクラスファイルに追加すればいいんだし。 ただ、静的に解析しても効果が弱いと思う。 メソッドの非仮想化やインライン展開を終えた後にやる方がいい。 274 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 03:17:31 ] >>273 それは、メソッドの非仮想化とインライン展開がエスケープ解析に与える影響がすごく大きいってこと？ そうは思えないんだけど。 275 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 03:46:33 ] >stackmapっぽい新しい属性をクラスファイルに追加すればいいんだし。 これは上で出てきたstructをJava言語でサポートするんじゃなくて、 JVMでサポートするってのに実質的に近いんじゃないか？ 276 名前：デフォルトの名無しさん mailto:sage [2007/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 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 04:44:16 ] >win32 apiとか触るの面倒だし ここらへんあるから実質C#はマルチプラットフォームじゃないよね。 278 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 09:53:41 ] >win32 apiとか触るの面倒だし それだけだったら、win32 api を触らなくて済むようなGUIフレームワークとかを使えばいいだけと違うん？ 279 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 09:56:34 ] >>273 > ただ、静的に解析しても効果が弱いと思う。 > メソッドの非仮想化やインライン展開を終えた後にやる方がいい。 二行目は静的/動的と関係ないじゃん。 280 名前：278 mailto:sage [2007/08/10(金) 09:57:41 ] って、.C# か・・・ じゃあ GTK# とか・・・ びみょかな・・・ 281 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 11:35:35 ] >>279 静的に＝.javaのコンパイル時にって意味で書きました .javaコンパイル時に非仮想化・インライン展開とかできないでしょ わかりにくくてごめんなさいね この暑さでちょっと疲れてるんだ 282 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 11:49:09 ] 出来ないことないじゃん。もうInner classあるんだから。 283 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 11:54:25 ] Inner class って、なんか関係が？ 284 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 11:59:12 ] インナー・クラスの非仮想化・インライン展開はソース・コンパイル時に出来る。 285 名前：デフォルトの名無しさん mailto:sage [2007/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 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 12:42:11 ] そもそもprivate:ならインライン展開し放題じゃない。 287 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 12:45:06 ] それはまぁね。 288 名前：デフォルトの名無しさん [2007/08/10(金) 17:18:14 ] で、実際デフォルトで（知らないところで）インライン展開はされているのか？ それも、メモリ上に展開なのか、ソースコード（.class）のバイト数が増加しているのか。 289 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 17:20:42 ] > で、実際デフォルトで （　ﾟдﾟ）ﾎﾟｶｰﾝ 290 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 17:45:00 ] はいはい、あげあし君はさようならで 291 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 17:58:23 ] 似たようなことを議論してるよ。 stack allocateについては、 アノテーションで指示するか、 ByteBufferでアドレッシングしてくれってことのようだ。 bugs.sun.com/bugdatabase/view_bug.do?bug_id=4820062 292 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 18:31:07 ] >>291 そこの議論の対象はC/C++の struct で作られたような データ構造にアクセスする事であって、 言語仕様的に stack allocated object が欲しい場合は bugs.sun.com/bugdatabase/view_bug.do?bug_id=4213096 bugs.sun.com/bugdatabase/view_bug.do?bug_id=4809540 どっちかにvoteしろって書いてあるよ 293 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 18:35:28 ] C# だと各メンバに FieldOffset が指定できるよね >>291 はそういう話じゃないの？ 294 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 18:54:29 ] >>292 で、君はそっちのREFをチェックしてからものを言ってるわけなのかな？ >>293 C#がどうしたって？ ざっとみてスタックがどうとか言う議論になってたから似たようなの出してみたのだけど。 295 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 19:02:35 ] いや、データをバイト列にパックする話とスタックアロケーションは別の問題だから。 296 名前：デフォルトの名無しさん mailto:sage [2007/08/11(土) 03:07:02 ] 君の都合にあわないからといって、いちいち相手にｹﾁをつけるところは君の悪い癖だな 297 名前：デフォルトの名無しさん mailto:sage [2007/08/11(土) 16:11:19 ] なあ、全員「デフォルトの名無しさん」じゃねえか 同一人物間でケンカ自演してるのってどうよ って突っ込んでるオレも同一人物な訳だが 298 名前：デフォルトの名無しさん mailto:sage [2007/08/11(土) 16:22:00 ] 夏休み的なツッコミだな 299 名前：デフォルトの名無しさん mailto:sage [2007/08/11(土) 19:00:47 ] ボケだろ、ボケ 300 名前：デフォルトの名無しさん mailto:sage [2007/08/13(月) 15:24:33 ] ノリツッコミか 301 名前：デフォルトの名無しさん mailto:sage [2007/08/18(土) 04:47:25 ] JDK7 build18 download.java.net/jdk7/changes/jdk7-b18.html download.java.net/jdk7/binaries/ 細かいバグ修正とか。 302 名前：デフォルトの名無しさん mailto:sage [2007/08/19(日) 07:15:13 ] java LnFっていずれocanからSwing new LnFと謳ってるNimbusになるのかね？ 303 名前：デフォルトの名無しさん mailto:sage [2007/08/19(日) 08:19:46 ] Nimbusはスクロールバーがヤだ 304 名前：デフォルトの名無しさん [2007/08/19(日) 15:38:42 ] 確かにへぼいな 305 名前：デフォルトの名無しさん mailto:sage [2007/08/19(日) 16:52:27 ] javaのスレでC#の話をするなボケども 306 名前：デフォルトの名無しさん mailto:sage [2007/08/19(日) 17:31:28 ] JSR 310ってどうよ 307 名前：デフォルトの名無しさん mailto:sage [2007/08/19(日) 19:22:01 ] >>302 Nimbusはごっつい雰囲気が強すぎて微妙ー Aquaとかみたいな甘いデザインにしてくれと思う。 >>306 各所のブログでJSR 310は入れてほしくないと言われているな。 どうなんだろう・・・ 308 名前：デフォルトの名無しさん mailto:sage [2007/08/19(日) 19:34:49 ] 使うことはあまりないだろうな。 309 名前：デフォルトの名無しさん mailto:sage [2007/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 名前：デフォルトの名無しさん mailto:sage [2007/08/19(日) 21:28:31 ] >>306 https://jsr-310.dev.java.net/nonav/javadoc/index.html 311 名前：デフォルトの名無しさん mailto:sage [2007/08/20(月) 17:49:33 ] >>309 いや、正直、1月が0とかは文章にしていてもあり得ない。 使うたびにAPIをその仕様で設計したヤツに殺意を覚える。 ライブラリの使い方からCと違うんだから中途半端にわかりにくくしてるだけ。 312 名前：デフォルトの名無しさん mailto:sage [2007/08/20(月) 18:02:22 ] 文章化してあるから問題なしって・・・ 313 名前：デフォルトの名無しさん mailto:sage [2007/08/20(月) 18:56:22 ] >>311 分かりにくいっても、C言語使った事あれば1月が0になる事もあるってのは予測可能だし。 不勉強な上に不注意な連中が躓く原因であるのは確かだろうけど、 たぶん、そういう連中は 月フィールドが 1オリジンになったら Calendar と互換性なくなって躓くだろう。 ゼロから新しいAPIを作るならともかく、既存の Calendar と共存するつもりなら、 新しいクラスを作って、そのクラスの月フィールドを 1オリジンにしたぐらいじゃ幸せにはなれない。 314 名前：デフォルトの名無しさん mailto:sage [2007/08/20(月) 19:37:12 ] >>311 まぁ有り得ないとか殺意を覚えるってのは程度の差だからなんとも言えんけど。 オレとしては 1月を 1 にしたければ、とりあえずユーティリティメソッド1つ作れば良いと思うんだわ。 で、オレの感覚からすれば、ユーティリティメソッド1つで解決するような問題を掲げて わざわざ新API作ろうって感覚の方が有り得ないんだわ。 スライド見て感じた事ってのはそーゆー事。 315 名前：デフォルトの名無しさん mailto:sage [2007/08/20(月) 19:43:10 ] 今から新しく作るんなら、enumにすればいいんじゃまいか。 public enum Month { JANUARY, FEBRUARY, ... } 316 名前：デフォルトの名無しさん mailto:sage [2007/08/20(月) 21:05:04 ] そして旧暦閏月で困ると。 317 名前：デフォルトの名無しさん mailto:sage [2007/08/20(月) 21:21:43 ] 閏月対応してるクラスってあったっけか？ 318 名前：デフォルトの名無しさん [2007/08/20(月) 23:19:30 ] Timeの方は刹那とかに対応しないかなと思ってみたりｗ 10^-18なんて精度表せないだろうが。単位として扱えたら面白そう。 319 名前：デフォルトの名無しさん mailto:sage [2007/08/20(月) 23:25:25 ] 誰が使うんだ、そんなもん…… 320 名前：デフォルトの名無しさん mailto:sage [2007/08/20(月) 23:41:02 ] ナノ時間取得はコストが高すぎるんだよな・・・ 321 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 01:23:50 ] >>319 坊さん用ソフト開発なプログラマｗ 24時間=30牟呼栗多=900臘縛=54,000怛刹那=6,480,000刹那という変換するとか。 スウォッチインターネットタイムも欲しいな。 322 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 01:33:32 ] 坊さん用なら卒塔婆プリンタの方が喜ばれそうだが。 っつか、Wikipedia漁って適当な事言ってるだけじゃね？ 323 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 08:50:41 ] www.atmarkit.co.jp/news/200708/20/httpcomp02.png 　同じくフォーチュン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 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 09:53:51 ] そろそろJava終了のアナウンスがSunからあるのかな まぁいい思い出になったよ 325 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 10:20:43 ] >>323 ASPとASP.NET合計で51.5％か。意外に低シェアだな。 >>324 Sunあぼーんして、IBM & Google が実権を握ってくれる方が嬉しいなぁ。 326 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 10:23:58 ] >>315 一応、Calendar.JANUARYとか定数ならあるよ。 そっち使うでしょ普通。 327 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 10:24:54 ] あ、そっち使うでしょ、ってのは0とか1とかじゃなくて、って意味。 enumならなおよろしいけど、互換の問題がねぇ・・・。 328 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 13:37:56 ] >>327 日付扱うときは、だいたいユーザー入力だから無意味。 プログラム中でJANUARYとか指定することなんてあまりないんじゃね？ 329 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 16:31:57 ] ユーザー入力を文字列として持ち回すと難儀だよね。 でも、WEBアプリにしろSwingにしろ、フレームワークとか 日付入力コンポーネントとかでDate型で最初から 扱える奴あるし、今時大概そうじゃないのかな。 プログラムの中で月決め打ちってのは確かにあまりないですね。 テストコードくらいか。 330 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 17:51:54 ] >>314 いや、ラッパークラスを用意すればいいってのはユーザ側の対応になる。 それはつまり、現状のDate型の変更に依存する訳だし 自分が書いたコードはラッパークラスを必ず含まなくてはならなくなる。 それならコアAPIに入っててくれよ、と思わないか？ 今のDate型の実装だと、実装者自身が作り直したいと考えても 仕方がないような作りが多々ある。Calendarを追加して手当したけど 時間、日時を扱う場面は多くある。 これだけJavaが使われてその問題点が明らかになったんだから 新しくより合理的なAPIができてもいいと思う。 言うなればJava3とでもいうものへのへの緩やかな変化。 基本的なモノだからこそ改良が重要になってくるとは思うんだ。 アトは失敗しないようにしっかりと作ろうってところだろうか。 331 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 18:15:12 ] Calendarいらないってがんばっている人もいる。 tp://d.hatena.ne.jp/nowokay/20070628 tp://d.hatena.ne.jp/nowokay/20070630 これが本当に通ってくれれば 憂いなしで嬉しいな。 332 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 18:29:39 ] つか、きしださんまで月間違ってるし！ 333 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 19:05:53 ] >>330 ラッパークラスで解決しようというのはダメだろ。 Calendar の set やら get を ラップして 1月が1になるようにしても、 自分の目の届く範囲だけなら構わないけど、 第三者が作ったクラスに渡す場合には、そのまま渡したら 1ヶ月ずれる。 そんなゴミをコアAPIに入れられたら、 Calendar をやり取りする メソッド作る場合に、必ず instanceof とかでチェックしなきゃいけなくなる。 334 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 19:08:21 ] >>331 無理じゃね？ java.util.Date は Serializeable だし、 Date の TimeZone対応とかやったら、 シリアライズされたデータの互換性なくなるんじゃないか？ 335 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 19:10:30 ] W3C-DateTimeからRFC2822-DateTimeに用意に変換できるようなものが欲しい。 RFCのほうはCWFSのおかげでやたらパースがしにくい。 336 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 19:23:34 ] >>330 > これだけJavaが使われてその問題点が明らかになったんだから > 新しくより合理的なAPIができてもいいと思う。 あっても良いけど、closure とかに比べると優先度は低いよね。 それに「問題点」ってのも個人個人で違うわけで、1月 が 0 なのがダメなのか、 setter の戻り値の型が void だから、1行に詰め込んで書けないのが問題なのか それ以外なのか。 現状では愚痴とか不満は出てるけど、 それらを一つに纏めて、多くの人が納得でき、多くの人が幸せになれるような 解決策が提示されているかっていうと、少なくとも JSR-310 は違うと思う。 337 名前：デフォルトの名無しさん [2007/08/21(火) 20:22:16 ] >>335 まえにjavascriptの実装がどっかのブログで公開されてたぞｗ 338 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 22:16:24 ] >>336 いや、JSR-310はまだ固まってないし。 そういう動きがある、ということしか言えないと思う。 なんで、これからの頑張り次第でしょ、という話。 それとも、「日付関係の新しいAPIは要らないぜ」という話？ 339 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 23:24:14 ] >>338 1月が 1 と書けるようになっただけ、の Calendar みたいなクラス作られても あっちのフレームワークでは互換性のために旧Calendar要求され、 こっちのフレームワークでは機能性のために新API要求され、 みたいに手間が増えるだけになる可能性が高い。 かと言って、Calendar が解決しなかったニッチな要求のためだけのAPI作ったら わざわざ標準APIに突っ込む必要ないって話にもなるし。 既存のDate＆Calendarがある状況で 日付関係の新しいAPIを作るのは凄く難しいと思ってるんだけど、 1月が 0 なのがキモイみたいな事かかれると、 マトモなものが出来るのか心配になるって話。 340 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 23:27:03 ] 動画再生用のSwingコンポーネントが標準化されたりしたら嬉しいのだけど、 JavaFX Scriptに合わせて対応してくれたりせんのかねぇ。 Flashは次のバージョンでH.264にも対応するとか発表してるし、 本気でRIA市場に乗り込むならここらへんを抑えてくれないと支持しにくい。 341 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 23:36:53 ] つ JMF 342 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 23:38:58 ] JRE以外にインスコしてもらえるわけないじゃんｗ 343 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 23:51:58 ] jarに全部突っ込んでマニフェストでパス指定するか。JWSでいいだろ。 けどJMFのH.264コーデックがまだIBMのプロプラライセンスものしかなかった気がする。 344 名前：デフォルトの名無しさん mailto:sage [2007/08/22(水) 09:04:57 ] >>339 相互変換はコンストラクタ一発なんだから問題ないんじゃね？ 345 名前：デフォルトの名無しさん mailto:sage [2007/08/22(水) 09:09:49 ] SilverlightやFlashに比べて、JREはインストール面で不利すぎる気がするのですが 軽量プラグインとか出す予定はないのでしょうか？ 346 名前：デフォルトの名無しさん mailto:sage [2007/08/22(水) 09:24:14 ] 何を削るかで揉める事必至だろうなぁ・・・ いっそのことJ2MEのランタイムを作ってそれを軽量プラグインにするとか 347 名前：デフォルトの名無しさん mailto:sage [2007/08/22(水) 11:31:10 ] 分割ロードの方が良さそうだなあ。 Javascriptは何でも一つのファイルにぶち込むのが流行ってきているけれども。 348 名前：デフォルトの名無しさん mailto:sage [2007/08/22(水) 14:09:41 ] >>345 Java Kernel と呼ばれているものを jdk6 update 4 で出す予定 weblogs.java.net/blog/enicholas/ weblogs.java.net/blog/forax/archive/2007/08/java_kernel_in.html 349 名前：デフォルトの名無しさん mailto:sage [2007/08/22(水) 14:24:44 ] >>344 Date と Calendar はコンストラクタ一発で変換できてないじゃん。 それと同じ事が起こる事は十分予測可能。 350 名前：デフォルトの名無しさん mailto:sage [2007/08/22(水) 14:30:23 ] >>349 っつーか、コンストラクタ一発で変換できても煩雑なのは変わらんのだがな。 351 名前：デフォルトの名無しさん mailto:sage [2007/08/22(水) 20:01:17 ] ”よく知られた日付型”がこれ以上混在されてもうざいだけだよ。 DateにCalendarにsql.Dateと、”よく知られた日付型”は、もう既に食傷気味です。 所詮は64bit unix epocと割り切ったユーティリティメソッドが拡充される方がよほど嬉しい。 352 名前：デフォルトの名無しさん mailto:sage [2007/08/22(水) 21:21:02 ] なるほど。 良くあるパターンに特化したユーティリティメソッドを用意してくれる方が ありがたい気がする。 353 名前：デフォルトの名無しさん mailto:sage [2007/08/22(水) 21:49:03 ] JREのインスコなんてウィザードに従えば良いだけだろ。 それより、システム管理全体がside by sideへ以降してきてメンテにエンドユーザーの負担が掛かってると思う。 354 名前：デフォルトの名無しさん mailto:sage [2007/08/23(木) 01:19:58 ] JSR 310はいいと思う。 ユーティリティ・クラスとしても上出来。 355 名前：デフォルトの名無しさん mailto:sage [2007/08/23(木) 03:08:43 ] >>354 そうなん？ >>310 に JSR-310 のAPIリファ来てるけど、 これどんな時に便利なのかサンプルコードとか書いてくれん？ っつか、オレには Moment や Period のサブクラスが 年、月、日、時、分、秒と分かれてる必要性がイマイチわからん。 356 名前：デフォルトの名無しさん mailto:sage [2007/08/23(木) 04:03:13 ] タイムベースの処理が必要でそのフレームワークを自前で作らなきゃいけないときに下のライブラリとして使えそうだな。 357 名前：デフォルトの名無しさん mailto:sage [2007/08/23(木) 04:06:51 ] >>310がJSR-310のリンクになっていることに 今になってようやく気が付いた。 なんか黄色ナンバーの車を1日10台見たとか ワーゲン見たとかその程度にちょっと幸せ。 358 名前：デフォルトの名無しさん mailto:sage [2007/08/23(木) 08:11:21 ] >>355 ぶっちゃけ、>>310より>>331の方が良いと思う…… 359 名前：デフォルトの名無しさん mailto:sage [2007/08/23(木) 08:43:24 ] >>356 逆に言うと、それ以外の目的に使えなさそうじゃね？ 360 名前：デフォルトの名無しさん mailto:sage [2007/08/23(木) 08:46:22 ] どっちがいいとかそういうもんじゃないだろ。 310はベースとなる時刻クラスを提供するんだから。 361 名前：デフォルトの名無しさん mailto:sage [2007/08/23(木) 08:49:25 ] 今のままだったら Date ＆ Calendar の方が下位層で JSR-310 はそれに乗っかるだけの上位層になりそうだが 362 名前：デフォルトの名無しさん mailto:sage [2007/08/23(木) 08:50:20 ] （　ﾟдﾟ）ﾎﾟｶｰﾝ 363 名前：デフォルトの名無しさん mailto:sage [2007/08/23(木) 08:52:26 ] おまけに使用用途が酷く限定されている、と。 364 名前：デフォルトの名無しさん mailto:sage [2007/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 名前：デフォルトの名無しさん mailto:sage [2007/08/23(木) 09:25:39 ] >>360 310が提供するベースとなる時刻クラスってどれよ？ 366 名前：デフォルトの名無しさん mailto:sage [2007/08/23(木) 11:36:39 ] 文字列からのファクトリメソッドは、 別クラスにした方がいいんじゃないの？ L10N考えると劇重プロジェクトだし。 GNU dateコマンドみたいな時間指示を考えると、やること一杯ある。 367 名前：デフォルトの名無しさん mailto:sage [2007/08/23(木) 11:46:17 ] これはひどい ベースとなる時刻クラス・・・ Instant かねぇ でも CalendarDay や TimeOfDay との相互変換はできそうになく 既存の Date や Calendar との繋がりもない どうやって使うんだこれ

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef