[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/ 528 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 17:31:04 ] パースの失敗は十分、例外的状況に値すると思うが・・・。 例外処理の乱用がスパゲッティーコード招いてるんじゃなくてそういうコード書いてる自分がスパゲッティー作ってるんだと思う。 アプリケーションかミドルウェア側の設計でどうにかなると思うんだが？ 529 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 17:37:48 ] >>527 InterruptExceptionって例外的だと思う？ スレッドのキャンセルを実装しようと思ったら普通に出るけど 530 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 18:49:35 ] >>528 設計っつーか、実装で吸収できるでしょ。 531 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 20:19:45 ] 便利なら便利なほうがいい。 532 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 20:24:49 ] 何を便利と感じるかは人によって違う、と。 かと言ってなんでも標準APIに入れたら標準APIメンテする人間の負担が増えて バグが増えたり放置されたりといった悪影響も考えられる、と。 533 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 20:47:42 ] NICEのnullableってのは興味深いネタだったけど、 それと一緒に語られたparseIntの仕様には何の興味も湧かなかった。 つーことで、イディオム補完型（保証型）のアノテーションの充実を期待したい。 534 名前：デフォルトの名無しさん mailto:sage [2007/09/07(金) 07:32:33 ] >>445 終了前のfreeは害っていうのがいるだろ。 535 名前：デフォルトの名無しさん mailto:sage [2007/09/07(金) 07:55:31 ] そんなものは無い 536 名前：デフォルトの名無しさん mailto:sage [2007/09/07(金) 22:37:51 ] blogs.wankuma.com/kacchan6/archive/2007/09/07/94499.aspx 537 名前：デフォルトの名無しさん mailto:sage [2007/09/07(金) 22:39:06 ] blogs.wankuma.com/kacchan6/archive/2007/09/07/94499.aspx 538 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 00:14:55 ] parseIntで100近くもダベれるお前らに脱帽 539 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 00:53:35 ] >>536 低脳な質問で悪いんだけど 「クリティカルで速度が要求される場面での数値チェックは、例外を使わないのが無難っぽいです。」 って言ってるけど、じゃぁどういう処理が望ましいんだろうな。 俺も、試しに同じ用なプログラムを10000000回処理をぶん回してみたが、 正直それほど有意差は認められなかった。 ----以下結果---- StringUtils.isNumeric() : boolean で不正な文字かどうかを検知 1回目 451 ms 2回目 401 ms Integer.parseInt() : 例外で不正な文字かどうかを検知 1回目 42822 ms 2回目 42771 ms 540 名前：デフォルトの名無しさん [2007/09/08(土) 01:03:04 ] >>539 例外を使ってるバージョンが100倍近く遅いんだが、それは 有意な差じゃないの？ 541 名前：デフォルトの名無しさん [2007/09/08(土) 01:05:19 ] あ、もちろん実際にparseIntが使われる局面で1000000万回も 呼ばれることは無いだろうから、そういう意味では例外を使っても いいんだろうけど、有意な差が無いってのは変でないの？ってこと 542 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 01:05:27 ] >>539 ネタにマジレス。 まず 数値チェックに parseInt 使って > クリティカルで速度が要求される場面 が具体的にどういう場面なのかってのを特定するのが先決。 それをしないで「どういう処理が望ましいか」を考えても時間の無駄。 543 名前：デフォルトの名無しさん [2007/09/08(土) 01:07:45 ] 間違った。1000000万回 -> 1000万回 544 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 01:12:44 ] >>538 まだまだ続くよ 545 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 01:59:22 ] 巫女巫女ナース巫女巫女ナース♪ 546 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 02:32:19 ] ｢まだまだ　いくよぉ〜｣だな 547 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 03:09:27 ] もうちょっとだけ続くのじゃ 548 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 07:03:01 ] つうか、例外は制御構造の要だろ ttp://d.hatena.ne.jp/smeghead/20070309/baka 549 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 08:05:55 ] 多値にしてもnullableにしても、 失敗をnullで表すのはちょっと古いんじゃないかな。 多値なら失敗(false)したら(undef, false)とundefみたいな値を返す方がいいと思う。 550 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 10:19:24 ] >>544,547 続けるなよ…… 551 名前：519 mailto:sage [2007/09/08(土) 14:09:14 ] >>536 ちょっと待て、ほとんど俺が書いたコードじゃねえかそれ。 ちなみに、おれじゃねえぞ。そのblog 552 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 14:18:22 ] >>549 undefがnullとどう違うのかわからん 553 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 15:06:37 ] >>552 お前はそもそもnullは何をモデル化したと考えてるんだ？ 554 名前：かつのり mailto:sage [2007/09/08(土) 16:03:23 ] 本人降臨っす。 >>519 実験用にパクらせていただきましたｗ ちなみにStringUtils.isNumeric()は微妙ですね。 Integer.parseIntの高速版とするなら、 Integerとしての要件を満たさなければいけません。 正規表現のパターンを予めキャッシュしておいて、 そのパターンでマッチングするのが一番早いのかな。 555 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 16:29:24 ] NumberUtils#isNumberもあるけどlong型とかでも判定しちゃうな 556 名前：519 mailto:sage [2007/09/08(土) 17:34:45 ] >>554 ああ、バッチでファイル読む時は俺もそうしてるなぁ どうせ桁数制限とか入る事が多いし 557 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 17:52:06 ] Patternのcompileってホントにコンパイルしてるの？ 558 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 18:01:25 ] >>557 コンパイルの意味を、パースして実行用データ作っとくって意味なら、コンパイルしてるんじゃねぇの？ 559 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 18:21:18 ] たしかに最適化オプション付きであるとはいってないからね。 Strategyパターンとか駆使してガチガチに最適化されたPatternを返して欲しいとこだ。 560 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 19:03:46 ] Javaの正規表現はDFAでしょ？確か。 DFAはバックトラックしなくていいから、 最適化は高速化ではなく使用メモリのレベル。 遷移テーブルとかその辺。 下手な自前のマッチングコードを書くより早いよ。正規表現は。 561 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 19:55:04 ] >>560 Javaの正規表現はNFA。実装読んでみるべし。 最近の言語に組み込みの正規表現ライブラリの多くはNFA(または その変種)を採用してる。理由はNFAじゃないと扱いづらい機能 (後方参照など)があるため。 562 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 19:56:36 ] ちなみに各言語における正規表現ライブラリの実装がどのように なっているかの概要を知りたい場合は、詳説正規表現がオススメ 563 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 22:35:20 ] >561 そか。情報サンクスコ 564 名前：デフォルトの名無しさん mailto:sage [2007/09/09(日) 19:28:16 ] DFAじゃあ不便すぎる。 565 名前：デフォルトの名無しさん mailto:sage [2007/09/09(日) 21:49:32 ] DFAはNFAから変換できるけど、NFAにしておく意義としては、 NFAのまま何かの機能を追加するってこと？ バックトラックする際に後方参照も同時にサポートするためなのか。 566 名前：デフォルトの名無しさん mailto:sage [2007/09/09(日) 22:28:17 ] >>560 > 下手な自前のマッチングコードを書くより早いよ。正規表現は。 んなわけねーだろ。正規表現遅すぎだ。計測してねーだろ。 ただ、Web アプリとかでせいぜい項目が数百程度の 入力チェックや変換程度なら速度差は計測不能。 567 名前：デフォルトの名無しさん mailto:sage [2007/09/09(日) 22:41:57 ] >>566 単純な文字パターンの検証なら正規表現の方が遅いだろうけど、 ごく一般的な業務システムプログラマが、 自前で複雑な検証コードを書くよりは速い。 きちんとロジックを書ける人なら速いんだけど。 568 名前：デフォルトの名無しさん mailto:sage [2007/09/09(日) 23:18:56 ] 文脈的に parseInt でパーズ成功/失敗を予め判定するためのコードでしょ。 >>554が言うように Intergerとしての要件を満たす、 文字列が数字で構成されてるかだけじゃなくて最大値や最小値チェックもするなら 正規表現つかうより自前でやった方が早く書けるんじゃねーの？ 569 名前：デフォルトの名無しさん mailto:sage [2007/09/09(日) 23:23:20 ] 最大値や最小値をチェックする時点で、成功/失敗を予め判定するどころか、すでに値が求まってる気がする 570 名前：デフォルトの名無しさん mailto:sage [2007/09/09(日) 23:56:08 ] >>566>>567>>568 >>560は正規表現エンジンがDFAで実装されてる場合の 話をしてると思うよ。その場合なら、下手に自前の コード書くより早いというのは間違いでもなんでもないよ 571 名前：デフォルトの名無しさん mailto:sage [2007/09/10(月) 00:01:33 ] > ちなみにStringUtils.isNumeric()は微妙ですね。 > Integer.parseIntの高速版とするなら、 > Integerとしての要件を満たさなければいけません。 だからなぁ…… 最大値/最小値チェックしないなら ほとんどStringUtils.isNumeric()で用足りるんじゃね？ 572 名前：デフォルトの名無しさん mailto:sage [2007/09/10(月) 00:01:37 ] >>565 そういうこと。NFAのままにしておけば、「非正規な」機能である後方参照 やその他もろもろ、比較的容易に追加できる 573 名前：デフォルトの名無しさん mailto:sage [2007/09/10(月) 00:13:43 ] >>569 例外使わないだけで 100倍程速くなるそうだから、 変換処理が 2回やる事によって 2倍の時間かかっても大した問題じゃないんじゃね？ まぁ、場合によっては大した問題になるかもしれんが。 そんなん問題になってから考えりゃいいっしょ。 574 名前：デフォルトの名無しさん mailto:sage [2007/09/10(月) 01:42:54 ] 正規表現使うほうが１００倍速いよ。実装が。 575 名前：デフォルトの名無しさん mailto:sage [2007/09/10(月) 20:17:24 ] C#の正規表現はグループに名前を付けられるみたいだね 576 名前：デフォルトの名無しさん mailto:sage [2007/09/10(月) 21:14:45 ] >>574 StringUtils.isNumeric()では足りない部分までIntegerの要件を満たすかチェックするんだったら 正規表現でやるのは面倒くさそうだが。 577 名前：デフォルトの名無しさん mailto:sage [2007/09/10(月) 22:50:21 ] 正規表現のスレでやれよ。ここには関係ないから。 578 名前：デフォルトの名無しさん mailto:sage [2007/09/10(月) 23:04:10 ] >>576 桁数制限してIntegerの半分以上の範囲捨てるなら簡単だけどな 579 名前：デフォルトの名無しさん mailto:sage [2007/09/12(水) 00:32:10 ] >>575 正規表現のマッチング処理高速化のためにコンパイルすると、 メモリリークするとかＭＳＤＮのドキュメントに書いてあるけどな。 580 名前：デフォルトの名無しさん mailto:sage [2007/09/12(水) 00:53:38 ] >>579 それドトネト1.1のころの制限じゃない？ 581 名前：デフォルトの名無しさん mailto:sage [2007/09/15(土) 10:08:16 ] なんと言う次世代 582 名前：デフォルトの名無しさん mailto:sage [2007/09/15(土) 10:59:42 ] 次世代試作機・・・。 583 名前：デフォルトの名無しさん mailto:sage [2007/09/15(土) 13:48:51 ] Javaを拡張するのではなく、OSを拡張するというのはJSRにならんのかね？ 例えばjinputをJava標準にするための下地にするためにとか。 584 名前：デフォルトの名無しさん mailto:sage [2007/09/15(土) 14:16:31 ] JDK7 build20 download.java.net/jdk7/binaries/ download.java.net/jdk7/changes/jdk7-b20.html 585 名前：デフォルトの名無しさん mailto:sage [2007/09/15(土) 19:49:01 ] そういやjdk7が出来たらOpenJDK6をOpenJDK7ベースで再構築してOpenJDK6をGPL2で配布するらしいな。 将来的には公式バイナリも完全にOpenJDKからビルドするらしい。 586 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 12:58:01 ] ７は変な機能増えすぎ もっとシンプルに保てよ 587 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 13:16:10 ] クロージャというか関数導入するならperl見たいな複数戻り値の関数もできるようにしてくれ 588 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 14:09:47 ] 多値返せたらいいのにと思うことはよくある 589 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 15:38:35 ] 時々、妙に多値希望の人っているよね そういう人はロートルだと思っておｋ？ 590 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 15:39:53 ] 多値が返せる言語ってあるの？ 591 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 15:44:03 ] Perlしかしらない。 ただstateとvalueみたいな多値が欲しいがために ReultFooみたいなクラスを書くのはなんだかなぁと思うときは多い。 592 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 16:23:13 ] lispまでいくと多値というよりリストか Object[]のシンタックスシュガーで十分なんだけどな C#のstructなんかよりずっと有用 593 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 17:16:56 ] pythonのtupleみたいなの。 まあ、Object[]でもいいけど。 >>591みたいな 型に名前つけるのが面倒なんだよ。 594 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 19:17:12 ] Pair<A, B> みたいなクラスを作って使いまわすとか 595 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 19:48:49 ] 最近は多値返せる言語増えたよ。 javaだとどうせバイトコードレベルでは配列になるんだろうね。 596 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:16:58 ] public const<String, Boolean> getResult() { return const { "おｋｗｗｗｗ", true }; } こんな感じで死にキーワードを流用できないものか 597 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:20:27 ] >>596 それだったら Pair<A, B> で良いじゃん。 598 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:26:16 ] 普通のGenericsは可変長じゃねー 599 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:36:13 ] じゃ、 static <A, B> Pair<A, B> tuple(A a, B b) static <A, B, C> Triple<A, B, C> tuple(A a, B b, C c) static <A, B, C, D> Quadruple<A, B, C, D> tuple(A a, B b, C c, D d) みたいにすれば？ 600 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:49:41 ] こらこら。Javaにrefやoutはないでしょ。 尤もCommonsLangあたりにはあっていいクラスだとは思うけど 601 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:52:29 ] ref や out って、どこの話だ？ 602 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:52:37 ] 多値よりも Ref<T> のほうがまだ使い勝手が良さそうな気がする。 603 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:53:37 ] ああ、ファクトリメソッドか、俺の勘違い。 >>601 C# 604 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:55:55 ] >>603 いや、レス番の話。 このスレのどこで ref や out の話が出てんのか、と。 605 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:57:38 ] 俺が>>601をクラス定義と勘違いしただけだって。 606 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:59:21 ] あ、>>599ね。あかん、おねむの時間っぽい。 607 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:03:13 ] >>599 にも ref や out があるようには見えんが…… 608 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:04:09 ] どう勘違いしたのかくらい考えろ馬鹿ちん 609 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:07:16 ] なんだ、勘違いか。なら考えても無駄だな。 610 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:09:24 ] 遅かれ速かれ多値はサポートしてくれるものと思いたい。 611 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:10:54 ] JVM系LLで多値サポートしてたら、そっち使えって話になるんじゃね？ 612 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:15:23 ] var rand = new Random(); int n = rand.nextInt(); みたいな書き方も需要あるから、多値もJSRには上がるとは思う。 613 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:17:32 ] bugs.sun.com/bugdatabase/view_bug.do?bug_id=4222792 will not be fixed になってる。 614 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:23:36 ] >>612 どうだろね？ 型推論ですら、変数宣言時の型指定を省くのは Java 的じゃないってんで G<T> g = new G(); みたいに、初期化子の方のパラメタ型指定を省けるようにしようって 論調の方が強いみたいだけど。今までの G<T> g = factoryOfG(); みたいな型推論とも一貫性あるってのが良いらしい 615 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:28:40 ] G<T> g = new(); みたいなのもどっかで見たな。 616 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:31:31 ] 極力interfaceで受け取れいうてる今までとの親和性の問題もあるし、 今後の拡張はローカルキーワードで行きたいって思惑もあるから 早い段階でサポートするならそっちかもな >>615 みたけど流石にそれはないｗ 617 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:42:13 ] varの方はGraphicsEnvironment.getLocalGraphicsEnvironment()とか長すぎるから何とか汁って考えもあったはず 618 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:47:32 ] >>617 つ static import 619 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:49:48 ] staticじゃなきゃ役にたたねーけどね 620 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:52:21 ] メソッド名が長いのはメソッド名のalias導入とかせんと解決せんのでは？ 621 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:54:22 ] 関係ないけど、メソッド名ってたしか長さ制限あったよね 622 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 22:00:53 ] static importはユーティリティメソッドに 沢山依存してる状態じゃないと返って面倒なだけ 623 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 22:05:31 ] 名前空間が汚れる。 624 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 22:06:13 ] まあ、結局のところD言語はvarで解決としたみたいだからJavaもそうなるよ。 プロパティ問題も馬鹿なことやらないで、素直にC#風にしたしね。 625 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 22:26:52 ] > プロパティ問題も馬鹿なことやらないで、素直にC#風にした ソースは？ 626 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 23:43:33 ] >>590 Common Lisp, Scheme(R5RSから) (define (foo) (values 1 2)) (set!-values x y (foo)) (set!-values q r (quotient&remainder 10 3)) スタックフレームの返値を格納するスロットが一つ増えるだけだから、 tupleやlistやarrayを箱にする方法より性能がいい。 627 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 00:01:39 ] >スタックフレームの返値を格納するスロットが一つ増えるだけだから、 それやると VM の変更が必要にならんか？ > tupleやlistやarrayを箱にする方法より性能がいい。 その辺の性能あげるためにエスケープ解析とか頑張ってるんじゃね？ 628 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 00:02:35 ] >>627 VMの変更っつーか、VM仕様の変更じゃね？

---

---

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

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