[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/ 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仕様の変更じゃね？ 629 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 00:07:16 ] >>625 docs.google.com/View?docid=dfhbvdfw_1f7mzf2 これの事じゃね？ でも、これbeansのプロパティと互換性ないし、 フィールドとプロパティの名前がかぶった場合どうなるかって部分も甘いような。 630 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 12:14:51 ] 多値はいつか実現して欲しいね。 引数は0個以上なのに、結果は0か1に制限されているのは不便。 >>589 他の言語で使うと癖になるから、粘着的なw要望が続くんだと思う。 631 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 12:20:52 ] >>630 なんつーか、Perlとかで初めてsplitの結果を複数の変数に まとめて入れる表現見たとき便利だと思ったわけで、 こういうのって、返値は配列として扱ってるじゃない。 配列の返値を、各変数に代入するシンタックス糖分があればいいんじゃないかな？ 632 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 13:34:05 ] > スタックフレームの返値を格納するスロットが一つ増えるだけ > 配列の返値を、各変数に代入するシンタックス糖分があればいい この二つって全然別の要求なわけで…… 633 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 13:35:18 ] >>630 粘着的な要望する奴は口だけ動かして手を動かさんからなぁ…… 634 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 14:09:07 ] >>632 多値って一口に言っても、考えてる事が微妙に違うからなぁ…… 635 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 14:49:27 ] とりあえず配列でやっておけばいいんじゃないの？ 636 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 14:52:17 ] >>635 Object[]を使えばいいじゃんって意味？その場合、複数種類の型を内包する配列を扱うことになるから、 言語的なサポートが欲しいって言ってるんじゃない？ 637 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 14:53:20 ] >>633 このスレに要望出しても意味ねえんだけどな 638 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 14:54:47 ] 型の問題があるなら、引数のほうに値をうけとる配列として渡すとかね。 639 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 14:58:05 ] >>637 要望だした時点で気持ちよくなってんじゃないかと。 要望を実現する事よりも、気持ちいい事の方が重要なんじゃね？ 640 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 15:48:10 ] ゆとりのやつって、直接的な効果がなければ意味ねぇとかよく言うよね。 間接的な効果を想像できないんだよね。 641 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 15:53:01 ] あるあるｗ ちょっとたとえを出して、それを否定できただけで、全てを否定ｗ 642 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 15:53:48 ] 間接的な効果に期待（するだけ）しかできないんだったら > 要望を実現する事よりも、気持ちいい事の方が重要なんじゃね？ って評価は正しいような。 643 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 17:26:43 ] はいはい、ここは次世代Javaのスレですよっと JSR-310 に generics版なるものが出来ていた。 https://jsr-310.dev.java.net/nonav/generics/index.html https://jsr-310.dev.java.net/servlets/ReadMsg?list=dev&msgNo=726 > The basic theory is to define a class for each of the basic concepts - > Day, Month, Year, Hour, Second etc, and then utilise those in other > ways. These are TimePart subclasses. > > Instead of having a dedicated Seconds class that holds only seconds, > there is a single TimeAmount class that is generified: > > Standard design: >　 Seconds s = seconds(3); > Generics design: > 　TimeAmount<Second> s = seconds(3); > > Similarly, the field classes such as DayOfMonth are removed with a > single generified TimeField class: > > Standard design: > 　DayOfMonth dom = dayOfMonth(3); > Generics design: > 　TimeField<Day, Month> dom = dayOfMonth(3); 個人的に generics版にするなら var dom = dayOfMonth(3); タイプの型推論が欲しいような。 644 名前：デフォルトの名無しさん [2007/09/17(月) 20:18:05 ] blogs.wankuma.com/kacchan6/archive/2007/09/17/96592.aspx 645 名前：デフォルトの名無しさん mailto:sage [2007/09/18(火) 08:41:40 ] generics版は、入力めんどすぎだな 646 名前：デフォルトの名無しさん mailto:sage [2007/09/18(火) 16:45:33 ] ドキュメント簡潔で理解しやすいしこっちのほうが好きなのは俺だけか それはそうと９月の第三月曜日とか毎月第五土曜日（と、第五土曜日が存在するかチェックする方法）とか どうやって入力するんだろう？ この程度のことがいちいち煩雑なのは嫌なんだけど。 曜日指定できそうなCalenderDayのDayOfWeekは引数がなぜかint型だし。 曜日関係はまだまだこれからなのかね？ 647 名前：デフォルトの名無しさん mailto:sage [2007/09/18(火) 20:37:07 ] あれだ。 カレンダー用のXPathみたいなの作って W3C標準にすればいいんじゃね？ 648 名前：デフォルトの名無しさん mailto:sage [2007/09/18(火) 21:04:02 ] CQL CalendarQueryLanguage ばばーん >>647 がただ今鋭意作成中です 649 名前：デフォルトの名無しさん mailto:sage [2007/09/18(火) 23:12:45 ] >>647 Structured Calendar And Time Markup Language 略してSCATML。それのAPIがSCATMLAPI。 650 名前：デフォルトの名無しさん mailto:sage [2007/09/18(火) 23:19:52 ] 31日や2月29日みたいなTimeFieldやTimeViewって カレンダーが背後にあるクラスに受け入れられるまで、意味のあるカレンダーデータかどうかわかんないわけだよな。 ついでにPeriodを加算するみたいな日付計算もできない。 それなら『カレンダーが背後にあるクラス』をインターフェース化しておいたほうがいいんじゃないかと思ったり。 最初はCalendricalがそうかと思ったんだけどなんか違うっぽいな。 651 名前：デフォルトの名無しさん mailto:sage [2007/09/18(火) 23:54:39 ] やっぱCalendricalか。何故かTimeViewやTimeFieldに継承されているけどこれは何かの間違いだな。 weekOfMonthが作れるようになったりTimeField同士を結合してTimeViewを作ったりできねえかな。 そしたら今年の９月の第３月曜日とかでも楽に指定できるのに。難しいのかこれは。 652 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 00:00:02 ] TimeAmountで期間データの変換が相互に可能になってるっぽいが Second〜DayはともかくDay〜Foreverのデータはカレンダーないと変換できないような。 いちいちUnsupportedOperationException投げるつもりかいな 653 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 02:32:47 ] こんな感じで書けないかな static import javax.time.Moments.* ... TimeView<Day,Year> leapyearday = build(MonthOfYear(2), dayOfMonth(29)); CarenderYear year = now().currentYear(); List<CalenderDay> lyds = new ArrayList<CalenderDay>(); for(int i = 0; i < 10; i++){ 　　CarenderDay tmp = CalenderDay(year.plus(i), leapyearday); 　　if(!tmp.wasRolledGenerate()) 　　　　lyds.add(tmp); } 654 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 02:54:46 ] >javax.time.Moments.* パッケージ名だけ見たらとてつもなく抽象的すぎて何に使って良いかわかりづらいな。 655 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 03:17:56 ] TimeUtilsとかの方がいいよな。常識的に考えて。 そのうち変わると思うが 656 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 11:16:37 ] >>654 time.Momentsってそんなにわかりにくいかな？ 657 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 13:15:14 ] 個人的にクラス名変えるならこんな感じ 時刻系 TimeView＞TimeExpression：時刻表現 Calendrical＞ScaledTime：カレンダー評価済み時刻表現 TimeField＞TimeField：即値時刻表現 期間系 Period＞Period：期間 TimeAmount＞PeriodField：即値期間 単位系 TimePart＞Unit：単位 その他 Moments＞TimeUtils：ユーティリティクラス うーん、イマイチ。 658 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 16:48:46 ] クラス名・変数名に迷ったら書き込むスレ。Part10 ttp://pc11.2ch.net/test/read.cgi/tech/1180146315/ ここにお願いしてみては 659 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 18:46:41 ] >>656 今のクラス名だと高精度の時間取得APIとも取れるし、時系列系APIのフレームワークとも取れる。 名前から想像できる用途が曖昧で冗長といった印象。 名前からすると一見汎用性がありそうだけど、 けど中身はカレンダーAPIの上位API程度の印象も受ける。 そのため、今のカレンダーAPIとの関係も分かりづらい。 そうなると移行や使い分けが難しいかと。 要するに何のために作ったのか分からん、と・・・。 660 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 19:01:06 ] どう見ても完全に置き換えるものとして使うようにできてるだろ。 互換性を意識しないといけない場合以外は全部移行していいようにするんじゃないのか？ まだOverViewには入ってないがフォーマッティングやパーシング用のクラスも作るらしいし。 661 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 19:22:46 ] java.util.concurrent.TimeUnit も忘れないであげて 662 名前：デフォルトの名無しさん mailto:sage [2007/09/21(金) 13:05:43 ] JSR 277とJSR 291は議論が熱いね。 www.infoq.com/jp/osgi 663 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 10:54:13 ] OSGi関係は熱そうだね。 関わってるところ多いし、影響が大きそう 664 名前：デフォルトの名無しさん mailto:sage [2007/09/24(月) 18:48:55 ] JDK7、機能はすごい魅力的なんだが、リリースが一年以上先か・・・。 堅実なのはいいことだけど、もうちょっと早くならんかなあ。 665 名前：デフォルトの名無しさん mailto:sage [2007/09/25(火) 01:28:48 ] 目玉機能とされてるJSR-277もまだだし Closureに至ってはJSRすらないしなぁ。 これでリリースまでに全部つっこんできたら十分早いと思うが。 666 名前：デフォルトの名無しさん mailto:sage [2007/09/27(木) 22:46:13 ] 業界的にはまだバージョン4が多数だから早い感じもする。 667 名前：デフォルトの名無しさん mailto:sage [2007/09/28(金) 00:51:19 ] テンプレート(1.5)、クロージャ(1.7)とくれば、最後に来るのは…マクロ！(1.9予定) すべての言語は最後はlispの一部を再実装する事になるのかと思うと、複雑な気分だな。 668 名前：デフォルトの名無しさん mailto:sage [2007/09/28(金) 01:00:50 ] バージョン4なんかない。 669 名前：デフォルトの名無しさん mailto:sage [2007/09/28(金) 02:22:08 ] >>668 R4のことだろ？ 670 名前：デフォルトの名無しさん mailto:sage [2007/09/28(金) 04:08:52 ] RhinoR4？ライセンスが・・・ｗ 671 名前：デフォルトの名無しさん mailto:sage [2007/09/28(金) 10:11:40 ] 最後はevalだな。 672 名前：デフォルトの名無しさん mailto:sage [2007/09/28(金) 11:10:22 ] OSGiじゃないのか？ 673 名前：デフォルトの名無しさん mailto:sage [2007/09/28(金) 14:32:28 ] JDK7 build21 download.java.net/jdk7/binaries/ download.java.net/jdk7/changes/jdk7-b21.html だって。 ようやくコンパネの縦長が直った。

---

---

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

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