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

1 名前：デフォルトの名無しさん [2008/01/03(木) 12:29:37 ] 前スレ [Java SE 7] 次世代Javaの動向 5 [dolphin] pc11.2ch.net/test/read.cgi/tech/1178925915 [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/ 577 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 22:10:25 ] javax書き換えられないようなsuperpackageはいらない、Sunの失態が無いなら良いけど 578 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 23:00:42 ] ↑ん？どういうこと？ 579 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 23:01:12 ] >>575 C#に洗脳されすぎｗ 580 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 23:03:18 ] クラスとかメソッド名が長いってだけなら、ビルダークラスとかを継承してオーバーライドして自分で短い名前にしてくれよ。 それぐらい頭使え。 581 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 23:12:34 ] void hoge(a){actionPerformed(a);] で、短いメソッド名で実装して、それを呼び出すことね。 582 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 23:26:28 ] indexerって普通の英語なんだが。 583 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 23:30:00 ] Javaじゃそんな言葉使わんしここ日本。 584 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 23:31:02 ] 普通の英語って事は「索引を作る人」って意味で使ってるとか？ 585 名前：デフォルトの名無しさん mailto:sage [2008/03/13(木) 00:02:39 ] >>583 お前は日本語でプログラム書くのか？ 586 名前：デフォルトの名無しさん mailto:sage [2008/03/13(木) 00:16:46 ] 演算子オーバーロードが言語仕様にあれば Javaでもインデクサって普通に呼ぶだろうね。 Javaもinterface経由で演算子オーバーロードに対応したらいいのに。 AppendableとかCalculateableみたく、目的を明示すれば設計者も馬鹿しないでしょ。 587 名前：デフォルトの名無しさん mailto:sage [2008/03/13(木) 00:21:01 ] 演算子オーバーロードは絶対にサポートしないといってたけど。 588 名前：デフォルトの名無しさん mailto:sage [2008/03/13(木) 00:28:40 ] >>585 いやいや、言いたいのは話をわざわざ分かりにくくするために英語にする必要はないだろうということ。 589 名前：デフォルトの名無しさん mailto:sage [2008/03/13(木) 00:33:24 ] C#ちゃんはいいかげんに巣に帰れよ 590 名前：デフォルトの名無しさん mailto:sage [2008/03/13(木) 02:05:45 ] インデクサくらい理解してやってくれ。 ループ抽象(拡張for) コントロール・インヴォケイション・シンタックス は過激に便利ですよ。>>539のp4-6見てください。 プログラム構造がかなりすっきりまとまります。 プログラム内でのコードの共通化も進みますし。 591 名前：デフォルトの名無しさん mailto:sage [2008/03/13(木) 03:43:59 ] ↑もうこなくていいから。死んでくれ 592 名前：デフォルトの名無しさん mailto:sage [2008/03/13(木) 06:40:12 ] 病的な過剰反応だな。明らかにネットに向いてない。 593 名前：デフォルトの名無しさん mailto:sage [2008/03/13(木) 14:00:38 ] >>592 おまえも 594 名前：デフォルトの名無しさん mailto:sage [2008/03/13(木) 21:56:17 ] >>561 別に相性は悪く無いと思う 以下のような感じでstatic importでtypedefを取り込めるような仕様にしておけば 問題無し -- A.java -- package a; public class Alias { type FileName = String } -- B.java -- import a.Alias._; public class B { public static java.io.RandomAccessFile open(FileName name) { .... } } 595 名前：デフォルトの名無しさん mailto:sage [2008/03/13(木) 22:49:58 ] >>594 それをやるには static import とは別の仕組みが必要になるし、 どうせやるなら class Alias みたいなものをヘッダファイルモドキとして使うのは間抜けすぎる。 596 名前：デフォルトの名無しさん mailto:sage [2008/03/13(木) 23:59:35 ] >>595 それ言っちゃおしまいでしょ。 java.lang.Math とか java.util.Collections とか、 クラス外にメソッド置いとけるんならクラス外に置きたいようなのは標準APIにも多いし。 Java でやるなら >>594 みたいなやり方しかないと思うけどね。 597 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 00:01:58 ] >>562 > 型推論と似てるけど、型推論は動的にやるでしょｗ MLなどの型推論はコンパイル時に静的にやるよ。 動的だったら、型を推論するまでもなくチェックすればいい。 >>567が言っているような、 generics使って汎用に書かれたクラスに、 具体的なクラスを与えて、新たなクラスとしてpublicにする、 って機能は必須だと思う。 ただconcept(C++), type class(haskell)のような形の方が より汎用でスマートだと思う。単なるエイリアスじゃなくて 両クラスのグルーとなるコードも加えられるし。 598 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 00:05:28 ] >>596 クラス外メソッド定義とクラスエイリアスは別件。 599 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 00:15:29 ] >>598 クラス外メソッド定義したいって言ってるんじゃなくて 言語仕様が許すなら必ずしもクラス内に置く必要ないエイリアスやメソッドを クラス内に置かなきゃいけないのは等しくアレだって事 600 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 02:39:52 ] アノテーションでいいよ。機能的には違うけど、本質的に同じだし。 601 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 03:01:16 ] クロージャーなんて既存機能で十分まかなえるものの焼き直しなんかより もっと AOP 的設計が出来るようなアプローチしろよ。インスタンスフィールドへの アクセスもトラップできるようにすればそもそもプロパティ拡張もいらんだろが。 602 名前：デフォルトの名無しさん [2008/03/14(金) 03:44:37 ] クロージャで演算子オーバーロードもとラップできるといいけどな 603 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 05:49:16 ] > インスタンスフィールドへのアクセスもトラップできるようにすれば フィールドアクセスがめちゃくちゃ遅くなりそうだな 604 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 06:29:16 ] final 宣言されてない getter/setter と同等にできるだろ。めちゃくちゃの根拠が不明。 まぁプロパティアクセスに関しては「後で」「静的に」「他のソースを修正せずに」アクセサを 追加できれば十分だが。 605 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 06:51:54 ] また変な奴が常任してしまったな。 606 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 06:54:17 ] ＪＳ乙 607 名前：デフォルトの名無しさん [2008/03/14(金) 07:11:52 ] C#厨房よりはましｗ 608 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 07:28:45 ] というかおまえ誰だよ 609 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 07:33:04 ] 俺ビルジョイ 610 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 07:58:33 ] ＪＳじゃイニシャル違うじゃんかよ 611 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 10:58:17 ] >>604 そか？ 隠蔽されたフィールドに対するアクセスとかも考えたら プロパティモドキじゃ対応できないし馬鹿みたいにでかい仕組みが必要になると思うが。 612 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 12:18:31 ] JKが女子高生なんだからJSは・・・ 613 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 12:22:35 ] 専門学校生だよね 614 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 12:30:48 ] >>611 それだけなら何とかなると思うが…… もっとも、リフレクション対応までして「インスタンスフィールドアクセスのトラップ」 できるようにするより他の事にエネルギー使って欲しいぞ。 615 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 15:49:59 ] J 常識的に S ｾｯｸﾙして 616 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 16:03:51 ] >>611 現時点でも少なくともリフレクション程度は確保できる。 まぁフィールドアクセスはそれも包含できるという意味で引き合いに出しただけで本意は別。 ゴリゴリ書くしかなかったのを簡素化したいのはもっともだが、なら無名内部クラスより DI の標準様式一つでも考慮しろと。 617 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 16:14:40 ] > DI の標準様式一つでも考慮しろと。 ？ 618 名前：デフォルトの名無しさん mailto:sage [2008/03/15(土) 01:41:01 ] あれ？JFileChooserが遅いバグって6u5までのどこかで修正入った？ 619 名前：デフォルトの名無しさん mailto:sage [2008/03/15(土) 10:17:10 ] >>541 つーか選択肢は二つくらい(?)あって 　・クロージャから抜けるのみ ・・ >>540のコードなら、doSomething() が実行されないだけで for each は続く 　・for each の置かれているメソッドから抜ける 「JavaのクロージャはこれまでのListenerの構文糖衣だぜ」ってんなら 前者が選ばれるだろうなと思ってさ。 620 名前：デフォルトの名無しさん mailto:sage [2008/03/15(土) 10:19:34 ] >>619 > 「JavaのクロージャはこれまでのListenerの構文糖衣だぜ」ってんなら 違う。 621 名前：デフォルトの名無しさん mailto:sage [2008/03/15(土) 10:32:19 ] 匿名クラスの構文糖って言いたかったんかな 622 名前：デフォルトの名無しさん mailto:sage [2008/03/15(土) 11:45:56 ] クロージャのreturn周りはどうなるのかホントわかんないな。 ECMAScript風になるのか、ruby風になるのか。 623 名前：デフォルトの名無しさん mailto:sage [2008/03/15(土) 11:54:42 ] C#風に、内容に expression しか書けないクロージャ（ラムダ式）と、 statements が書けるクロージャの2種類作るってのもアリだと思うんだけど。 624 名前：デフォルトの名無しさん mailto:sage [2008/03/15(土) 11:54:49 ] どっちでもない 625 名前：デフォルトの名無しさん mailto:sage [2008/03/15(土) 12:41:25 ] ruby風はありえないだろ 何がどこに抜けるんだかバージョンによって変わるだなんて 626 名前：デフォルトの名無しさん mailto:sage [2008/03/15(土) 13:29:50 ] returnで脱出する最外レベルはメソッドであって、 クロージャやブロックではない。 詳しくは www.javac.info/closures-v05.html を読め。 627 名前：デフォルトの名無しさん mailto:sage [2008/03/31(月) 04:07:09 ] Listenerを登録するという設計自体がクロージャと相性が悪いわけか なんでこんな設計にしたんだ 628 名前：デフォルトの名無しさん mailto:sage [2008/03/31(月) 04:15:55 ] 他に手がないからだろ 629 名前：デフォルトの名無しさん mailto:sage [2008/04/01(火) 08:58:11 ] >>627 てか他に手は無いだろ 630 名前：デフォルトの名無しさん mailto:sage [2008/04/02(水) 02:03:03 ] >>627 相性が悪いって程でもないと思うが 確かBGGAでは、function typeをListenerに暗黙に変換するための 仕掛けが用意されるんじゃなかったっけか 631 名前：デフォルトの名無しさん mailto:sage [2008/04/02(水) 09:54:37 ] >>630 ActionListenerみたいにメソッド一個しか無い場合は変換できるけど、 BGGAには、MouseListenerみたいにメソッドいっぱいある場合の変換の仕掛けはないよ。 named inner methodがあるFCM と比べると、BGGAとXxxListenerは相性悪い。 632 名前：デフォルトの名無しさん mailto:sage [2008/04/02(水) 10:02:50 ] tronicek.blogspot.com/2008/03/method-references-version-2008-03-17.html method reference だそーです。 method reference に '#' 使うのが平気な感覚もってるのに accessing property に '.' 以外の演算子使うのってダメなんかねぇ…… と思ったり。 633 名前：デフォルトの名無しさん mailto:sage [2008/04/02(水) 10:50:41 ] listOfArgumentTypesは必要かね? 継承に絡まない型推論はしない主義だから必要になるのかな。 文脈は常に強く型付けされているはずだが。 634 名前：デフォルトの名無しさん mailto:sage [2008/04/02(水) 10:59:04 ] もう Method の静的解決 (Foo.class みたいな) でええやん。関数ポインタみたく使えりゃええんじゃろ。 635 名前：デフォルトの名無しさん mailto:sage [2008/04/02(水) 11:00:07 ] static import で listOfArgumentTypes 書けるようにしてくれませんかね？ 636 名前：デフォルトの名無しさん mailto:sage [2008/04/02(水) 19:35:24 ] >>633 本来なら通常は要らんと思うけど、同名のメソッドがオーバーロードされてる 場合必要になるから、必須にしてるんじゃないかな？ 637 名前：デフォルトの名無しさん mailto:sage [2008/04/02(水) 19:41:39 ] それは型情報で分かるから。 638 名前：デフォルトの名無しさん mailto:sage [2008/04/02(水) 20:49:02 ] >>634 ちがうよ。変数スコープが重要 639 名前：デフォルトの名無しさん mailto:sage [2008/04/02(水) 21:46:47 ] >>637 contravariant な変換許すなら、型情報だけから必ず判るわけじゃないから listOfArgumentTypes 省略しないタイプも必要だと思うぞ。 省略できても良いと思うけど。 640 名前：デフォルトの名無しさん mailto:sage [2008/04/02(水) 23:01:51 ] >>637 (System.out#println(String)).invoke("Foo") みたいな場合を考えると必要なケースもあるよってこと もちろん、必要じゃないケースもあるから省略はできてもいいと思う もちろん、上のような式を実際に書く必要はないだろうけど、文法上 書けるなら対策は必要になるわけだ 641 名前：デフォルトの名無しさん mailto:sage [2008/04/09(水) 23:28:18 ] そろそろjdk1.7はリリースされるの？ 642 名前：デフォルトの名無しさん mailto:sage [2008/04/10(木) 00:19:26 ] 来年の始め頃じゃないか 643 名前：デフォルトの名無しさん mailto:sage [2008/04/10(木) 00:27:41 ] 1.6updateN が出てから 1年ぐらいは必要じゃないかと思うが 644 名前：デフォルトの名無しさん mailto:sage [2008/04/10(木) 09:45:57 ] なんだ。まだか。 645 名前：デフォルトの名無しさん mailto:sage [2008/04/10(木) 21:34:28 ] Java7からと思ってたが、Java KernelはUpdate Nから入るのね。 JMFあたりも自動ダウンロードしてくれるならありがたい限りだけどどうだろ。 646 名前：デフォルトの名無しさん mailto:sage [2008/04/18(金) 12:48:24 ] JDK7 build25 download.java.net/jdk7/changes/jdk7-b25.html download.java.net/jdk7/binaries/ 647 名前：デフォルトの名無しさん mailto:sage [2008/04/19(土) 06:58:13 ] クロージャーなんかよりも、入出力ストリームや Lock 使った try-finally 使いまくりのコードを きれいに書ける構文考えてくれよ。synchronized と違和感ないような (これもブロック抜けるときに モニタ開放するし)。 try(Writer out = new FileWriter("foo.txt")){ 　　... } catch(IOException ex){...} ↓みたいな。二重tryでもいいや。 Writer out; try{ 　　out = new FileWriter("foo.txt")){ 　　... } catch(IOException ex){ 　　... } finally{ 　　try{ if(out != null) out.close(); } catch(IOException ex){throw new RuntimeException(ex);} } 648 名前：デフォルトの名無しさん mailto:sage [2008/04/19(土) 08:59:28 ] それは既に入る予定だが? しかもクロージャを使って。 649 名前：デフォルトの名無しさん mailto:sage [2008/04/19(土) 09:30:50 ] >>647 つ control invocation syntax 650 名前：デフォルトの名無しさん mailto:sage [2008/04/24(木) 14:22:07 ] 次のjava7でクロージャ以外で主要な目玉機能ってなんですか？ 651 名前：デフォルトの名無しさん mailto:sage [2008/04/24(木) 16:03:13 ] 俺はダグ・リー先生のjsr166y.forkjoinがどうなるかが最大の関心事 素晴らしすぎ。 652 名前：デフォルトの名無しさん mailto:sage [2008/04/24(木) 16:21:19 ] 今度の JavaOne で dolphin の進捗も発表されんじゃね？ 653 名前：デフォルトの名無しさん mailto:sage [2008/04/24(木) 17:00:32 ] クロージャ以外は特にないよ 654 名前：デフォルトの名無しさん mailto:sage [2008/04/24(木) 20:05:44 ] fork-joinはメニーコア時代の必需品になるだろうし重要だと思う。 そんな時代だと永続性ユニットとしてRDBMSだけじゃなく、 これとMemoryMappedFileあたりと組み合わせたやつとか使いそう。 655 名前：デフォルトの名無しさん mailto:sage [2008/04/24(木) 21:35:45 ] FileじゃなくてOODBください　＞＜； 656 名前：デフォルトの名無しさん mailto:sage [2008/04/27(日) 15:47:45 ] いつまでも実現しないMVMは？ 657 名前：デフォルトの名無しさん mailto:sage [2008/04/29(火) 15:06:35 ] JDK7 build26 download.java.net/jdk7/changes/jdk7-b26.html download.java.net/jdk7/binaries/ 658 名前：デフォルトの名無しさん mailto:sage [2008/05/04(日) 23:56:54 ] LINQみたいなのは、はいらんの？ quaereのような式言語っぽいやつじゃなくて言語実装として組み込まれてるのがほしい。 659 名前：デフォルトの名無しさん mailto:sage [2008/05/05(月) 00:12:37 ] スクリプト関連ほんとに追加されるのかな〜 660 名前：デフォルトの名無しさん mailto:sage [2008/05/13(火) 03:23:42 ] スクリプト関連は、やるだろうね。 Java一本が難しくなった今、他言語のサポートは急務 LINQみたいなのは、能力的に無理そう。 661 名前：デフォルトの名無しさん mailto:sage [2008/05/16(金) 19:50:57 ] method refarenceなかなかいいんじゃないの？ Integer#parseInt(String);のやつ 662 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 00:41:53 ] JavaFXをプッシュしてるけどSunは、まともなオーサリングツール作る気あるのか？ どう考えても負け戦な気がするんだけど。 663 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 01:24:56 ] 君にはまだ早すぎる。できる開発者だけの楽しみだしｗ 664 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 23:38:25 ] 負け戦は確定でしょ ただでさえ中心人物がどんどんやめていってるのに 665 名前：デフォルトの名無しさん mailto:sage [2008/05/21(水) 15:16:25 ] SUNは、開発者ごとJavaFXをGoogleにあげればいいと思うよ。 開発者のやる気も出るし、Android標準搭載になっていい事だらけだと思うぞ。 まあもらってくれないだろうが・・・ 666 名前：デフォルトの名無しさん mailto:sage [2008/05/21(水) 23:37:07 ] JavaFXって結局ブラウザの中でも実行できるんだっけ？ デモサイトを見てもブラウザ内で実行できるのが無いんだけど単にJavaFXのブラウザプラグインがまだ無いだけ？ 667 名前：デフォルトの名無しさん mailto:sage [2008/05/21(水) 23:43:12 ] 全部javaで書いてあります。> JavaFX 668 名前：デフォルトの名無しさん mailto:sage [2008/05/21(水) 23:47:01 ] えーとね、スクリプトをサポートする順番は、sunの発表では、rubyとかはあるけどFXは全く予定にないってところだった。 まだ熟してないんだよ。そーあせるなってｗ 669 名前：デフォルトの名無しさん mailto:sage [2008/05/22(木) 00:18:10 ] 熟すときは来るのか？ｗ 670 名前：デフォルトの名無しさん mailto:sage [2008/05/22(木) 07:10:25 ] SM次第でSMのシルバーなんとkがが市場を開拓すればおのずと、 知らないだろうけど、フォトランのsun風味とかもあるし、 671 名前：デフォルトの名無しさん mailto:sage [2008/05/23(金) 11:09:35 ] JDK7 build27 download.java.net/jdk7/changes/jdk7-b27.html download.java.net/jdk7/binaries/ 672 名前：デフォルトの名無しさん mailto:sage [2008/05/26(月) 12:02:22 ] JDK6でせっかく入れたTools APIはjava7のリッチクライアントプロファイルでは外されるんだな。 Tools APIってJDK6で入っただけでまだ標準ライブラリ化してないんだっけ？ 673 名前：デフォルトの名無しさん mailto:sage [2008/05/26(月) 12:09:04 ] >>672 リッチクライアントプロファイルからはjavacとか削るつもりなんだろ。 プロファイルによってはAWT/Swingみたいな標準ライブラリも削られる。 だからTools APIが削られる事と標準かどうかは関係ない。 674 名前：デフォルトの名無しさん mailto:sage [2008/05/26(月) 13:47:38 ] プロファイルはJREの話だからjavacがないのは元からだ。 toolsAPIはJREのrt.jarに入ってるから削られる。 675 名前：デフォルトの名無しさん mailto:sage [2008/05/26(月) 14:18:04 ] >>674 このスレの主だから。こいつは、なんつーか傲慢で非常にひねくれた性格なのよｗ 確かageたりすると、こいつ、すぐ発狂するからｗｗ 676 名前：デフォルトの名無しさん [2008/05/26(月) 14:20:08 ] ＞プロファイルによってはAWT/Swingみたいな標準ライブラリも削られる。  だからTools APIが削られる事と標準かどうかは関係ない。 この「だから」ってのはどうつながっていて、標準ライブラリとTools APIとどういう風に「関係がない」のかちゃんと説明できるの？ 偉そうに適当な事ばかり言ってないでさ 677 名前：デフォルトの名無しさん mailto:sage [2008/05/26(月) 14:39:12 ] AWT/Swingが削られるのはヘッドレスプロファイルだろ。サーバーサイド向け。 けどjava2Dの一部ってAWTだよな・・・。

---

---

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

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