[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/ 101 名前：デフォルトの名無しさん mailto:sage [2007/07/26(木) 23:59:44 ] >>100 Collectionライブラリもクロージャ対応されてくるかなぁ？ Streamとか、JDBCもクロージャ対応になったら、今のソースとガラッと変りそう。 102 名前：デフォルトの名無しさん mailto:sage [2007/07/27(金) 00:24:21 ] java.util.Collections にクロージャ対応な staticメソッドが追加される予感…… 103 名前：デフォルトの名無しさん mailto:sage [2007/07/27(金) 00:43:27 ] これから6勉強しようかって思ってるのに・・・ 104 名前：デフォルトの名無しさん mailto:sage [2007/07/27(金) 01:44:31 ] 別に覚えた内容が損になるわけじゃないぜ 105 名前：デフォルトの名無しさん mailto:sage [2007/07/27(金) 01:48:37 ] >>103 勉強しとけ。 106 名前：デフォルトの名無しさん mailto:sage [2007/07/27(金) 02:35:04 ] >>101 with(InputStream s: new FileInputStream("c:/test.txt")){ 　System.out.println(s.read()); } みたいなことが書けたり List<Integer> list = Arrays.asList(1, 2, 3, 4); int sum = Collections.reduce( 　list, {Integer x, Integer y => x + y}); とすると10が得られたり Lock lock = ....; withLock(lock){ 　//いろいろロックされる処理 } と書けたりする予定らしい。 107 名前：デフォルトの名無しさん mailto:sage [2007/07/27(金) 07:50:44 ] こういうのって結局Cのプリプロセス処理と同じなんだよね。 108 名前：デフォルトの名無しさん mailto:sage [2007/07/27(金) 09:43:44 ] >>107 Cのプリプロセッサみたいにコンテキスト考えずに ただ置換するだけのものとは全然違うよ 109 名前：デフォルトの名無しさん mailto:sage [2007/07/27(金) 14:52:46 ] 違いを見せたいのは分かるが、たいした差はない。 110 名前：デフォルトの名無しさん mailto:sage [2007/07/27(金) 14:55:54 ] ようするにシンタックスシュガーっていいたいんだろ。 それをCのプリプロセス処理と同じというのは問題あるがな。 111 名前：デフォルトの名無しさん mailto:sage [2007/07/27(金) 22:54:16 ] 単なる置き換え。マクロと同じってことがいいたいんだろう。 そういわれると辛いところだが… 112 名前：デフォルトの名無しさん mailto:sage [2007/07/27(金) 23:03:57 ] プリプロセッサは別の言語仕様として存在してるのが問題なんだろ。 D言語とかはC++のカオスさをうまく言語仕様に馴染ませてて感心した。 113 名前：デフォルトの名無しさん mailto:sage [2007/07/28(土) 08:27:49 ] まあ、でもそれはCore2Duoって8086と同じだよね、っていう感じで、だから何？ってなるんだよね。 仕組み的に同じ系統だからって、便利さは全く違ったりするわけだ。 114 名前：デフォルトの名無しさん mailto:sage [2007/07/28(土) 11:10:24 ] 自分で実装するわけにもいかないからね。 便利なのは使わせてもらおっと 115 名前：デフォルトの名無しさん mailto:sage [2007/07/28(土) 11:58:04 ] >>107>>110 アホですね。 116 名前：デフォルトの名無しさん mailto:sage [2007/07/28(土) 12:03:17 ] Ｇｅｎｅｒｉｃｓの話？ 117 名前：デフォルトの名無しさん mailto:sage [2007/07/28(土) 14:00:46 ] どこからその話が・・・ 118 名前：デフォルトの名無しさん mailto:sage [2007/07/28(土) 15:07:58 ] >>106 またC#のパクリか 119 名前：デフォルトの名無しさん mailto:sage [2007/07/28(土) 15:18:52 ] クロージャーがC#にしかないと思ってんのか。 120 名前：デフォルトの名無しさん mailto:sage [2007/07/30(月) 12:02:37 ] scriptは何が追加されるんだろう。 121 名前：デフォルトの名無しさん mailto:sage [2007/07/30(月) 13:43:25 ] script乱立しすぎでわけわかんね 122 名前：デフォルトの名無しさん mailto:sage [2007/08/01(水) 07:29:47 ] jdk6ではjavascriptが使えるけど、javaファイルも同じようにスクリプトとして使えるのかな。 123 名前：デフォルトの名無しさん mailto:sage [2007/08/01(水) 10:38:25 ] 標準添付はされていない 124 名前：デフォルトの名無しさん mailto:sage [2007/08/01(水) 11:36:20 ] 標準ではないのか。次バージョンに期待するよ。 125 名前：デフォルトの名無しさん mailto:sage [2007/08/01(水) 12:09:03 ] >>124 いまのところ、標準添付される雰囲気はないね。 標準添付できるような質のJavaスクリプトエンジンってあるのかな？ 126 名前：デフォルトの名無しさん mailto:sage [2007/08/01(水) 14:14:13 ] 標準添付のスクリプトエンジンの方が 野良スクリプトエンジンより品質悪かったりするけど…… 127 名前：デフォルトの名無しさん mailto:sage [2007/08/01(水) 15:02:46 ] >>125 つ　Pnuts・・・ 128 名前：デフォルトの名無しさん mailto:sage [2007/08/01(水) 17:08:04 ] スクリプトだし、質とか速さとかどうでもいいよ。 とりあえず、Javaが動くスクリプトエンジンを実装してくれ。 129 名前：デフォルトの名無しさん mailto:sage [2007/08/01(水) 17:13:49 ] 言語としてのJavaならスクリプトエンジン作るよりも コンパイラAPIの拡充の方が良い。 メソッド宣言時のシグネチャだけみたいな細かい単位で 構文解析＆名前解決してくれればそれで良い。 ツール作る時とか、そっちの方が都合良いし。 130 名前：デフォルトの名無しさん mailto:sage [2007/08/01(水) 18:31:03 ] そんなこといってちゃ、いつまでたってもjavax.scriptでJavaはサポートされないよ。 自分の都合だけで考えるのもいいけどね。 131 名前：デフォルトの名無しさん mailto:sage [2007/08/01(水) 20:05:04 ] 俺は両方欲しいぜ、ベイベ わがままな、俺の願いを聴いてくれよ イエー 132 名前：デフォルトの名無しさん mailto:sage [2007/08/01(水) 20:15:11 ] >>126 具体的には？ 133 名前：デフォルトの名無しさん mailto:sage [2007/08/01(水) 21:04:43 ] 何につかうんだよそんなもの 134 名前：デフォルトの名無しさん mailto:sage [2007/08/01(水) 21:36:56 ] >>130 標準添付されないというだけで、javax.scriptでJavaはサポートされてるわけだが。 135 名前：デフォルトの名無しさん mailto:sage [2007/08/01(水) 22:35:59 ] >>132 具体的にはって標準添付されてんのRhinoしかないじゃないか。 136 名前：デフォルトの名無しさん mailto:sage [2007/08/01(水) 22:37:07 ] 標準で入ってないと意味ないし、無駄な努力なのだが。 137 名前：デフォルトの名無しさん mailto:sage [2007/08/01(水) 22:40:17 ] SPI使えるんだから、クラスパスに含めるだけで新しいスクリプト言語使えるようにできるんだが…… 138 名前：デフォルトの名無しさん [2007/08/01(水) 22:42:38 ] おれは、C言語をスクリプトで実装して欲しいぜ！ それもC99を！ 139 名前：デフォルトの名無しさん mailto:sage [2007/08/01(水) 22:45:08 ] >>137 ん？俺が無知なだけなのか・・ 140 名前：デフォルトの名無しさん mailto:sage [2007/08/01(水) 23:13:33 ] まあ実際無知なんだろうな。 141 名前：デフォルトの名無しさん mailto:sage [2007/08/02(木) 05:09:30 ] >>135 いや、オレもRhinoしか添付されてないと思ってたのだが、それだと野良スクリプトエンジンの方が品質がいいってのがひっかかる。 Rhinoよりいいスクリプトエンジンって何だ？ 142 名前：デフォルトの名無しさん mailto:sage [2007/08/02(木) 05:10:04 ] >>136 いらん。 143 名前：デフォルトの名無しさん mailto:sage [2007/08/02(木) 12:28:23 ] >>141 普通にビルドしたRhino。 144 名前：デフォルトの名無しさん mailto:sage [2007/08/02(木) 14:28:20 ] >>141 つ　Pnuts 145 名前：デフォルトの名無しさん [2007/08/03(金) 00:08:05 ] >>138 個人的にはFORTRANが良い 146 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 00:12:18 ] たしかSunがFortressっての開発中だったと思う。 並列計算に特化したJavaとFortranを参考にしたスクリプトっての。 147 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 00:12:52 ] >>144 pnutsそんなにいい？ まだこなれてない感じバリバリなんだけど。 yieldの挙動とか。 148 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 04:44:27 ] あんま関係ない話で恐縮なんだけど、javax.script バブルの火付け役が php だって噂は本当なん？ 149 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 06:10:32 ] msのcliに対抗するため 150 名前：デフォルトの名無しさん [2007/08/03(金) 06:16:58 ] C言語やC#にある値型の struct はいつサポートされるの？ 151 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 08:37:18 ] >>148 script言語の共通基盤になるチャンスを見逃すわけがない。 javascript, php, python, ruby実装環境をごっそり頂きかも知れない。 コンパイラ基盤もちらほら出てきているし。 152 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 12:00:15 ] >>150 なぜそんなものが必要なのか？理由を明確に 153 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 12:54:23 ] リンゲージがその関数内であるオブジェクトに対して、イチイチnewしないで済むことが言語として保障されることになる。 154 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 13:02:33 ] >>153 コンパイル時に最適化情報がバイトコードに埋め込めればいいんだよね〜 そしたら、ガンガンエスケープ解析できる 155 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 13:28:43 ] >>151 いや、知り合いから 「php を java vm 上で動かそうって話が最初で、そのあと他の軽量言語が追従した」 って話を聞いたんだけど、本当なのかなって。 156 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 13:54:15 ] >>154 そういう小手先解析よりも、普通に言語としてサポートしろってこと。 struct Point { double a,b }; どう考えても需要あるだろ。 157 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 13:56:16 ] >>155 それだけ需要があるなら、PHPがまずサポートされるはずじゃないか？ VMで他の言語が動けばいいのであって、どうでもいいけど。 158 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 14:24:28 ] >>156 その程度なら不要。 値型の利点は、newが必要とかより、 代入が必ずコピーになることによって、 同一オブジェクトに対応する変数が一つであることを保障できることだと思うんだが。 159 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 16:26:23 ] >>158 需要の論点ではPointで示したが、利点としては例えが悪かった。 では必ずコピーになる利点のために導入するのではどうだ？ほしいだろ？ 160 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 16:41:03 ] いや別に 161 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 17:45:57 ] 値型が導入されたら、今度はポインタ演算を欲しがるに違いない 162 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 19:10:24 ] C#はstructの導入に失敗したからNullableが出来たんでしょ 恥ずかしい実装まで追従する必要ないから、別に要らないなぁ どうしてもってのならByteBufferをラップすりゃいいし 163 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 19:34:17 ] 値型ってメモリ効率に関する利点のために導入するもんだろ。 164 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 19:36:02 ] それが理由ならエスケープ解析が導入されたから今後は不要でしょ 165 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 21:11:05 ] >>161 それはない。 166 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 21:17:46 ] >>164 複雑じゃなくていいから、普通にCと同じのでいいよ。 メソッドもCの関数ポインタみたいに、staticのみでいい。 エスケーポ解析よりも言語に導入のほうが楽だと思うけど、そうでもないのか まあ、そのうちちゃっかり導入されるんだろうけど。 167 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 22:14:07 ] JDK7 build17 ttp://download.java.net/jdk7/changes/jdk7-b17.html ttp://download.java.net/jdk7/binaries/ 168 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 00:41:24 ] いまさら導入されても、C の register 変数と同じ運命をたどる予感。 169 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 02:00:02 ] register にも、一応アドレスを取れないという効果はあるんだぞ！ 170 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 07:19:54 ] >>157 PHPみたいなどうでもいい言語をまずサポートする必要性がみあたらない。 171 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 08:47:45 ] structのメモリー効率のよさってのは、オブジェクト廃棄時のコスト云々じゃなくて、 newに頼ってオブジェクト生成するときのコストがまったくないってことだろ。 関数呼び出しでスタックに自動生成されるのであって、newによるオーバーヘッドは かからないいってこと。 172 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 08:51:14 ] オブジェクトがほかのメソッドに伝播される可能性を考えると、エスケープ解析で自動的にやってくれるのが一番効率がよさそうだな。 173 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 08:52:09 ] structは、コピーによって、ここのオブジェクトの同一性の確保も そのとおり利点ではあるが、エスケープ解析の小手先技なんぞに頼らないで 優先的に言語でサポートするのが妥当だろ。 assert, enumとかよりも先にさ。 Javaの文法は、結局Cの文法を真似てるだけってことを忘れて、 「エスケープ解析もできる俺ってすごいだろ」っていい気になってるだろ？ 174 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 08:52:42 ] エスケープ解析ってのはそれをやるんだよ。 C#のstructと同じような最適化がされることになり、 逆にC#2.0で対応するはめになったNullableのようなstructの欠点も無い 175 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 08:54:47 ] >>171 まあ、メリットはあっても、それが"大きく"効いてくるのはかなり特殊なケースで、 そういうのが大量にある応用の時は、ハイバネでいい、ってのが今の流れなんじゃないの? 176 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 08:55:56 ] JavaのenumはCのenumとは違うぞ。 定数そのものに振る舞いを持たせることが出来るし、 なおかつタイプセーフだ。 177 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 08:57:25 ] メモリーの効率とかじゃなくて、 structを使いたいプログラマーの切実な要望には答えられないのかね？ そういうエスケーポ解析の新技術はどうでもいいからさ。 178 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 08:58:34 ] >>173 で、エスケープ解析に比べたstructの利点ってなんなの？ 179 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 08:58:58 ] structの欠点の無いむしろメリットとなるようなカラクリがあれば導入されるかもな。 180 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 09:02:12 ] ちなみに、structなど値型を使いたい場面は、 forや関数呼び出しで100万回以上まわす。 そういう小型オブジェクトの短期生成は、newでは向いてないし、役不足だろ。 またエプケール解析とかいうのか？ GCの新技術はJava以外のVM使うスクリプトにもメリットあるだろうが、 そういうのは使うほうからみてどうでもいいから、まずはJava言語で導入しろ。 181 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 09:02:38 ] >>177 メモリーの効率とかじゃないなら、structを使いたいっていう切実な要望っていうのは、新技術以上にどうでもいいんじゃないかと思う。 182 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 09:03:54 ] >>180 使う方から見てどうでもいいのがstructだと結論づいてるのに何を・・・ 183 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 09:04:17 ] >>176 使うほうからすれば、C,Javaどちらのenumも同じ。 いつ使えるようになったかといえば、Javaはサポート遅すぎ。 184 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 09:04:37 ] >>180 エスケープ解析で十分です。どうもありがとうございました。 185 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 09:05:49 ] >>183 全然違うっての。お前のいう「使う人」って誰だよ。お前限定じゃねーか。 お前はCだけ使ってろ。 186 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 09:06:52 ] >>181 きみ、structとclassは実質同じってことを知ってるのか？ 187 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 09:08:35 ] >>186 C++のデフォルトアクセスレベルの話で言ってる？ 同じものなら要らないだろ 188 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 09:09:11 ] structを否定するってことは、classつまり、構造体型（集合型）を否定しているようなものだけど・・ 君の理解じゃ、ポインタがどうとかってあたりで止まってるんだろうな。 189 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 09:09:20 ] >>186 だから、なに？メモリ効率以外に、structの利点ってあるの？ 190 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 09:10:21 ] >>188 なんで？ きみ、エスケープ解析の意味ちゃんとぐぐってる？ 191 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 09:15:05 ] なんか、エスケープ解析をわかってないやつがいるみたいなんで書いておくけど for(int i = 0; i < 10; i++){ 　Point p = new Point(); 　p.x = i * 2: 　p.y = i * 4; 　System.out.println(p.x + ":" + p.y); } が for(int i = 0; i < 10; i++){ 　int px = i * 2: 　int py = i * 4; 　System.out.println(px + ":" + py); } に最適化される技術な。 192 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 09:34:02 ] まとめると、「エスケープ解析の意味がわかんないやつが暴れてましたとさ」でいいの？ 193 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 10:12:30 ] >>180 エプケール解析て…これは釣りだろ。 それから値型もnewされることに変りはないぞ。 194 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 10:20:21 ] Java版のaptみたいなのがそろそろ出てきてもいい頃合だね。 各種IDEやmavenの資産、そしてJAMの登場によって下地は十分のはず。 JDKに同梱されれば、環境構築のコストが激減しそう。 195 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 11:09:02 ] SunがOpenSolaris用のパッケージ配布機構を発表したぞ。 ZFSに基づくサービス、実装らしい。 Sun、『OpenSolaris』でバイナリパッケージ配布モデル採用へ japan.internet.com/busnews/20070713/11.html 196 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 11:55:05 ] またエスケープ解析が得意の彼か 彼の言い分も一理あるが、単純に彼は自分の技術を自慢したいだけだから、ほっとけ 197 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 11:55:58 ] >>193 そもそも struct とか言う奴は大抵釣り。 198 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 12:01:23 ] JOGLやjinputとかをJDKから簡単に取り寄せられたら便利だね 199 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 12:18:37 ] 下手にやると複数バージョンのjarが入り混じってカオスになるけどね 200 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 12:25:12 ] >>196 そういう話は、的確な議論してから言ったほうがいいと思う。 201 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 13:47:09 ] struct ： スタックに値を割り付ける エスケープ解析 ： スタックにオブジェクトを割り付ける最適化手法 オブジェクトが対象のエスケープ解析の勝ちでおｋ structは時代遅れの産物

---

---

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

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