[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/ 752 名前：デフォルトの名無しさん mailto:sage [2008/07/11(金) 05:27:30 ] >>749 戻り値が違う場合？ 俺の場合はその戻り値の型を同行する前に 自分で型を作って、二つの型に共通するスーパークラスを 作るにふさわしいかどうかを考えるがな。 そうはいかないときもあるが、そういうときは 根本的に設計上の問題があると考えられる。 デザインパターンを考慮するときはとくに。 753 名前：デフォルトの名無しさん mailto:sage [2008/07/20(日) 00:18:11 ] JDK7 build31 download.java.net/jdk7/changes/jdk7-b31.html download.java.net/jdk7/binaries/ 754 名前：デフォルトの名無しさん mailto:sage [2008/07/21(月) 16:51:54 ] >>752 (String , Map) こんな二つの結果が帰ってくるときなら、Superclassも何も無いと思うが・・・ 755 名前：デフォルトの名無しさん [2008/07/22(火) 21:55:05 ] TextSS 756 名前：デフォルトの名無しさん mailto:sage [2008/07/23(水) 07:28:02 ] mail.openjdk.java.net/pipermail/closures-dev/2008-July/000180.html > Closures and XML support in Java 7 are unlikely. だってよ、どーするよ。 757 名前：デフォルトの名無しさん mailto:sage [2008/07/23(水) 08:28:01 ] んん？ unlikelyって・・・見込みがないってこと？ 758 名前：デフォルトの名無しさん [2008/07/23(水) 09:03:58 ] 実装するのは思いのほか大変だってこと。 759 名前：デフォルトの名無しさん mailto:sage [2008/07/23(水) 09:17:18 ] >>758 実装は www.javac.info/ から取ってこれるが。 どっちかっつーと技術的な問題じゃなくて政治的な問題でしょ。 google も www.javac.info/google-position.html みたいに及び腰だし。 760 名前：デフォルトの名無しさん [2008/07/23(水) 09:48:43 ] 実装という書き方が悪かったね。 今までのJava(Cの延長）からすればたいぶ異質なパラダイムを入れるのに抵抗があるので、思いのほか大変って意味。 761 名前：デフォルトの名無しさん mailto:sage [2008/07/23(水) 09:57:18 ] そういうことかー 英語弱いんで助かりました。 762 名前：デフォルトの名無しさん mailto:sage [2008/07/23(水) 09:58:55 ] >>760 パラダイムとか関係ないでしょ。 Javaにclosure入れるっていう根本方針に反対な人が多数派ってんならともかく。 763 名前：デフォルトの名無しさん mailto:sage [2008/07/23(水) 10:00:18 ] > Java 7 itself is starting to seem unlikely ;-) orz 764 名前：デフォルトの名無しさん mailto:sage [2008/07/23(水) 10:05:11 ] genericsの時もやたらと遅れたし大規模に言語変更するときはJSRみたいな委員会型の組織だと動き鈍くて大変だよね 765 名前：デフォルトの名無しさん mailto:sage [2008/07/23(水) 10:07:56 ] ぽんぽん尻軽に大規模な言語変更されても困るからしかたない 766 名前：デフォルトの名無しさん mailto:sage [2008/07/23(水) 10:14:55 ] 小規模な言語変更だとぽんぽん尻軽にやっちゃうんだけどね。 assert とか勝手に予約語に追加しやがるし。 767 名前：デフォルトの名無しさん [2008/07/23(水) 12:43:43 ] assertが予約語で何か不満でもあるのか？ 768 名前：デフォルトの名無しさん mailto:sage [2008/07/23(水) 12:55:23 ] >>767 JUnitで使われてた assert って名前のメソッドが改名させられたのは有名な話。 enum って変数名使ってて泣いた奴も案外多かったりして。 769 名前：デフォルトの名無しさん [2008/07/23(水) 13:33:48 ] それならC#の方が凄いんじゃないの？ 770 名前：デフォルトの名無しさん mailto:sage [2008/07/23(水) 13:38:08 ] enumは多かったな 771 名前：デフォルトの名無しさん mailto:sage [2008/07/23(水) 13:40:21 ] >>768 ﾉｼ 772 名前：デフォルトの名無しさん [2008/07/23(水) 15:00:16 ] >>755 www.vector.co.jp/vpack/browse/pickup/pw5/pw005236.html 773 名前：デフォルトの名無しさん mailto:sage [2008/07/23(水) 15:36:24 ] >>759 googleは時期尚早としか書いてないけど、 > To arrive at the best solution, Google is open to multiple parallel investigations > but is not currently prepared to commit to any particular proposal. というのは、もしかしたら、data parallelがやりやすいかどうか、 良く確認してから決めたいと考えているのかな。 774 名前：デフォルトの名無しさん mailto:sage [2008/07/23(水) 19:41:05 ] >>773 BGGA の初版から 2年、BGGA のver 5出てからもう 1年近くたってるし 未だに時期尚早ってのはなぁ…… Java7 から漏れるそうなのも、jsr166 に closure っつーか function type 入れたくないよって事なんじゃねーかと邪推したくなる。 doug lea は function type 入れない CICE の提案者の一人だしなぁ。 775 名前：デフォルトの名無しさん mailto:sage [2008/07/24(木) 00:08:41 ] さっさとScalaに移行しようぜ。Javaなんて、使ってられなくなるよ。 776 名前：デフォルトの名無しさん [2008/07/24(木) 00:26:39 ] グルービーはもう廃れちゃったの？ 777 名前：デフォルトの名無しさん mailto:sage [2008/07/24(木) 00:27:15 ] あらま。delegate感覚で使えると期待してたのに。 まぁListenerの代替として使いたいって程度だから、 Swing Application Frameworkがあれば十分だけど。 代わりといっちゃなんだがOGNL式の静的チェック機能とか欲しい。 778 名前：デフォルトの名無しさん [2008/07/24(木) 05:41:11 ] なんだこいつ？ 779 名前：デフォルトの名無しさん mailto:sage [2008/07/24(木) 08:01:33 ] >>777 その辺は JSR-305 さえ入ってくれれば @Language("OGNL") とかできるようになるんじゃねーかと思うけど…… 780 名前：デフォルトの名無しさん [2008/07/27(日) 02:53:17 ] 　 781 名前：デフォルトの名無しさん [2008/07/28(月) 00:10:23 ] jakartaのなかから標準APIに取り込んで欲しいのは？ 782 名前：デフォルトの名無しさん mailto:sage [2008/07/28(月) 00:22:28 ] ない 783 名前：デフォルトの名無しさん mailto:sage [2008/07/28(月) 00:28:42 ] 俺もないなあ 標準APIは太りすぎだろ 784 名前：デフォルトの名無しさん mailto:sage [2008/07/29(火) 16:07:43 ] EEやSEに突っ込んだら勝ちって競争になりつつあるからね。 土方プログラマ方面では標準化して統一してほしいだろうし。 785 名前：デフォルトの名無しさん [2008/07/29(火) 16:24:35 ] いくら標準化しても、おまえじゃ使えないだろうな。おまえが使えるようになった頃には既に誰も使ってないだろうしw 786 名前：デフォルトの名無しさん mailto:sage [2008/07/29(火) 17:15:22 ] jakarta、generics対応してないの多いからな JDK1.3くらいのときはありがたかったものも今では必要ないとかかなりあるからね 787 名前：デフォルトの名無しさん mailto:sage [2008/07/29(火) 17:35:02 ] 正直、言語面の変化しか注目してない。 後は自分の使いたいクラスライブラリ使う。 788 名前：デフォルトの名無しさん mailto:sage [2008/07/29(火) 17:44:27 ] JSR-203 の試験版。 download.java.net/jdk7/jsr203/binaries しっかし、これ pfav.setOwner(fs.getUserPrincipalLookupService().lookupPrincipalByName("hoge")); とか横に長すぎなんですが…… commons-nio が必要になる予感 789 名前：デフォルトの名無しさん mailto:sage [2008/07/29(火) 17:49:12 ] メソッド名長くしすぎると、 Jakarta Commons VFSに負けちゃうかも… >>774 CICEはクラス中心的でJavaっぽくていいんだけど、 これだけじゃ物足りないね。 790 名前：デフォルトの名無しさん mailto:sage [2008/07/29(火) 17:52:12 ] それからDoug Lea先生は、JSR-166との絡みで、 control abstractionにまいっちゃってる可能性が… そうするとBGGA, FCMに吸い寄せられるような 791 名前：デフォルトの名無しさん mailto:sage [2008/07/29(火) 19:23:49 ] >>788 生APIってのはそんなもん だからみんなファサード大量に容易するわけだ 生APIの場合は出来ないことが存在することがまずいわけで 多少のインターフェースの悪さは無視するのが普通かと 792 名前：デフォルトの名無しさん mailto:sage [2008/07/29(火) 19:50:04 ] >>791 >>788 の例は、出来る出来ないの話じゃなくて、どっちかっつーとクラス構造(?)の話かな。 UserPrincipal extends java.security.Principal 使う必要があるんか？って話。 setOwner(String) でいいじゃんって思うんだけど。String じゃダメな理由あるんかな？ 793 名前：デフォルトの名無しさん [2008/07/29(火) 22:05:32 ] 極端に言えば、BGGA以外は匿名クラスとあまり差はないし、ならクロージャいらないとの議論になりかねない。 BGGA自体も、関数言語指向の方向性は自然な姿だけど、controlのあれはビックリしたけどね。 なんだかんだ言ってサポートされるからブログとか追いかけて気にし過ぎだなｗ 794 名前：デフォルトの名無しさん mailto:sage [2008/07/30(水) 00:15:33 ] >>793 ネストしたときのわけわからなさは異常 1つのメソッドのみのインターフェースを書くのがだるい人向けかな 業務系だと型そのものが大事ではなくてインターフェース名そのものが大事だから あんまり使われないと思う 795 名前：デフォルトの名無しさん [2008/07/30(水) 00:37:34 ] 総称型はコンパイラ時の型安全のつもりだろうけど、インターフェイスの引数で使うとまったく違った使い方ができるし、 クロージャも同じように使ってるうちに全く想定外の使い方がでてくるんじゃないの。 interface Inte <T extends java.lang.Number> {  int compareTo(T obj); } Inte<BigDecimal>だとobj.subtract(this)とかできる。 796 名前：デフォルトの名無しさん mailto:sage [2008/07/30(水) 01:22:10 ] >>795 日本語でもうちょっとわかりやすく 797 名前：デフォルトの名無しさん mailto:sage [2008/07/30(水) 01:33:57 ] 言ってることはわかる気がするが それなんか意味あるの？ 798 名前：デフォルトの名無しさん mailto:sage [2008/07/30(水) 02:18:49 ] >>784 > 土方プログラマ が エア プログラマ にみえたので眼鏡を新調してくる。 799 名前：デフォルトの名無しさん mailto:sage [2008/07/30(水) 05:00:44 ] >>798 おまえのそのメガネは高く売れる。 800 名前：デフォルトの名無しさん mailto:sage [2008/07/30(水) 05:12:58 ] >エア プログラマ にみえた 正解です 801 名前：デフォルトの名無しさん mailto:sage [2008/07/30(水) 09:18:27 ] >>788 これ java.nio.file.Path がディレクトリか調べるのに旧I/O使わないと path.getFileAttributeView(BasicFileAttributeView.class, true).readAttributes().isDirectory() とかする必要あるんですが…… 旧I/O使うと new File(path.toUri()).isDirectory() で済むけど 旧I/Oだと java.io.File#getPath() で帰ってくるのが java.nio.file.Path っぽいけど、 実は String だとか名前の統一性なくなるからあんまし混ぜたくないんだよなぁ 802 名前：デフォルトの名無しさん mailto:sage [2008/07/30(水) 12:00:59 ] こんなん見つけた。 blogs.sun.com/abuckley/en_US/date/20080728 module を言語全体のキーワードでなく文脈依存のローカルキーワードにしたいんだけど、例えば 　class classname { module classname(){ throw new Error(); } } って宣言があった場合、module型を返すメソッドなのか module privateなコンストラクタなのか判別付かなくて悩ましいというお話。 互換性だけを考えると module型を返すメソッドにするべきなんだろうけど…… 803 名前：デフォルトの名無しさん [2008/07/30(水) 14:08:05 ] >>796 おまえの知能を疑うが、どこを日本語にして分かりやすくして欲しいんだ？ 804 名前：デフォルトの名無しさん mailto:sage [2008/07/30(水) 15:34:07 ] >>803 >>795のどこが不思議な使い方なんだ? 805 名前：デフォルトの名無しさん mailto:sage [2008/07/30(水) 15:52:28 ] つ >>795にとって不思議 806 名前：デフォルトの名無しさん mailto:sage [2008/07/30(水) 18:02:10 ] >>804-805 お前らの頭の中は不思議でいっぱい 807 名前：デフォルトの名無しさん mailto:sage [2008/07/30(水) 18:42:40 ] >>768 あれは面倒くさかった。 ぜんぶassert()メソッドをassertEquals()やassertNotTrue とかに変更する羽目になった 808 名前：デフォルトの名無しさん mailto:sage [2008/07/30(水) 18:44:49 ] >>781 Log4jかな。あれを標準化したロギングAPIと統合して欲しい。 ライブラリ依存関係で混乱するから。 Commons Math、Commons Collections、Commons Configurations も標準APIにいれて欲しい 809 名前：デフォルトの名無しさん mailto:sage [2008/07/30(水) 18:48:12 ] >>786 CollectionsのGenerics対応はまだまだ遅いよな。 別ライブラリとしてGenerics対応されたやつがあるだけで まだまだ時間かかりすぎる。 810 名前：デフォルトの名無しさん mailto:sage [2008/07/30(水) 18:53:19 ] マ版でやってくれないか？ 811 名前：デフォルトの名無しさん mailto:sage [2008/07/30(水) 19:03:07 ] この話題はマ板じゃねぇだろ 812 名前：デフォルトの名無しさん mailto:sage [2008/07/30(水) 19:44:09 ] >>802 単純型名で module型が使える場合は module型を返すメソッド、 そうでなければ module privateなコンストラクタってのはダメなんかね？ module型使ってる場合は module privateなコンストラクタを一切使えなくなるけど、 それはmodule privateな静的ファクトリメソッド使うなりして我慢してもらう方向で。 813 名前：デフォルトの名無しさん [2008/07/30(水) 20:52:30 ] >>811 いや。十分にマ版ネタだと思うが。 814 名前：デフォルトの名無しさん mailto:sage [2008/07/30(水) 21:04:53 ] moduleか package名前空間使って public package FacadePackage { 　public class FacadeClass { 　} 　private class SomeClass { 　} 　private package SomePackage { 　　private class SomeClassB { 　　} 　} } んなFacadeなパッケージを作れないだろうか。 UMLで登場したことがある「Facadeに相当するパッケージ」を 作れないかと期待。 今まではクラスレベルでしかできなかったことがパッケージレベルでも 出来ればと期待。 815 名前：デフォルトの名無しさん mailto:sage [2008/07/30(水) 21:05:42 ] >>813 キーワードが増えてこまったこととか、CollectionsのGenerics対応とか、技術ネタだろ。マ板にもっていく必要性がわかんない。 816 名前：デフォルトの名無しさん [2008/07/30(水) 21:51:13 ] 技術ネタなんじゃなくて、おまえの愚痴でしかないようだが？ 817 名前：デフォルトの名無しさん mailto:sage [2008/07/30(水) 21:59:29 ] ネタとして次世代Javaではなさそうだが。 818 名前：デフォルトの名無しさん mailto:sage [2008/07/30(水) 22:02:04 ] >>816 まぁ、落ち着けよ。 宿題やったか？早いうちに終わらせとけよ。 819 名前：デフォルトの名無しさん mailto:sage [2008/07/30(水) 22:15:07 ] >>814 module で export package 指定できりゃそれで良いんじゃ？ 820 名前：デフォルトの名無しさん [2008/07/31(木) 00:52:21 ] >>818 早く死ねよ 821 名前：デフォルトの名無しさん mailto:sage [2008/07/31(木) 01:48:01 ] >>819 それはC/C++のヘッダファイルと同じ運命を辿らないか？ できればimport宣言はそのクラス内ですませたい 822 名前：デフォルトの名無しさん mailto:sage [2008/07/31(木) 03:08:13 ] >>818 ITドカタは来えろ 823 名前：デフォルトの名無しさん mailto:sage [2008/07/31(木) 08:22:28 ] >>821 > それはC/C++のヘッダファイルと同じ運命を辿らないか？ ってどーゆー事？ 「export うんたら」 はモジュール外から使えるクラス「うんたら」だけに制限する。 >>814 みたいな事は OSGi の Export-Package 使えばできるんじゃね？って思うんだが。 JSR-277 はそこんとこはクラス単位みたいだけど それを パッケージ単位でもできるようにすれば良いだけのよーな。 824 名前：デフォルトの名無しさん mailto:sage [2008/07/31(木) 10:03:56 ] >>801 Attributes.getBasicFileAttributes(path, true).isDirectory() までは短くなるな。 十分長いよーな気もするけど。 new File(path.toUri()).isDirectory() に比べても、まだ長いし。 825 名前：デフォルトの名無しさん mailto:sage [2008/07/31(木) 10:12:33 ] >>812 そんな事するぐらいなら module を言語全体に影響するキーワードにした方がすっきりせんか？ 変数名とかフィールド名にmoduleって名前使ってる人には泣いてもらう事になるけど。 826 名前：デフォルトの名無しさん mailto:sage [2008/07/31(木) 11:51:29 ] SunにはJavaのコードからexeバイナリを生成するコンパイラの開発をしようという計画は無いんですかね VM作ってるぐらいだからやる気になればそう難しくなさそうですが 本末転倒かな便利だと思うけど 827 名前：デフォルトの名無しさん mailto:sage [2008/07/31(木) 11:59:58 ] >>826 スレ違いのレベルも下がったな。夏休みか。gcjでも食ってろ蛸。 828 名前：デフォルトの名無しさん mailto:sage [2008/07/31(木) 12:13:47 ] >>826 スレ違いのレベルも下がったな。夏休みか。Visual J#でも食ってろ蛸。 829 名前：デフォルトの名無しさん [2008/07/31(木) 12:47:13 ] 粘着はそろそろ消えてくれないか 830 名前：デフォルトの名無しさん mailto:sage [2008/07/31(木) 12:49:15 ] >>825 影響範囲がでかすぎる。 assertのときほどJavaはマイナーではないし、enumほどみんなに使われるわけでもない。 ほとんどの人が直接使わないのにキーワードにされたら、そりゃ怒るだろね。 831 名前：デフォルトの名無しさん mailto:sage [2008/07/31(木) 13:05:12 ] >>830 moduleって名前使ってない人は怒らないから大丈夫。 それに列挙型よりはモジュール機能の方が使用頻度高いと思うが。 言語仕様汚れる方が将来の言語拡張の妨げになるから嫌って人も多いし。 832 名前：デフォルトの名無しさん mailto:sage [2008/07/31(木) 13:09:29 ] >>802 そこに 2つ目の案として 　class classname { module classname(){ throw new Error(); } } はmodule privateなコンストラクタで、package privateなmodule型を返すメソッドは 　class classname { package module classname(){ throw new Error(); } } にしろって案が出てるけど、これも結構汚いよなぁ。 現実的ともいえるけど。 833 名前：デフォルトの名無しさん mailto:sage [2008/07/31(木) 13:26:23 ] >>827 使いものになんねーだろあれ 834 名前：デフォルトの名無しさん mailto:sage [2008/07/31(木) 14:11:32 ] gcjはclasspath使って書き換えるからそれが完了すれば5.0までいけるんだけどな。 835 名前：デフォルトの名無しさん mailto:sage [2008/07/31(木) 14:52:33 ] もうウザイし、誰か相手してやれよ。 836 名前：デフォルトの名無しさん [2008/07/31(木) 15:58:31 ] >>831 言ってることが良く分からないんだけど、どの言語仕様が汚くなるの？ 837 名前：デフォルトの名無しさん mailto:sage [2008/07/31(木) 16:56:07 ] >>836 全体にキーワード適用した方が言語仕様が単純に保てて汚れずに済むって話。 >>812みたいな小細工が汚れそのもの。 838 名前：デフォルトの名無しさん mailto:sage [2008/07/31(木) 16:57:51 ] >>831 今後の言語拡張だけじゃなくてコンパイラの単純さ健全さバグの少なさにも影響してくるし。 839 名前：デフォルトの名無しさん [2008/07/31(木) 19:27:08 ] はあ？ 840 名前：デフォルトの名無しさん [2008/07/31(木) 19:48:45 ] >>837-838 抽象的で分からないんだけど、もうちょっと具体的に技術的な話は出来ないの？ 841 名前：デフォルトの名無しさん mailto:sage [2008/07/31(木) 22:33:06 ] >>840 お前、このスレ来るのまだ早いよ。 842 名前：デフォルトの名無しさん [2008/07/31(木) 22:40:07 ] ↑頭おかしいだろ？早く病院行ったほうがいいぞ 843 名前：デフォルトの名無しさん mailto:sage [2008/07/31(木) 23:34:18 ] >>840 言語仕様に追加する場合考えてみ？ 全体キーワードなら 3.9 Keywords に module 加えればいいだけ。 >>812 をやろうとすると、大量に書き換えが必要になる。 844 名前：デフォルトの名無しさん mailto:sage [2008/08/02(土) 17:57:54 ] >>843 もう全体キーワードの追加は認められないだろね。 moduleなんてパッケージ名はどこにでもありそうだし。 言語処理側ががんばればいいのなら、それでやるべきだと思う。 845 名前：デフォルトの名無しさん mailto:sage [2008/08/02(土) 19:36:50 ] いっそのことmojuleとかにしちゃえばいいのに 846 名前：デフォルトの名無しさん mailto:sage [2008/08/02(土) 19:53:09 ] ところで、module って本当に jdk7に間に合うのか？ OSGi との互換性とか整合性とかどーすんだろね？ なんつーか >>763 の予感が…… 847 名前：デフォルトの名無しさん mailto:sage [2008/08/02(土) 22:25:45 ] >>845 それなんてCloneable？ 848 名前：デフォルトの名無しさん mailto:sage [2008/08/02(土) 23:17:36 ] そろそろC＃が巻き返してくるんじゃないのか？ 849 名前：デフォルトの名無しさん mailto:sage [2008/08/03(日) 01:27:02 ] 意味がわからん 850 名前：デフォルトの名無しさん mailto:sage [2008/08/03(日) 01:35:26 ] 確かにC#の方が儲かる罠 851 名前：デフォルトの名無しさん mailto:sage [2008/08/03(日) 02:35:05 ] Scalaでえぇよ 852 名前：デフォルトの名無しさん mailto:sage [2008/08/03(日) 03:07:57 ] >>850-851 スレ違い

---

---

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

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