【Java SE 7】 次世代Javaの動向 ７ 【dolphin】

■■前スレッド■■
[Java SE 7] 次世代Javaの動向 6 [dolphin]
http://pc11.2ch.net/test/read.cgi/tech/1199330977/

■■過去スレッド■■
[Java SE 7] 次世代Javaの動向 5 [dolphin]
http://pc11.2ch.net/tech/kako/1178/11789/1178925915.html
[mustang/Java SE 6] 次世代Javaの動向 4 [dolphin]
http://pc11.2ch.net/tech/kako/1163/11639/1163986696.html
[mustang] 次世代Javaの動向 3 [dolphin]
http://pc8.2ch.net/test/read.cgi/tech/1157227790/
次世代Javaの動向　２
http://pc8.2ch.net/test/read.cgi/tech/1147881822/
【Java】次世代Java・J2SE1.6の動向【Mustang】
http://pc8.2ch.net/test/read.cgi/tech/1081698555/


■■関連スレッド■■
現世代Javaの動向 1
http://pc11.2ch.net/test/read.cgi/tech/1150286189/

■■■関連スレ
【初心者】Java質問･相談スレッド119【歓迎】
http://pc11.2ch.net/test/read.cgi/tech/1220388885/
【徹底討論】Java３Dの可能性について考える
http://pc11.2ch.net/test/read.cgi/tech/1033703640/
Eclipse統合M25【Java/C/PHP/Ruby/Python/Perl】
http://pc11.2ch.net/test/read.cgi/tech/1211505494/
【Java】NetBeans Part4【Sun】
http://pc11.2ch.net/test/read.cgi/tech/1218959013/
【Java】Wicket【HTML】
http://pc11.2ch.net/test/read.cgi/tech/1132407308/

乙

クロージャーのことがまだ良くわかっていないのだが俺は、
クロージャーのことがよくわかる参考資料はないかね

BCPLの仕様とそこからリンクしてあるチュートリアル嫁。カス野郎

JDK7 build34
http://download.java.net/jdk7/changes/jdk7-b34.html
http://download.java.net/jdk7/binaries/

6u10っていつ頃ですか？

>>7
今秋予定。いまRCまできてる。

NIO2 のバイナリ ： jdk7build33 + NIO2
http://download.java.net/jdk7/jsr203/binaries/

NIO2付きの javadocも来た。
http://openjdk.java.net/projects/nio/javadoc/index.html

>>8
ありがとう。6u8や6u9が間にあると思ってたけど、すっとばすんだね。

演算子オーバーロードーのことを気にする人がかなり減ったけど、あの熱気は一体なんだったんだろうと思う。
もし言語として必要（必須）なら今でも不満が出るんだろうけど、やっぱり一時の浮気心であって実際はどうでも良かったのかな…
この辺りはどう思う？

BigIntegerやBigDecimalを除けば、
特に欲しいと思える機能ではないな。

それだと、BigDecimalはextendsして自分でメソッドを定義すればいいんじゃない？

JDK 7はいつごろリリースされるの？
さらにEclipseが対応するのはいつごろ？

JDK7のリリース予定は、いまのところ来年夏かな？
http://www.javaworld.com/javaworld/jw-05-2008/jw-05-rightsize.html

これが最新の予定かどうかは知らん。
遅れる事はあっても早くなる事はないと思う。

>>15
ありがとうございます。
まだまだ先ですね。

>>11
あれは熱気じゃないだろw ただの荒らしがしでかしたもの。
過去に「C#って死滅しちゃうのスレ」でJavaアンチが散々煽っていたネタの一つw

次のJVMではたくさんのスクリプト言語がサポートされるんですが、この選考基準はなんですか？
自分のスクリプトをevalさせるのは簡単ですか？

コミュニティの数とか、歴史とかじゃない？
Pnutsのユーザーとかまだ居たりするのかな。

>>18
何か追加される予定あったっけか？
今のところ Rhino しか入ってないと思ったが。

後付でスクリプトエンジン入れられるって意味のサポートなら、
自分で ScriptEngineFactory 実装してSPI 登録すりゃいいだけだから、
後はユーザーがダウンロードして使ってくれるかどうかだけ。
こっちは jdk7関係ないし。

>>20
つ JavaFX

>>20
SPI登録っていってもCLASSPATHにJar通せば終わり

JavaFXはRAD環境がないらしいけど、
βから作り始めてる猛者はいるのかな。

悪い、実装する側の話ね。

スクリプトサポートといっても、なんか難しそう・・・

JDK7 build35
http://download.java.net/jdk7/changes/jdk7-b35.html
http://download.java.net/jdk7/binaries/

ところで、前スレで、ScalaはJavaVMで動かすことを考えられた言語でネイティブにバイトコード対応してるから速いと書いたら、GroovyやRhinoでもバイトコード変換ができるという答えが返ってきてたんだけど、GroovyやRhinoのコードでJava言語よりも速いコードが吐けるの？

>>27
バイトコードに変換するコンパイラがどれだけ頑張るかによる。

>>28
今どきのJVMのJITは、Javaコンパイラが通常吐き出すバイトコードに、
かなり特化した最適化が行われているから、
いかにJavaコンパイラが吐き出すバイトコードに近いコードを生成するかが、
高速化の鍵になると思う。

Scalaはリフレクションをつかったバイトコードを生成したりするから、それでも遅くなる。
単純なソースならないだろうけど。

> 今どきのJVMのJITは、Javaコンパイラが通常吐き出すバイトコードに、
> かなり特化した最適化が行われている

具体的には？

>>30
あのへんは InvokeDynamic使えればリフレクション使わなくてもよくなるかも。

>>30
んー。Scalaでリフレクションを使ったバイトコードが生成されるのは、やや特殊な場合だけ
だが(配列がらみの変換とか)。通常の数値演算とかメソッド呼び出しはリフレクション
は特に使われていない。コンパイル結果をjavapしてみればわかる。

で、Scalaが速い理由は、単にバイトコード吐くからじゃなくて、
静的型付けで、しかもJavaに比較的近い型システムを持っているため、より
直接的にJVMのバイトコードにマッピングできるから。たとえば、scala.Int
型同士の加算は単にJVMのiadd命令になったりする。

>>33
structural conformance とかもそうだね。

structural conformance、Javaでも出来るようにならんかねぇ

interface MyIn
{
class MyCl {}
}
とすると、内部クラスはインターフェイスの規約どおり必ずpublic static final class MyCl
として扱われるんですか？

>>34
そんな紹介記事読めば書いてあるような事を一生懸命書かなくても……

>>36
誤爆しました。

BeansBindingって7に含まれるのかな？

>>39
たぶん含まれると思うけど。
7 のスペックリードの Danny Coward の追っかけでもやらんと最新の動向はわかんない。

そーいや、クロージャの Neal Gafter が Google やめて Microsoft に行ったとか。

それ、ハッタリだって。

>>40
あれま。closureはどうなるのかな。

JDK7 build38
http://www.java.net/download/jdk7/changes/jdk7-b38.html
http://download.java.net/jdk7/binaries/

おお
JColorChooserにHSLタブが追加されたんだｗ

>>42
仕事はdotNetだけど、
バランスのために趣味でJava言語の設計と開発を続けると書いてある。> blog

次世代ではないが、6u10はいつになったらダウンロード出来るんだ。

英語ページからならはじめから。
日本語ページから落とさなくてもMulilingualだから
どうせ同じバイナリですよ

自分も英語ページから落としたけど
日本語ページの放置っぷりに、Sunのやる気の無さが伺えたｗ

JAVAって欠陥言語だろ？
本も種類多すぎだし、コードはクソ見づらくなるし
何がいいの？

>>49
コボラー乙

SwingLabsのJXTreeTableって標準で実装される可能性はない？
これだけは欲しいんだよねー

JDK7 build39
http://www.java.net/download/jdk7/changes/jdk7-b39.html
http://download.java.net/jdk7/binaries/

最近のJVMの進化は凄いね。部分的にだけどJavaがCの処理速度を超え始めてるよ。
ttp://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=java&lang2=gcc

部分的ならかなり昔に越えてるよ。
1.4の頃からアルゴリズムの教科書に載っているようなプログラムは
Javaの方が早いのが結構あった。

>>53
それ、最新のJVM使ってないんじゃね？

>>54
6.0になると、体感で1.4の倍くらい速いしなぁ。

6はGUIまわりが高速化されたイメージが強いな
性格にベンチしたわけじゃないので、あくまで個人的な感覚だけど

>>53
Cでオレオレ言語とオレオレVM作って、Javaを巻き返したとしたら
Cが速い事になるんだろうか。それともオレオレ言語が速い事になるんだろうか。

と考えようと思ったけど、よく考える間もなく、JavaだってC製だよなあ。C++かも知れんけど。
なんかもうオレだめだ寝るわ。

所詮最後は機械語な訳だから、動的コンパイルの勝利って視点が正しい気がする。

gcc-llvmってのがあるから、
そいつがCも速くしてくれるかも知れない。
ただあまり低レベルな記述ができないほうが、
プログラム解析には有利なんだよな。

JDK7 build39
http://download.java.net/jdk7/changes/jdk7-b40.html
http://download.java.net/jdk7/binaries/

> build39

次の目玉機能といえるクロージャや追加スクリプトとかの話題を最近聞かないんですけど、やっぱ止めちゃったんですか？

Neal GafterがMicrosoft行ってから、
> Current prototype: http://www.javac.info/closures.tar.gz (updated 2008-08-11)
更新されてないからね。

なんかこう
ｇｄｇｄ感が漂ってるよね・・・

そのニアルってゴスリンの部下じゃなかったのか。
一度MSに行くともうSUNに戻ってもリーダーになれないような感じだけど、SUNの社風はそうでもないのか？
それともいい仕事する割には、ストレスに弱いのかｗ

Sunつぶれそうだから逃げ出したんでしょ

今のSUNはかなり儲かってんだが。
レイオフはよくあることだし、どっかの大学と提携して順調だろ？

ニールはマイクロソフトのスパイだったって話だよ

>>68
かなり儲かってる？どこが？
http://www.itmedia.co.jp/enterprise/articles/0810/31/news022.html

おまえ、営業利益とか経常利益とか言われてもさっぱりで財務とか苦手だろｗ
隠さなくてもいいぞｗｗ

Neal GafterはGoogleにいたんだよ。
GoogleのJavaのチーフ。Google Calendar作った。
その前はSunでJavaのコンパイラ。

>>71
純損失が16億ドルあって「かなり儲かってる」といえる理由がわからないので、財務とか苦手なようだ。
ちょっと解説してもらえないだろうか？

UNIX板にSunスレあるぞ。二人とも行け

そういう話じゃないだろ

そういう話だろ

文脈よめねぇの？

つうか、次世代Javaの動向にSunの経営状況が密接に関係あるのわかってないのか

SunはヤバいからJDKの実質有償化をゴリ押ししてなんとか金にしようとしてるんでしょ

jdk1.4のサポートを有料で継続するって話？

ここ次世代Javaのスレなんで。

古いのも次世代も、今後は出てから３年で無償サポート切られるよ

新しいのはGPL化されたOpenJDKがあるからやろうと思えば自力で手を入れられるし。

一般カスタマー向けじゃあるまないし、３年は早すぎだな
jvmやjdkライブラリも、もともと低額でも有償だったらあまり使われなかっただろうし
XBoxやPSとかみても５年から７年過ぎたらってところじゃないか？

ゲーム機w

携帯でも成功したので、jvmの次のターゲットはゲーム機ですよ？

無償サポートのわけねえw

ゲーム機が無償でもらえると聞いて

携帯でjavaアプリゲームが実現できたので、次のターゲットはゲーム機器（ハード・コンソールとも言う）に特化したjvm (kjvmなど）を作れば同じ流れで成功するだろう。
ただハード性能を引き出す必要があるけど、もともとコンソールは普通関係者だけで閉じてるからあまり問題ない。というか携帯の方は乱立がすごいし。
java meの延長でcpu 1.0Gなど大コンソール向けとかのプロファイラ切り替えでいけるんじゃないかな。

当然プリンタとかの組み込みとかも視野に入ってくるけど。
SUNは本来ハード会社だし、MSとはそもそも畑が違う。

dolphinっているかだろ？どうせなら、グランパスにしてほしかった。

>>89
グランパスは8まで取っとくだろ常識的に考えて

つまらん

コードネームって廃止されたんじゃなかったっけ？

相手にするだけ無駄だな

>>90
激ウケｗｗｗ

>SUNは本来ハード会社だし、MSとはそもそも畑が違う。
javaが動く携帯ゲーム機作ってくれたら買うんだけどなぁ

>>88

詳しそうなので聞くけど、
BlurayDisc対応のハードって、Java搭載が必須だったっけ？？？
何かの光Discの規格でそういうのがあったような。。。

で、それって、実際使われているのだろうか、とうのが気になっている。教えて。

PS3でjavaが動くと聞いて！

>>96
必須ですよ。プロファイルがSEとはずいぶんと違いますが。
ネットで関連グッズ買わせるボーナス画面で既に使われてるはずです。
変わったエフェクトのメニューとか。

でも携帯アプリみたく自分で作ったのが自由に転送できないなら、Java搭載かどうかはあまり意味ない。
それなら値段も安いしネットブックでやるし。
少し大きいけど、持ち運び可能な液晶と考えればそうでもない。

クロージャもプロパティもサポートされないんですか・・・

その代わりにJavaFXがサポートされます！

JavaFXってコンシューマJREに載ってこなかったけどいつ出てくるの？
オーサリングツール作ってるってんなら待つけどさ。

まだ先だろ。だいぶ待ってろ

クロージャはサポートされないんですか。ならc#にします。

>>102
JavaFXは今週プレリリース版出すらしいよ。

Javaがレガシーだって? 冗談じゃないよ - James Goslingが語るJavaの現在
ttp://journal.mycom.co.jp/articles/2008/12/03/javasfather/index.html

クロージャは早くて１年半後ってあったから、jdk1.7が出てから追加導入ってことになるかのかな。
SUNにはキャッシュが３０億ドルあるってのが笑えた。
アメリカ本国が破綻することはないけど、タンス預金と同じ。
なんなら森ビルとか日本テレコムでも買収して固定資産化しろよｗ

固定資産化ってアホか

難しいことにアホが口を挟むなｗ

>>108
おまえはそんなところにしか目がいかないのか？ｗ

オマエモナー

FX 1.0、明日リリースだってー。

>>112
Sunがいろいろ頑張ってるのはわかるんだけど、
さっぱり盛り上がってないよね……

需要は少ないんだろうが、そろそろSwing上のハードウェア加算合成をサポートして欲しいなあ…

名のあるゲームメーカーとかと組まなきゃ無理だろ。
Sun主導ででクライアントサイド技術が大成するとは思えない。

JSFだって結局JSPじゃなくてFaceletsに移ったしね。
Velocityが通った道に何年掛けてるんだって話。

Javaで商用アプリケーションはけっこうあるけど、商用のゲームなんか見たこと無いもんなあ。
Quake2エンジンはずいぶん前に移植できてるみたいだから、ポテンシャル的にはそこそこのものが動きそうな気もする。

ただ、ゲームの世界で「そこそこのもの」を作っても、あんまり金を出してもらえないか。

まぁでも、6u10以前のアプレットで作ったネットゲーム(RuneScape)で
億万長者になった人もいるにはいる。

>>117
そういや、あのころJOGLはまだだろうし、Java3Dで頑張ってたのかな？

　
【サンタクロース、トナカイの酒気帯び運用罪での逮捕に、ﾏｼﾞ逆切れｗ】(ZDNet)
http://builder.japan.zdnet.com/story_media/20384793/081204_sun-james-gosling_02_400x300.jpg

クロージャの導入にいつまでかかってんだよ
C#との差は広がるばかりだな

C#4.0は動的型とジェネリック型共変反変サポートだったっけ

JDK7 build41
http://download.java.net/jdk7/changes/jdk7-b41.html
http://download.java.net/jdk7/binaries/

JavaFXになっても未だにmp3再生はJLayer頼りなの？
ttp://weblogs.java.net/blog/javakiddy/archive/2007/05/making_javafx_s.html

JavaFXって速度はどうなの？
っていうかJavaってなんで遅いの？
ゴスリンはいまはCよりも速いとか言ってるけど、絶対遅くね？
納得のいく説明をマジ期待

スレ違い

>>124
Cは永遠に不滅だからねぇ

起動時の速度が遅い
これは何ともできないね。常駐JVMとかできないと。
だから小さなベンチマークだとJavaは遅い。
実際・・・Jazelle入ってるARMとかで動かしてるLinuxとかで
Javaが速いプラットフォームとかあるのかな？

>>124
どういう処理が遅い？

>>116
http://www.getamped.jp/
Java製だったと思う。

まじか。本当にそうならすごいな。
どうもインストールのとこ見るとJREのインストール促すような文章もなかったけど内包してるんかね。

国産じゃないけどこんなのもあるね。

ttp://tribaltrouble2.com/

今までjavaがゲームに向かないって言われてたのは、javaの精神からネイティブの個別対応に消極的だったからでしょ。
だからgcもかなりよくなってるし、ライブラリもかなりそろってるし、javaなら当たり前かなって感じはする。

あれ？JInputってMacやLinuxにも対応してるのね。
これだとWebStartあたりでMMO作るのが一番楽かも知れん。
今ならサーバもクライアントもJavaでいけると思う。

ベクトルユニットを使わずCPUで全部計算させていい程度のゲイムならjavaでもrubyでも実際のところ比べるほどの差はない。
ただ、無理して昔のPS１のような３D使うなら普通にクラッシュバンデブーとかの２D化とかスプライトの方がいい感じはする。

微妙な違いが気持ち悪いがクラッシュバンディクーだよな？
2Dか？
http://jp.youtube.com/watch?v=buMA1evvbbI

いや、言いたいことはテクスチャをピクセル毎に計算するんじゃなくて、アニメのように精密なセル画を毎々用意してはってけばいいってこと。
影とか屈折とか３D特有の計算がなくて、せいぜい多色のべた塗りの画像を貼り付けるだけだからやってるとことは2dとほとんど同じ（３次・４次のベクトル座標計算程度）。
もしopenglとかのGPUユニット使わずCPUだけで画像処理やるなら、どんなに頑張っても今のPCの限界はこのへんじゃないか？
個人的にはマルチコアでやっぱりCPUで何とかなっていっちゃうのが次の流れかなって思うけど。

ナルト
http://ps3navi.com/log/2008/09/ps3naruto_9.html

そんなこと言うなら、ゲーム3Dは屈折とかちゃんと計算してないし、ピンボケも2Dでのぼかしと同じで、ほとんどは2Dのフィルタ処理と同じじゃないか。
CPUとGPUの区別をどうするか知らんが、しばらくはCPUのようなでかい演算装置で超並列できるようにはならないと思うよ。
結局Direct3Dをどれだけ使えるかって話だろ。

＞ゲーム3Dは屈折とかちゃんと計算してないし

上に書いてあるのを読んで、屈折自体を計算する必要がないってことに気がつかなかったか？

それに計算の話じゃなくて、アルゴはいくらでも考えられるけど、実際はソフトで行える限界・その計算が視覚に耐えられる限界・協調同期の限界があるわけだから、
１０年前のFF7ポリゴンみたいなことして技巧的にならないで、アニメっぽいテクスチャ述べた塗りでいいんじゃないのってこと。
それだとナルト並なら、動きの滑らかなのとか抜いても、分担して３人ぐらいいれば作れるし（１ステージだけとか）。

nvidiaとか最先端技術のデモ見てるとよだれでるけど、それが世に広まるのは5-7年先のことでしょｗ
やっと１０年前のFF７並みのポリゴンがjavaで手軽に作れるほど世に広まったわけだし。

マルチコアについてはハードを持ってないからあまり知らないけど、
gpuとかopengl/directxとかで計算を肩代わりさせるよりもよりもスレッドとマルチコアが主流になると思う。

個人的にはグラフィックカード(gpu)に２万も３万も出すよりはバックアップ用のHDDとかデジカメとか買うけどねｗ

これ(>>138)人工無能だよ。多分。
似たようなのが前にもJava初心者スレに湧いていた。

JVM自体の拡張は無いものかな？
そろそろSIMDをサポートしてもいいような気もするんだが。
JVMの命令レベルでサポートしてくれれば、標準ライブラリにも反映されるだろうし。

>>140
知らない話になるとすぐ人工無能とかいっちゃうあたりは、その人工無能は君のことじゃないの？

仮想スタックマシンとベクトル計算は相性いいからそれはありえるかもね。
ただ、プリミティブの128bit型(dot netだとstruct Decimal)を入れて欲しい。
add,subとかの演算はなくていいから、int,longへのキャストだけでいい。
といよりも、jvmヒープではなくてスタックフレームにメモリ確保する
struct, stackallocを導入すればいいかなって感じはする(当然値渡し）。

>>141
つ invokeDynamic

>>141
そういう計画は次期JVM本流では全くないです。

そもそもGPUをフルに使いたいのに、
バイトコード設計に制約を受けていては元も子もない。
リッチなAPIをネイティブで実装するのがいい。

あと２−３年もすればマルチコア一色になるからダイレクトXを使いこなせるって考え方も変わるんじゃないか？
そりゃGPU使えればかなり魅力的だけど、べつにGPUの機能やライブラリを使わなくてもある程度同等ならもう十分だし。
ただ（東工大の例も考えれば）GPUは並列にしないとあまりうまみがないし、個人のPCでGPUを多段式（予算６万として３枚以上）にする人は滅多いにいないだろう。

http://blogs.sun.com/darcy/entry/small_language_changes_jdk_7
http://www.jroller.com/scolebourne/entry/java_7_small_language_changes

なんつーか、既存のプロジェクト(kijaro)とモメてる？

>>138
屈折自体を計算する必要がない？3Dグラフィックわかってる？
アニメっぽいテクスチャのべた塗りでいい？それほんとにやったらどんなしょぼいもんができるかわかってる？
バーチャファイター１だぞ。
カートゥーンレンダリングのこと言ってる？

マルチコア一色？あと10年は掛かるな。
アップデートしなくちゃいけないのは人間だて。

マルチコア一色？Larrabeeのことか？

ゲーマーと同じ発想のようですけど、デテールにこだわるなら勝手にどぞ。
デテールにこだわるあまり３Dを熟知しているゲームPGを２０人も雇うなら人件費の方が大きいよね。

open glがデフォで使えるようになったのは1995-1998頃から普及しだして3年ぐらいじゃなかったか？
PCと一緒にグラフィックカードも買ってくれるようになってからだったしな。
ただライブラリが貧弱で実際プログラムする敷居は高かったけど。

短絡で考えればメインPCを買い換えるは無いだろうけど、
マルチコア（CPU)はサブPCとかサブノートとか追加で導入されていって普及していくんじゃないかな。

俺の開発用PCは確か８年前でintel 1.4Gだし、別にゲームの専門・職業でやってるわけじゃないからね・・・

（Sunが真面目に取り組む気があるなら）将来的にはJOGLよりJava3Dのが速いんだろうな。

JOGLよりJava3Dのが速いかどうかは、ハードの問題でライブラリ（アルゴ）はあまり関係ないんじゃないの？
それよか、自分で実装するのも面倒だし、特定ハードの機能に依存しないアルゴがあればいいよ。
遅いかもしれないけどそれは先も書いたとおり、速いか遅いかはハードの問題。この辺りは、古参兵だと今だにごっちゃなんだろうけどｗ

抽象度が高い方がハードウェア特性を吸収しやすいってことだよ。
結局の所ソフトウェアのボトルネックは大抵が人間系だ。

ただ、マルチコアだと速いくなるってことはないだろうと思う。
OSが握ってるわけで、未だとプロセス(os thread)管理が主体みたいで、PGが直接制御するような代物でもないようだからな。
CPUに入ってるFPUユニット(sse)を常時乗っ取れるかどうかとかもあるけど、そういうのはライブラリの仕事でしょ。

ただPGは、gcのようにストレスなく並列計算でき、memory管理とかも気にせず、float[][][]使いまくりで2d(と擬似3d)プログラムできるんじゃないか？
現在要求されるハードを全部解決できるからな・・・

擬似的じゃなくて、3dバリバリ使いたい（PGやゲーマ）なら普通にGPU導入するだろうし、3dの表現効果とかカード１枚でやる程度のベクトル計算はGPUの畑だろう。
3dは、表現効果を全く考えないなら、ただの座標計算でしかないし（ワイヤーをクルクルみたいなアレ）、gpuとか不要じゃない？

ところで >>151はゲーム作成のコスト削減の話をしてただけなのか。

わかったことは、「アルゴ」なんて言葉つかうやつは、信用できないってことだな。

ナルトのレンダリングってかなり高度だと思う。

>>158
ALGOLの作者に謝れ!

>>157-160
おまえらの相手なんかしてたからageちまったじゃないか！どうしてくれるんだよ！

３Dでよくある何チャラ法とか知ってます！ってのじゃなくて、アルゴをちゃんと勉強したことあるなら>>155みたいな思想は持ってないな。
たとえば、座標上の点を推定するために補間関数を考えたとき、
そのアルゴ・関数では端点（極点）での精度が著しく悪くなるアルゴなら、
この問題はいくらハードが速くなったところで解決できない。
こういうのはアルゴ（ソフト）の問題じゃないの？ｗ

これは光（法線）と影（ブレンド）の従来３Dの理論上の計算方法と同じ問題で、ソフト（例えばダイレクトXとか）ではいくら技巧的にやっても解決できるはずはない。

jvmにSSEやgpuユニットとかの計算専用（ベクトル計算）FPUを呼び出すbytecodeがあってもいいってのは面白いと思う。

それにはJava VMの仕様の一部としてバーチャルSIMD演算器を
定義する必要があるだろう。

http://weblogs.java.net/blog/alex2d/archive/2008/12/jwebpane_projec_1.html

そろそろ来るのか？

>> 161
なんか、がんばって知ってる難しい単語ならべたようにしか見えない。

座標の補完で精度が悪くなるアルゴリズム？
補完で繰り返し収束するようなアルゴリズムなら、ハードが速くなると解決するね。
というか、座標の補完で著しく精度悪くなるようなアルゴリズムって何？
どういう座標補完を前提にしてる？

ソフト(ダイレクトX）って書いちゃうってことは、DirectXわかってないことバレバレだし

その定義はそんなに難しくない。and or xor の配列へのapplyでいいだろう。例えば
void xor (arrsrc, off, arrdst,off, count);
するとベクトルの内積（算術・論理演算）が定義できたことになる。スカラー倍もしかり。
だから最低[Bでand or xor だけあれば、後はライブラリでコピーと変換するだけ。
add,mulとかも論理演算があればライブラリで何とかなる。
仕組みについては多倍長BigIntegerを自作してみるとわかるんじゃないか。

この辺りの合理的な設計（十分条件）はハードの専門家（SUNとかIBMとか）の方が詳しいんじゃないのかな？

個人的には、struct,stackallocの方が優先順位は高いけど、このsimd呼び出しも面白そうだなぁ。
どうしてかというと、jvmプラットでサポートされてるってことになるから、
例えばintelでasm使ったりintel製コンパイラ使ったりせず、またjniでmmx,sseゴリゴリしなくてもすむし、
javacだけでなくjrubyやjavafxでも言語仕様やライブラリでサポートできるから。

ただjvm bytecode眺めてみたんだけど、配列のコピー(arraycopy)のbytecodeはないから、
この内積論理演算はarraycopyの代用にもなるんだよね。実質的に演算子だし、追加されてもいいんじゃないのか？

>>164
知らない話題になると揚げ足取りに変身するのは、どの分野にもいるね。
君みたいなゴミはうん千うん万と見てきたよｗ

>>164
昔からいるスレ主だろうけど、君は知らない話題に首を突っ込まないでエスケープ解析だけを頑張ってればいいよｗ

>>167
受け流すヒマがあれば、合理的な反論の一つもしてみたらどうだ？

>>164
人の批判をするなら
まずはアンカーぐらいちゃんと付けられるよ
うになってからじゃないの？ダサｗw

補完とか漢字も分かってないのに批判しだして調子に乗ってるのは笑えるｗ
ていうかどの分野でもこういうゴミが沸いてくるから何にも教えたくなくなるよな。
こういうゴミが一つでもいると、逆にスレを徹底的に荒らす実験でもしようかと思うww
ま、スレが荒れるのも自業自得なんじゃね？ｗｗ

合理的な反論とか意味分からんｗｗ
>>164を見るに、全くわかってないお子ちゃまじゃんかｗｗ
あまりのお馬鹿に笑いが止まらないし鼻くそが吹き飛んだじゃないか！

>>166
リアルでは「ジャバしかやったことありませーん」とか言うレベルだろ。
だから話についていけないし、java.netのキチガイブログを読んでばかりで、次から次と最新技術の追っかけやってるしか能がない。
おまえなんか厨房レベル、つまりジャバ・アイドルの追っかけと同じだろ？ｗｗ

アンカー間違えたｗ
>>163
早く死ね

>>172
朝から顔まっかにして・・・
結局どういう補間が精度わるいか書かないし、DirectXもわけわかってないし。
連投してレス先間違えまくるほど、痛いところつかれたんだな。

あまりに高度・技術な話題に、このスレの住人はついて来れないって落ちだろ。
この程度のスキルで調子に乗るなら、このスレは国内外のリソースとかブログ紹介とかの路線でいいんじゃね？

頑張って難しい単語を理解しようとするのは良い心がけですが、難しい単語が理解できないからといって人のせいにするのはいけません。まず「補完」の漢字すら言われないとそのまま間違って覚えてたでしょｗｗ
人のことを「ソフト(ダイレクトX）って書いちゃうってことは、DirectXわかってないことバレバレだし」なんていってるヒマがあるなら、そういう癖はすぐに直した方がいいですよ。

>>175
連衡てなんだよ。おまえはさ、妄想もいいかげんにしたらどうだ？おまえがいるとスレが荒れるだろ。

>>175
補間の漢字も知らなかった奴が「書いて欲しい。分かってない」とかマヌケなことぬかすな。ゴミｗ

人工無能君に一人芝居モードでも追加されたのか？

そういや元からあったっけか。

>>164
＞補完で繰り返し収束するようなアルゴリズムなら、ハードが速くなると解決するね。

人工無能君のこの発言の意味がわからないんですけど、たとえばどういうアルゴリズムで補完することこのような現象になるんですか？
それと座標補完ってなんのことですか？

はい補間と補完まちがえました。スミマセン。

で、アルゴリズムわかってないみたいだから説明してやるよ。
>>161のいうような精度の悪い補間は知らないから推測な。

その補間に連立方程式を使うとする。複数点を指定して補間するとすれば、連立方程式解く可能性は高いな。
連立方程式を解く場合には、適当な値を答えとして連立式に当てはめて計算すると、少し正しい答えに近い値が求まる。
さらにその値をもう一度連立式に当てはめると、もっと正しい値に近づく。
つまり繰り返すたびに精度が高い値に近づく。
そうすると、ハードが遅いときに十分な精度まで求められなかったのが、ハードが速くなると繰り返しを多くして十分な精度が求めれる。

連立方程式だけじゃなく、いろいろな計算で、繰り返し回数を多くするほど精度が高まるものがあるから、そういう計算を使うアルゴリズムなら、ハードが速いほうが精度をあげやすい。
だから、繰り返しで正しい値に収束するようなアルゴリズムを使った補間ならハードが速くなると精度の問題が解決する。
わかったかい？

アルゴリズムをちゃんと勉強したことあるなら、>>161 みたいにアルゴリズムの問題がハードが速くなったところで解決できないなどという思想は持ってないな。

>>166
そういうのはJITの仕事です。

ゲーム屋って近視眼の馬鹿が多いね。

>>182
もしナンチャッテじゃなくて少しでも勉強したことがあるなら、そのアルゴに名前とかあるんじゃないの？
O[n log[n]]がハードの性能によってO[n]になったりすることは無いんじゃないかな。
難しい話題に飛び込んで赤っ恥をかく性格だし、ここらへんが人工無能君の限界だったかｗ

＞そうすると、ハードが遅いときに十分な精度まで求められなかったのが、ハードが速くなると繰り返しを多くして十分な精度が求めれる。

こういう発想は根っからの技術者ってところかｗ
それに、有効桁（精度）とアルゴリズムの区別もついてないみたいだし、アルゴうんたらよりもハードでごり押しタイプか。
ダイレクトXのAPIは熟知しているMS信者だとしても、所詮ダイレクトXがなければただの素人だろｗ

>>182
それで、あなたの脳味噌は補完されましたか？ｗｗ

所詮ゴミなんだし、いじめるのもそのへんで・・・

お母さんがゲームばかりしていると馬鹿になりますって言ってました。

がんばって煽ってみたけど逆に恥じかいたって落ちか。
お父さんが言ってたけど「知らないことに頭突っ込んじゃいけない」典型例だな。

>>182
こういう人が他のスレで暴れてスレが荒らされるんでしょうね。
どんなにスキルが上がってもコメネケーション・スキルは中学生レベルですか。
育ちが悪く、どこにいってもいじめられてたんでしょうね・・・

論理的思考力が中学生以下の大人よりましだ

論理的思考力ｗ

スルー出来ないのは厨房だからｗ
よっぽど悔しかったんだろ？ｗｗｗ

>>186
俺は>>182じゃないけど、なんでアルゴリズムの速度の問題がいきなりアルゴリズムのオーダーの
問題にすり替わってるんだか…まあ確かに指数関数オーダーのアルゴリズムはハードウェアが
いくら速くなったところで大して速くならないが、O(n)とかO(n log n)程度のオーダーのアルゴリズム
ならハードウェアの性能向上による恩恵は十分受けられるでしょーに。しかし、アルゴなんて
奇怪な略語をいつまでも使ってる辺りまともな技術者には見えんなあ。

マッキントッシュといっても最近の若いもんには通じません＞＜

アイマックってのはビックマックの友達か何かですか？

>>198
http://ja.wikipedia.org/wiki/IMac

>>186
連立方程式の解き方なら、ガウスザイデル法だろ
「有効桁（精度）とアルゴリズムの区別もついてない」って何言ってるの？
がんばってオーダーの話もちだしたようだが、精度の問題がハードの速度改善で解決できる例をあげただけだろ。定数項の問題。

>>136 が単純なCGの例としてあげてるのであろうナルトのムービー見たらかなり高度なCGで、PS3のCellじゃないとできないような負荷がかかっていそうで笑った。

>>200
がんばって勉強したみたいだね。
おこちゃまは早くおうちに帰りなｗ

>>200
端点の近くで大きく振動する補間関数といわれてすぐ思いつかないならモグリだな。
おまえも大恥かきに来たんだろ？ｗ

ここ何のスレだっけ？

いまだにアルゴの話で負けて悔しがッてる奴がいるんだろ。
どうせ一日中wiki読んで勉強でもしてたんじゃないか（笑）
>>201とかみても妄想癖強そうだし、こいつの人生は一生負け組ｗ

そもそも連立方程式とかいいだしてる辺りから分かってないよねｗ

同じ奴が何度もレスしてファビョってるだけだな
そろそろ正常化したいんでよそでやってくれ

なんか、「ドンキホーテ」って感じだよね。どの板（分野）にもいるんだろうけど。
負け組みに人はどんなにスキルが向上してもやっぱり負け組みなのかｗ

変な流れなので無理やり次世代Javaの話に戻すと、
上の方で話題になったJVMレベルでのSIMD演算器実装はやって欲しいなあ。
で、Mathライブラリの増強かMatrixライブラリの新設で、ベクトルと行列の計算メソッドを作って欲しい。
現状だと自分で組んでるけど、forループ回してfloatなりdoubleなりの計算をさせてるんでスマートじゃない気がするし、
といってそのためだけにシェーダー勉強するのもしんどい。

もっとも、JVMでSIMD演算器を持ってなくても、Hotspotで検出してネイティブSIMD命令に変換してくれれば
それはそれでかまわないともいえるけど。

次世代Javaの話題なんてこのスレはやってないじゃん。
ただの英語ブログの紹介でしょ。サルでも出来るｗ

哀れな男だ

「補完」も知らなければ「連立方程式」を持ち出したりして、頑張って食いつこうとしてるだけの厨房だったか。厨房なのに変な自尊心があるんだろ。無能のクセにｗ

>>209
文脈で検出ってできるのかね? 積和が連続してるっぽかったら変換とか?

ゴスリングも指摘してたが未だに1.4.2とか使って、
Java5以降の構文が使えない環境とか今後どうなるんだ？
SE for Businessとか契約する日本の企業なんてほとんどいないだろ

イメージ加工処理でループ使って配列アクセスする実装が多いし（当然だけど）、それに満足しない人はjniとかでmmx,sse使いたくなる。
ただdot netやcではなくて、javaでプログラムやる人はそこまでネイティブ機能に関心を示すかどうか疑問だからjvmでサポートするのが妥当だろう。
これはjavacの話ではないし。他には動画コーデックとかも負担激減になるだろうな（処理も速くなると思うけど）。

>>213
分岐命令が入らないで積和が連続している部分を見つけられれば、SIMD命令への変換はできそう。
ただ、for文の積和をSIMD化しようとすると、ループアンロールをかけないとマッチングしないような気がする。

Hotspotではループアンロールもやるみたいだけど、ループ回数が可変だったりすると、
プログラマが処理を組まないと自動で効率よくやるのは難しい気がするなあ。

自分の場合、ほとんど3ｘ3と4ｘ4しか使わないから、定数ループにすればアンロールはやりやすいと思う。

>>214
1.4.2なコードなんてゴロゴロしてるよ。
つか、俺はまだ5.0以降が使われてる仕事のコードは見たことがない……。orz

＞気がする

ってなんだよｗ

仕様とかはちゃんと読んだけど、ただの一読者・ただの理想論と同じだな。
こんな糞スレにいるやつの妄想を信用する奴も哀れだ

>>217
自分はホビープログラマだけど、5.0から生産性が一気に上がった気がするけどなあ…
（特にジェネリクス関係とか）
業務用では使われてないとすればもったいない話だ。

>>216
この程度でいきがってるしな・・・
ちょっと知ってる程度で突っ込みいれると恥じかきますよ
財務の話とかも全然しらないんでしょうにｗ

それよか、他の有用な技術的リソースないですか？（日・英）

>>219
まぁ、今後は5.0以降を使うことが確定してるけどな。6.0には行けないけど。
問題はなかなか仕事が取れないことでな……。orz

>>217
俺は次の案件でJava6使ってくるぜ！
会社にJavaの資産が殆どないから気楽なもんだ。

>>219
あと、一般論で言うと、業務系では、技術採用の判断基準は生産性が高いか低いかじゃなくて、
・現場に理解できる人間が十分にいるかどうか(こればっかりはどうしようもないねぇ……)、とか、
・リーダーが理解できるかどうか(これに伴う悲劇は各所でよく見る(-人-) SCMのスレじゃ哀愁を誘うようなネタが……)、とか、
・営業や販社が担いじゃったから無理矢理使わされる(おかげ数年前に死ぬ思いをした上に、未だにトラブル多発)、とか、
・RFPに書いてあったから(コンサルが何か吹き込んだんじゃねーか、これ、みたいな)、とか、
が支配的要因だったりする。

7のクロージャなんて、入ったところで、使えるようになるのは何時の日か。

クロージャはあってもなくても大して生産性は変わらないかな。
リスナとかComparatorみたいな委譲用のクラスは昔からあるんだし。

jdk1.2でも1.5でも動くし全く同じ性能なわけで、1.5やgenericsを強制させる必要もないんじゃない？
早く移行してくれって言うゴスリン大先生の意見も十分わかるが、おれは君ほどゴスリン大先生のシンパではない

ブログネタしか投下できないんじゃ、その程度（権威主義）が限界だろ。
所詮タイマー付き人工無能だし

何か自由にしゃべらせてやっても「気がする」とか言う妄想だらけの>>216ぐらいが限界なんじゃないか？

この板にも、ID表示が欲しいところだな

出す出す詐欺ならぬ出さない出さないツンデレなSunは、
6u11に合わせて1.3のアップデートを出したりようと分からんけどねｗ

＞5.0から生産性が一気に上がった気がするけどなあ…

ここでいう生産性ってのは具体的にはなんですか。
具体的に出て来ないってことは、IT系HPにある宣伝文句の受け売りなだけじゃないですか？

>>228
そもそも6u10とか、アップデートと思わせといて大改造だったしな。
Java6からマイナーバージョンが消えたけど、6.1とか6.5と名乗ってもいいくらいだ。

確かに生産性が上がるんなら大部分のプロジェクトは1.5に移行してもいいし、おかしいよなｗ
マーケティング上（文系w）の宣伝文句に騙されてるだけじゃないの？

SUNは、昔はSWINGを普及させるためライトウェイト・コンポーネントとか言って騙してたからね。
MSみたく次々と新技術のパラダイムを出してきてすぐ裏切ったりしないからまあいいけどｗ
こういう文句に騙されちゃうのは、ここでブログ紹介とかしてる「おのぼりさん」なんだろうｗｗ

>>232 はなにをいきがってるんだ？
基本的な連立方程式アルゴリズムも知らずに>>182書いちゃって、恥ずかしくてファビョってんのか。
連投、自作自演してバレてないと思ってるんだろうか？

ん？アノテーションとか使い出してから生産性は普通に上がってるけど。

>>225
可読性がまるで違う。ジェネリクスのないコレクション使いまくりのソースを追っかけるのがどれだけ大変か。
結局PC上じゃ追い切れずに、印刷して赤ペン持って机上で解析したさ……。

>>209
SSE命令は1.4.2からHotspotコンパイラが利用してますよ。
JVMの起動オプションすらろくに設定したことない人?
このスレにはまだ早いのでは?

最初の一行だけでいいのに。
なんで余計な言葉付け足すかなー

>>237
おまえが無能だからだろｗ

アノテーションは便利ですけど、コードの保守ですよね？
プロジェクトもせいぜい２−３年程度ならいらない感じですけど、
ドキュメント化すればいい程度ならアノテーションは不要だし、それによってどういう生産性が上がるんですか？

>>171
>こういうゴミが一つでもいると、逆にスレを徹底的に荒らす実験でもしようかと思うww
>ま、スレが荒れるのも自業自得なんじゃね？ｗｗ
アルゴ君、あなたは他人を煽る前にまず自分の人格を見直すべきです。
批判レスがいやなら最初から一切書き込みしないようにするしかありません。

>>227
>>161まで普通にレスしていたアルゴ君が>>164で批判されたら
>>167から連投荒らしに豹変した、というだけのことでしょう。
基本的にアルゴ君がひとりでスレ住人を片端から煽っているように見えます。

>>233
>>232は連投しまくっているアルゴ君の可能性が高いですが、
>>182は人口無能君と呼ばれている人で、>>186がアルゴ君では？
高次方程式なら山登り法でないと解けない事もあるでしょう。
http://ja.wikipedia.org/wiki/%E5%B1%B1%E7%99%BB%E3%82%8A%E6%B3%95

自分の無能さをわかってないから世の中が無能に見える典型だな。

>>235
たぶんあなたはOOやUMLとかの近代手法的を使ったプログラミングの設計には向いてないんじゃないですか？
あなたの脳内は未だにフローチャットの延長か何かの旧式のままなんでしょうけどｗ

>>239
XMLの記述が減る。
短いプロジェクトなら、記述量が減るのはうれしいだろ。
Javaで宣言的なコードがまがりなりに書けるというのはいい。

>>240
その「アルゴ君」とはあなたのことじゃないんですか？ｗ
いい歳して、恥さらしするのもいいかげんにしなさい

>>240
ここでは収束する計算の例としてガウスザイデル法を使いました。

>>240,241
あなたは確かに無能のようですね。
多少スキルがあるみたいですけど、せいぜい中級車って程度ですよｗ

勝手な妄想ばかりして「可能性が高い」とか「気がする」とか、何か根拠でもあるんですか？ｗｗ
あなたが「可能性が高い」とか「気がする」ばかりかいてある誰かのアホブログを見たらそのアホを信用しますか？ｗｗ

>>182は人口無能君ｗｗ

>>240
てか、あんたいいかげんウザイよ
なんか説教してるようだけどまた漢字間違えてるし、高度な知識があるわけでもないくせにいいかげんその高慢な態度を改めた方がいいんじゃないですか？

人様に人格を見直せというなら、まずはあなたが率先しなければ何も始まらないでしょう。

>>246-248
同一人物だろ。かまってちゃんか

風紀委員長が女便所に常任していると聞いてやって来ました！

>>236
> JVMの起動オプションすらろくに設定したことない人?

SSEがらみのJVM起動オプションてどれ? 探し回っても、-XX:UseSSEしか
見当たらなかったんだ。これ、JVMのオプション一覧には記載されてないし、
1.4.2のSSEのバグ(fix済)回避専用みたいだから、これじゃないよなぁ。

それに、確かに1.4.2のリリースノートにHostspotでSSE/SSE2使ってるぜ!!
とは書いてあるんだけど、何をどう使ってるのか、という情報も

海外のブログだとそういうアホ記事が多いよね
英語でかいてあるから、それも大事な部分が砕けた英語だったりするとなおさら日本人だと分かり辛いんだけど
そういうアホ記事に洗脳されちゃう人なんじゃないの？根っからの理系とかｗ

>>251
切れたorz
何をどう使ってるのか、という情報も見つからないんだよね。

>>252
だなｗ

>>252 と >>254 のような自作自演、前も見たな。

>>255がどんどんとこのスレの主になっていく件について？

>>240
そもそも、ageで煽って回ってる人は何をしたいのかわからん。
他の人の書き込みを煽るだけで、話題を提供しようとしてるわけでもないし。

http://hamletdarcy.blogspot.com/2008/12/java-7-update-from-mark-reinhold-at.html

クロージャ、プロパティ、refied generics、演算子オーバーロードあたりが全滅か。
JSR295が入らんのも地味に痛いなぁ……

演算子オーバーロードは未来永劫Javaに入ることはないんじゃなかったっけ？

Multi catch (yes!)
null checks (yes!)
とかいってる奴のブログなんか紹介するんな。キモイ。
それにjdk1.7は１年半も先だし、上で指摘されたばっかりなのにおまえは洗脳されやすいんだなｗ

>>258
Java7があと1年遅れればそのへんも復活するかもよ

>>257-259
提供してみた話題は叩かれるし、それでも我慢してスレに張り付いてるのはよっぽどヒマ人なんですねｗ

indexerも入んないの？

closure 要らんから、せめて function type だけでもくれ。

アップデートとブログ紹介しか出来ない人工無能に、ヒマ人とか直接言っちゃったらかわいそうだろ。

>>263
そもそも入るなんて話あったの？

aheのウィッシュリストにはあった

なんだ。ただミーハーだったのかｗ

indexerや演算子オーバーロード付けるくらいならもうjava言語捨ててC#準処にするべき

そういう考え方もあってもいいけどね

javaVMで動くC#を

逆だろ。.Netに手軽にアクセスできるjvm (java)。

そっちの方はScalaが頑張ってるね

ほんとか！で.Netで動くScalaじゃ意味ないよな。結局やってることはjrubyと同じだし。

>>267
ウェブ・ブックマークのネタはもう切れたんですか？ｗ

BigDecimal シンタックスの話なんてあったのか。欲しかった

なかったと思う

演算子オーバーロードの文脈の中で
ユーザ側で自由に定義できる演算子オーバーロードはダメだけど
BigDecimalなんかは特別扱いで演算子使えるようにしようかって話はあった。

さすが、JAVAのことなら隅々まで追いかけてますねｗ

前スレか前々スレあたりで出てたと思ったが。

>>276
http://blogs.sun.com/dannycoward/resource/Java7Overview_Prague_JUG.pdf
の 28枚目あたりにある。

XMLリテラルとか懐かしいな。

multi catch って型の扱いどうなるんだろ？
ExceptionA extends Exception { public void method(){} }
ExceptionB extends Exception { public void method(){} }
catch (ExceptionA | ExceptionB ex) で ex.method() 呼べたら面白いけど
たぶん無理だろうなぁ。

インデクサってか演算子オーバーロードの類は要りません。
もちろんプロパティとかも要りません。
メタプログラミングをこれ以上推奨しないでくれ。

>>282
無理だろうな
使えるのThrowableのメソッドだけだろ

Javaってgetほにゃららとかsetほにゃららとかやり続ける気なの？
馬鹿馬鹿しくならない？

>>284
Throwableだけに制限する必要は無いでしょ。一般には
Exception1,Exception2,...ExceptionNの共通のスーパークラスを計算できるはずだから
そのスーパークラスのメソッドは呼び出せるようにすればOK

>>283
そんなものはメタプログラミングでも何でもない。

>>285
言語仕様を次々と拡張されるよりはマシ

>>272
IKVMどうだ？
http://www.ikvm.net/

>>289
そんなのあるのか。
普通に想像できることは他の人が既にやってるよな。

JavaFXってJCPで管理されてる仕様ではないよね？
Java7でクロージャ導入して、FX向けのアノテーションもバリバリサポートしてくれないかなぁ。

JavaFXは結構はまるよね。プロパティ設定のコード書くのも楽だしIDEいらないぐらい。
コーデックとかメディアプレヤァに力入れてるけど、2.0になったら3Dとかもやるのかな？

JDK7 build42
http://download.java.net/jdk7/changes/jdk7-b42.html
http://download.java.net/jdk7/binaries/

で、Java7でのマルチコア対応ってどうなってるの？
並列APIはできてるし、後はJVMレベルでどれくらい対応するんだろう？

現状は放置？

>>294
どんな機能を期待してるの?
単にスレッドが各コアに分散されることを期待してるだけなら、1.3か1.4
あたりからネイティブスレッド対応なので、既に対応済みとも言えるが。

コンパイラで並列化した中間コードを吐けるようにしてくれ

>>296
必要ないです。

>>297
なんで？
あったら便利にならんかね？

普通に書いたプログラムを自動で解析してなんとか並列化してくれ

んじゃあMVMだな
これが出来ればマルチコア対策になるんだが、無理そうだよね

>>298
コンパイラじゃなくてVMの仕事です。

すまんが>>300の理屈が理解できないので詳しく教えて欲しい。
結局、マルチコア対応を行わなければ、MVMで合っても並列処理できなくね？
MVMでもネイティブスレットレベルでしか並列化できないような気がするんだが。

>>300
MVMがマルチコア対策になる理由がわからない。
メモリ等のリソース効率はともかく、CPUの利用という意味では、
複数VMを立ち上げるのとそう変わらないのでは?
それとも俺が何か勘違いしてる?

MVMのおかげで僕にも彼女g

300ではないですが、MVMのプロジェクトでは、
複数のJVMで実行していたものを一つのJVMで実行するための基盤、
multi-tasking JVMの作り以外にも、排他制御の効率化なども研究してます。
同じバイトコードを実行しても、複数のタスクが同時に動くと、
内部リソースに対する競合が出る可能性があるのですから。
そういうボトルネックを消し去らないと遅くなってしまいます。

あきらめろ
MVMはJNIがあるかぎり実現は出来ない
絶対に、だ

>>305
それって>>299の要求してるモノなの？

>>299に返事してません

排他制御の効率化なんてMVM以外でもやってんだろ

http://www.infoq.com/jp/articles/java-threading-optimizations-p1

>>306
MVMを利用する条件にJNIの利用禁止をつければよくね？
SingleVMも生かしておけばいいと思うんだが。

MVM-lite という項目はある。maybe付きだが
http://java.dzone.com/articles/java-7-update-mark-reinhold-de

SwingFreamworkが入らないかもしれない、というだけで幻滅した

>>310
全然役にたたねえなこの記事ｗｗ

>>313
swingはいらない子
遅いし、遅い

Swingはやればできる子。WinFormsなんかにくらべるとよっぽど筋がいい。
でもSwingFrameworkは、使いにくいからいらないです。

おみくじ

てｓｔ

で、delegateは入らないの？
lambdaは？

delegate気持ち悪くない？
eclipse使えば一発で挿入してくれるしいらんわー

これだからIDE使っての開発しかした事のない奴は。。。

IDEじゃなくてもそんなもんPGなら挿入してくれるようなのつくっときゃいいっしょ

今どきIDE使わない環境なんてあるの？

>>323
つ 現場によりけりでない場所もある

で、delegateは入らないの？
lambdaは？

ってのは例えば何のこと？
C#使えって落ちじゃないよなw

JVMのモジュール化のほうが先だと思うんだよなぁ・・・

もうめんどくせえからScala使っちまえよ

一番簡単なのはdelegateとlambdaを金輪際使わなければ良いんだよ☆

もうレガシーとして余生を送れよ

swingに限らないが、もうちょっと速くならないだろうか
そういえば、似たようなことしてるのに、.NETは速いのはなんでかね？？

言語仕様がクソすぎてＩＤＥ無しじゃとてもプログラミングできない。

例えばどこらへんの仕様？

イベントリスナとかイベントリスナとか

イベントリスナは言語仕様じゃなくて標準ライブラリの部分だろ
イベントリスナというモデルを採用せざるを得なかった言語仕様が糞だというのなら
話はわかるが。個人的には最初からクロージャがあってそれをベースにした
イベントモデルになってたら良かったなあと思う

↑
おまい、「ハローワールド」 しか作ったこと無いだろ。

関数型もラムダ式もないからイベントリスナが必要になり
無名内部クラスなんていう全くシンプルでも便利でもない
ウンコみたいなものに頼らざるを得なくなった

関数型は欲しい。
Generics入れるときにいじったんだから、そこで入れちゃえば良かったんだ

そうするとポインタ型も導入するか。

ポインタは難しい。理解できないってヤツが増えたから
なんでもかんでもオブジェクト型で片付けてしまおうとしたのが失敗だったな。
こんどは、オブジェクトは難しい。理解できない、ってヤツが増えた。
ポインタを理解できないのなら、オブジェクトも理解できない。

>>338
アドレスってGCの世代管理で変化するんじゃないの?

そりゃ機能を追加すりゃあ、その部分については便利になるだろうが、
なんでもかんでも追加すりゃいいってもんじゃないよな。
言語仕様に手を入れるなんて、不便でどうしようもない部分を直す
程度でいいよ。
新しいパラダイムを使ってみたいだけなら、Scalaでもなんでもあるし。

また麻布か・・・

まぁC++よりはずいぶんマシな言語だからな
正直言語使用としてこれ以上必要なものはないわ
後はJVMのほうの改良ぐらいじゃねーの？

結局、JAVAは別の言語の実行環境などの役割にシフトして行くだろう
JAVAに替わるものが出ない間は

>>338
「難しい、理解できない」ではなくて、「正しく動くことを保証するのが難しい」だろが。

関数型はいらない。
クロージャーが欲しい

関数型なしでクロージャをどこに入れとけばいいんだ

匿名クラスにローカル変数を取り込めるようにするとか
例の{int, int => int}よりはマシな気がする

evalが欲しい

evalは流石に・・・

evalするならGroovyでいいじゃないか

Rhinoのこともたまには思い出してください。

class MyFrame extends JFrame {
public MyFrame() {
addMouseListener(new MouseHandler());
addKeyListener(new MouseHandler());
}
class MouseHandler extends MouseAdapter { // ←Mouseイベント処理ブロック
// Mouseイベント関係だけで利用する変数をここで定義
// ここにMouseイベント関係のメソッドをまとめて記述
}
class KeyHandler extends KeyAdapter {// ←Keyイベント処理ブロック
// Keyイベント関係だけで利用する変数をここで定義
// ここにKeyイベント関係のメソッドをまとめて記述
}
}

お互いに関連した処理や変数を名前つきインナークラスとして、
記述してやることで極めて可読性が高いソースコードを記述できる。
関連した処理が複数があり、そして複雑な処理になりがちなイベント周りでは、
「名前つきインナークラス >>> クロージャ」
異論は認めない。

無名インナークラスではなく、名前つきインナークラスをもっと使いましょう。

イベントに対する処理をクロージャで書くべきではないのは同意だけど，クラスは無くていいよね
メソッドをそのままオブジェクトとして渡せれば一番わかりやすい
まとめてインターフェイスにしてるとイベントを後で追加するときに困るし

>>348
つjavax.script API
対応言語の一つに「Java」がある:-)

ボタンをポチッと押したら変数aの値をインクリメントしたいだけなのに〜
って場合には、簡易な記法でクロージャーを使えると有り難い。

名前付き内部クラスだとイベントハンドラをadd***Handlerしている箇所
からググッとソースを下にスクロールしないと処理の実装(a++;)にたどり
着けないので、簡単な処理を沢山登録する場合は可読性が悪い。
可読性を改善しようとするとMouseHandlerToIncrementAとか何とか
処理内容をイメージ出来る内部クラスの名前を山ほど考えなければなら
ないので、面倒。
無名内部クラスも処理の実装の前後にノイズが多すぎ。

クロージャーや関数型を導入しても、既存の名前付き内部クラスを用いた
Strategyパターンとは上手く共存出来ると思う。

>>355
> ググッとソースを下にスクロールしないと

EclipseならCtrl+クリックでおk

>>355
>ボタンをポチッと押したら変数aの値をインクリメントしたいだけなのに〜
>って場合には、簡易な記法でクロージャーを使えると有り難い。

クロージャいらない派の人は、「今はインクリメントだけでも、将来的には変わるかも・・・」
という予想をするんだと思う。
結果、それだったら今のうちからインナークラスにしとこ。って考えになる。

きっとクロージャいらない人は慎重で心配性な人。
そういう人たちは無名クラスもクロージャもいらないと思ってるんじゃないかな。

今な享楽に生きる大雑把な自分は、やっぱりクロージャ欲しい。

というかクロージャの中に直接処理の実装を書いても良いし、
処理が複雑なのであれば別メソッドでも名前付き内部クラスでも
お好きなやり方で別途処理を実装してそれをクロージャの中から
呼び出せば良いと思う。
クロージャのある世界では、大雑把な人も心配性な人も共に
そこそこ快適に生きていけると思う。人類皆共存、めでたい。

というわけで世界平和のためにはクロージャが必要だと思う。

クロージャの主な用途は
コレクションに対して一気に処理を適用したり
Openした後自動的にCloseするようにしたりといった
メソッドを引数として与えることで再利用を促進することだよ

無名クラスやインナークラスもいいんだけど、そもそもMVCのそのCの部分は分離できるんじゃないかを考えてみたらどうだ？
その仕様だとマウス・キーのリスナのところが該当する。
分離できない程密接ならprotected のイベント用メソッド使うのが普通だけど、初心者向け教科書のままでコンポーネント開発したことないと分からないか。

>>359
javascriptにある onClick= ってのは魅力的じゃないか？
コレクションていうのも分かるんだけど、Cで言えばqsortに関数ポインタ渡すのとやってることは大して差はないし。

>>359
両方とも無名クラスでも出来るんじゃないかい。

MartinFowlerの見解にほぼ同意なんだけど、簡単に使えて
初めてクロージャは嬉しいと思う。
シンプルな記述で定義出来る事はもちろん。
環境中の変数を参照出来て嬉しいのも、クロージャ内の処理に
必要な変数値をsetする手続きの大半を省略する事が出来るので、
結果として少ない手間で同じ事が出来るからだと思う。

なので毎度function云々と書かなければならないJavaScriptの
書き方は実はそれほど好きじゃない。

>>362
何を言いたいのか意味が分からないんだけど
ただ短く書きたいだけってならsetter/getterのプロパティ表記と同じことじゃないの？ｗ
MartinFowlerの見解なんかも、君の脳味噌じゃ理解できなかったようだ（笑）

swing関連のフレームワークが欲しいが、それはベンダが提供すれば言い話だしな・・・
sunが提供してNetBeansに組み込んでくれないかな〜
そうすればMFCのようにデファクトになるのに

後、クロージャは微妙だなぁ
別に無くても困らないし・・・

>>364
Swing Application Frameworkは、すでにsunが提供してNetBeansに組み込まれてるわけで
クロージャーなくて困らないのはクロージャーつかったことないからじゃないのかな。

>>364
swingがGUIのフレームワークなわけで、既にjdk 1.2で取り込まれて、デファクトになってるがそれでも不満か？ｗｑ

フレームワークは玉葱の皮のような状態だからね〜

ネイティブコードでコンパイルできるようにならんかねぇ

>>365
おんなじJavaを使っても、クロージャを使ったことがある人は困って、
使ったことがない人は困らない？
そりゃ変な理屈だろう。

携帯電話のない世界に住む人が携帯電話がなくて困るわけがないだろう

クロージャのない言語はクソ

Control invocation syntax 萌え
ビバ、BGAA！

>>369-370
今日のベストアンサー賞

しかしJavaが和暦に対応したばっかりなのにもう平成が終わりそうだよ！

でも、携帯電話があったらなぁ、と夢想はする。

>>370
それはクロージャが携帯電話みたいに一度使ったら手放せないほど
便利だという前提での話だね。
アマチュア無線だったらまぁ、あれば便利なんだろうけど、それがない
世界に行っても俺は困らないや。

クロージャーは便利だね。一度クロージャーがある環境になれると、クロージャーなしの環境は不便。
クロージャーがある環境というのは、文法がクロージャーに対応してるだけじゃなくて、ライブラリもクロージャー前提になってるのな。

クロージャがあれば苦労しなくて済む

クロージャはJavaFx Scriptで使えるから暫くはこれで遊んでいよう。

しかし、
クロージャは入らない

残念ｗ

java7は地味なリリースになりそうだな・・・
目新しいのはJAMぐらい？

クロージャって便利何だけど、今のjavaに自然に含める文法を考えるのが相当難しいんだよな。
正直 => みたいな文字が入るぐらいなら無いほうがマシって気にもなる。

まぁ、ジェネリクスの<>も最初拒否反応出たけどすぐになれたから、すぐになれるものなのかもしれないけど。

クロージャでクロー知らずジャ

button.Click += (sender, e) => {
　var averageAge = persons.Where(p => p.Sex == local_Sex).Select(p => p.Age).Average();
　MessageBox.Show(averageAge.ToString());
}
今のC#なんかこんなことになってるからなw

やっぱり
+=
これにはとても抵抗があるな。パッとみ、Clickの回数を+=するとも見えるし、
オーバーロードと分かっていても抵抗がある。

ただ、こういうの（簡略表記というか）はjavafxの方に流れてるからなぁ。

>>385
オーバーロードは違うな
プロパティと一緒だよ
プロパティに=を使ったらgetter/setterアクセサメソッドの呼び出しになるでしょ
それと同様に，+=はaddアクセサ，-=はremoveアクセサの呼び出し

javafxだとイベント系の処理はクロージャよりbindで済ませることが多いかな。

今落ち着いて考えると、
ジェネリクスはいらなかったと思うんだ

いやさすがにそれはない

ワイルドカードはいらなかった

ジェネリクスをイレージャタイプにしてしまったのは拙速だったとはいわれてるね。

VMの互換性の重視と
必要ないって意見に配慮して穏健なものにしたからだろうね。

GenericsはC++のテンプレートと全く違うんだけど？
違いが分からないなら使わない方がいいよ。どうせ「長くて可読性が」どうとかこうとかなんでしょ

ランタイムサポートされたGenericsの世界を知らないの?
C#なら型やメソッドを型パラメータごとに動的生成したりnew T()とかできるんだぜ

Mbeanをもっと作りやすくしろ

>>394
なに頓珍漢なこと言ってるんだ。
イレージャタイプって意味も分かってないのか。

Googleで検索しても実質0件だがなあ

『「実質0件」でぐぐって50件くらいしかないから「実質0件」という日本語はあまり使われていない』
というのと似たようなものだな

ググっても意味がわかんなかったといっておる

英語分からない人は、こういうこと知る機会は制限されてるでしょ。

Type Erasure（型消去)ってことね
イレージャタイプじゃでてこんわね

>>397
それなら、イレージャタイプから消えた方情報（クラスなど）を動的に知る方法を教えてくれませんか？

erasure形式っていうことじゃねぇの？

>>403 は子供みたいなこと言ってるし、これは荒れるな

互換性との兼ね合いでこうなりました、終了。でいいじゃん。
new T()はできないけど、
T newInstance(Class<T> cls) { return cls.newInstance(); }
で実用上困らないし。

>>406
T.classとかできないからそのgenericクラスorメソッドから
そのメソッド呼ぶのが難しい
どこか(大抵はコンストラクタか)でClassオブジェクトもらわんと

>>392
Genericsも寸止めあったぞ。拙「速」ではなかった。
しかしすごい残尿感が今でもある。

ゴスリンたちの感覚ではBGAAは過激過ぎるのかもね。
俺はプログラミング言語系のこういう単純なアイデアでは久々に萌えたけども。
Closure invocation syntaxにはさ。

リアルで残尿感が・・・寄る年波（泣

はじめはコレクションのキャストがなくなると便利だよねってぐらいだったのに、
モノが出たら途端にあれもこれもって状態になったのは覚えてる。

クロージャはそのうち導入されるけどjdk1.7では後続の情報がないから微妙かな。
ただアレだけ斬新なアイディアがたくさん出たから、1.7updateの途中で追加されたり、1.8とかの持ち越されるだけじゃないかと思う。
Generだって未だに良く分かってない人多いし、まだ時期尚早と判断されているのかもしれない。
そうしていると、クロージャある言語js,ruby,schemに人が流れる。ただクロージャのためだけに、C#に行く人はいないだろ。

だから、C++のテンプレートとは全く違うっていってんでしょ。
>>405-407

クロージャやプロパティや実体を持ったジェネリックがC#にはあるでな

>>411
誰がC++と比べてるんだ？

>>408
BGGAのGの一つはゴスリンのGだぞ。

closureのためにC#に行くのは癪だからjavafxで暫く様子見かな。
/* * save usdkrw.fx
javafxc usdkrw.fx
javafx usdkrw
*/
function getfuncs() {
// 空の関数配列がうまく作れないので要素を１つもつ配列を作ってみた
var i = 0; var rt = [ function() : Void { println("aaa : {i}") } ];
while (++i < 10) {
var j = i; insert function() : Void { println("bbb : {i}, {j}") } into rt
}
for (j in [1..9]) {
i++; insert function() : Void { println("ccc : {i}, {j}") } into rt
}
rt
}
for (f in getfuncs()) f();

結局C#でも

delegate(int i){ return i * i; }
この記法では使い物にならなくて

i => i * i
こうなった
クロージャ作るならここまでやらないとダメ

>>411
C++のテンプレートとの違いなんて話題になってないよ。
それをいきなりC++のテンプレートと違うなどとわめいても、だれも相手にしない。

.NET4.0のように、並列機能を強化して欲しい
あっちはfor loopを自動で並列化してくれるようになるらしいぞ

あれは並列化するだけだし
その程度ならクロージャさえあれば簡単に出来る

>その程度ならクロージャさえあれば簡単に出来る
本当？
クロージャを知らないJava世代の俺に例を教えてくれ

Parallel.For(0, 10000, i =>
{
// 重い処理
});

こうしたら重い処理を並列実行してくれるというだけの機能だから

コンパイラいじったり言語仕様拡張していくのはC++で十分。
MSお得意の「拡張・吸収・淘汰」によって技術を食べていっちゃうMSの手口知らないの？
そんなことしていると、そのうちに蛙まで食べちゃう「カオナシ」になっちゃうよｗ

>>410
まあクロージャ入るのは間違いないだろうね。BGAAが。
>>409
いまさら実行時サポートなしのやつだけなのか！って驚きの方が大きかったが。
>>417
C++と同じところ(erasure type)が話題になっていたわけだからね。

>>420
BGAA提案ならfor文に相当するものをユーザ定義できる。
>>421の{ //重い処理 }に相当するループ変数を引数とするクロージャを、
生成したスレッドに実行させる新しい並列forを定義するだけ。

BGAAがあればそういう構文はいくらでも新しく定義できる。
Lock(ロック変数) { 排他処理; }
InputWith(new 対話ウィンドウ()) { 入力処理 }
など。
デストラクタ相当のコードを埋め込んで、close処理もできる。
しかも例外安全で。

並列forを特別扱いで別個に導入なんてpgr以外の何者でもない。

クロージャと通常の処理の外からの見分けが付かないのは
危険極まりないと思うがね

BGAA

>>425
提案読んだことないのが丸分かりだね。
このスレで意見を書くのはまだ早いのでは？

ニューｎファンネルバリアって射撃属性だよね？
だったらスナイプつけて雑魚即死で余裕だぜ！！

>>415
つScala。クロージャが欲しいだけでも学ぶ価値あり、と思ってる。
ただ、IDE(つかEclipseのScala Plugin)がヘボいのが難点……。

>>427
きみ、ヤバイよｗｗ
バカ丸出しだしｗ

Lock lock = new ReentrantLock();
withLock(lock) {
　　System.out.println("Under 'withLock' control.");
}

こんなことが出来ちゃうってのがBGAAだろ
これがぱっと見クロージャを使ってるように全く見えないのが問題だって話だ

そんなん問題にしてる奴なんかいない

だったら問題にせえよ
演算子オーバーロードも認めないくせに
なんで制御構造の独自定義を認めるんだよ

BGAA君

演算子オーバロードを認めて何かいいことあんの？ただの構文砂糖なだけじゃないか。ｗ
上にもデリゲート結合+=の例で書いてあるけど、可読性云々はなしよｗ

構文糖衣ったって+より*が優先されるメソッドなんて作れんだろ
しかしそれがないと多倍長整数も複素数もまともに作れんのだ

BGGAとBGAAとあるの？

俺は演算子オーバーロードも欲しい。
C++やHaskellでの例を見ても、
変態的な演算子オーバーロードは決して流行らず廃れていく。
可読性のあるものだけ残っていく。
boost::expressiveみたいなのが主流になることはない。

おれよくライブラリとか作るけど、例えば多倍長とかも c=a.sub(b);で実際全く問題なんだが？
たとえば、x=a.sub(b).mul(c)でいいんでないの。
どうせ何も作ったことないで人の言いなりロボット君なんだろうけどｗｗBGAA君もｗｗ

可読性

>おれよくライブラリとか作るけど

ですか（笑）

>x=a.sub(b).mul(c)でいいんでないの。

これを見れば分かるように演算子オーバーロードがないと問題があるわけだ
しかしControl Invocation Syntaxはなくても別に困らないわけだ
>>421でも十分使えるからな
むしろクロージャを使っていることを隠してしまうのが問題だ

クロージャも算子オーバーロードもないJAVAなんか糞言語。HTTTPだけあれば俺たちは幸せ！

そうやってPGの方に宗教的制約を課すなら、そもそも演算子オーバーロードなんか不要でもいいんじゃないの？
JAVAの世界にいる本物のSEや本物の職人ではそういう意見が多いんですわｗRUBYIZMなんかよりもよりも実利的ですなｗｗ

表現が全く説得力ないよなあ
意見が多い、か。

常に張り付いてる奴もいるし、雑学ばっかり増やしてるひまあったら手を動かせ。
くだらんスレだｗ

>>443
おまえの頭はおかしいからな。

Control Invocation Syntaxは別にクロージャ使ってること隠してないでしょ
見ればControl Invocation Syntax使ってるのは一目でわかる(=クロージャ
使ってることが一目でわかる)んだから。なんつーか、BGGAの提案書まともに
読んだこと無いやつが多過ぎだよ

あと、クロージャとか関数型の便利さを知りたいならScalaやってみると良いよ
基本的に言語仕様のほとんどの部分でScalaの方が優れてるし(制御構造に
関しては一部劣化してるが)

>>449-450
創価学会ってそんなにいいところなんですか？
みんな笑顔で楽しそうなんですけど・・・

>>450
何が優れてるって？ｗ

確かにScalaの言語仕様はJavaみたいなウンコのはるか高みにあるね

>>453
それでウンコの上で馴れ合って楽しいんですか？

俺はJavaの後進性をあげつらって楽しんでるだけだよ

学会さんですもんね

あの・・・・BGAAってなんですか？

ほんとなんなんだろうな

Java6があまり進化しなかった代わりにJava7は大幅に進化するって聞いてたんですけど、
どの辺がすごくなるんですか！？

すごくなる予定はありません

>>450
まぁそういうの必要な人はScalaとか使うのが正解だよな。
わざわざJavaに追加する必要もない。

>>461
確かにJavaに追加する必要があるかは議論の余地があるけど
クロージャのある言語をろくに使ってみたことも無いやつが良し悪し
についてまともな議論できるものかねえ。

クロージャがあると

string[] fruits = new [] {"apple", "banana", "orange"};
bool flg = false;
foreach(string fruit in fruits) {
　if (textBox.Text.Contains(fruit)){
　　MessageBox.Show(fruit + "です。");
　　flg = true;
　　break;
　}
}
if (!flg) {MessageBox.Show("一致しません。");}

これが

var result = fruits.FirstOrDefault(fruit => textBox.Text.Contains(fruit));
if(result != null)
MessageBox.Show(result + "です。");
else
MessageBox.Show("一致しません。");

こうなるんだぜ

VB?何か汚いなあ

逆にクロージャいれると何か困ることある？
便利そうなのはなんとなく分かったけど。

クロージャ使ってるソースコードが
慣れないと読みにくいというのがあるかな

慣れてなくても読みやすいものなんて

Javaに入るとして、クロージャの引数は型宣言無しで使えるのでしょうか。
クロージャが入ってくると高階関数を使いたくなるのは自然だと思いますが
（それがないならコレクションに対するシンタックスシュガー程度にしかならない）
型推論のサポートが無いままJavaに突っ込まれても、ちょっとマゾいんじゃないかと思います。

クロージャ入れた後で型推論付き（引数の型宣言なし）もできるようにするのは
そんなに難しくないから、とりあえず型推論なしで入れちゃってもOKだと思うぞ。

いや無理でしょう。やはりJavaには馴染まない気がします

>>463
FirstOrDefaultの定義は？
それが汎用的に書けるのが利点だというのはわかるんだけどさ。

というか型推論がないとコレクションに対するシンタックスシュガーとして
すら使いたくないなぁ。面倒くさくて。
というわけで型推論もクロージャも欲しいです。ものぐさとしては。

ですね。
でも型推論を入れてしまうと、クロージャに限らない話になってしまって
（少なくとも見た目的には）もうJavaがJavaでなくなるような雰囲気があります。
だから馴染まないと書きました。

>>471
LINQというライブラリにあるんだけど

public static T FirstOrDefault<T>(this IEnumerable<T> e, Func<T, bool> pred)
{
　foreach(T item in e){
　　if( pred(item) )
　　　return item;
}
return default(T);
}

こういうものだな
thisというのはstaticメソッドをその引数のインスタンスメソッドのようにして呼び出す記法

Javaなら素直にこんな風に書けばいいと思いますが駄目ですかね。

String[] fruits = { "apple", "banana", "orange" };
String result = firstMatched(text, fruits);
if (result != null) {
　MessageBox.Show(result + "です。");
} else {
　MessageBox.Show("一致しません。");
}

int firstMatched(String text, String[] fruits) {
　for (String fruit : fruits) {
　　if (text.indexOf(fruit) != -1) {
　　　return fruit;
　　}
　}
　return null;
}

text.indexOf(fruit) != -1 の部分を汎用的にしたければ
Predicateクラスでも作って引数に渡せばいいんじゃない？
…というのが「Java流」だと思うのですが。

手が滑った。firstMatchedの戻り値はStringに読みかえて下さい

Predicateクラス作れったってめんどくさくて誰もやらないでしょう
関数に分けるより直接書いちゃったほうがコードもむしろ読みやすい気がする

Predicateクラスでも作って引数に渡すのがJava流というのはその通りだと思うし
Google Collections Libraryでも実際にそんな感じのクラスがあったりするけど
いちいち必要になるたびに別個にクラス作らなきゃならんのがダサい
無名クラス使えば記述量は多少減らせるけど煩雑だしな

いや、そういうの(Predicateクラス作れ)をめんどくさいという人
(or そういうのがめんどくさいと感じる規模のプログラム)なら
Javaで書こうとするのが間違ってる。

スクリプト言語とはニーズが違うと思うんですよ。
小さいプログラムを光速で書き上げるところに明確なニーズのある言語なら、
クロージャでも何でも「便利だから」の一点で正当化されると思うんですが、
Javaってそういう言語じゃないでしょう。

いやいや、小さいプログラムに限った話じゃないし、スクリプト言語関係無いから
クロージャ＝スクリプト言語由来の機能だとでも思ってる？

関数型言語由来の機能ですよ。

closure = environment + function
object = state + function

DBにアクセスして結果をブラウザに返すだけのプログラムしか作ってないんだろ？
クロージャとかホントにいるの？

Predicateクラスの中で必要なのは条件のメソッドの中身だけで
他の部分はノイズでしょう

しっかりクラスを作ってノイズをたくさん増やしたところでプログラムが堅牢になるわけじゃなく
ノイズによって可読性が下がっては本末転倒なわけです

FirstOrDefaultのような抽象化は現状のJavaの言語機能では現実的じゃないし
だからといってコレクションに対する定型的な処理を毎回手で書くのもバグの元

すばやく書けるかも大事だけど
可読性が高くバグが入りにくいプログラムを書くには
どういう言語機能が必要かという視点で考えていかないと

クロージャいらね。

関数型とかわけわかんねえものは要らねえよな。
プログラミングは数学じゃねえぞ。

>>483
>FirstOrDefaultのような抽象化は現状のJavaの言語機能では現実的じゃないし
>だからといってコレクションに対する定型的な処理を毎回手で書くのもバグの元

いやいや、論点はそこじゃなくて…

>public static T FirstOrDefault<T>(this IEnumerable<T> e, Func<T, bool> pred)

この Func クラスのインスタンスを生成する構文を言語仕様として導入することの是非、では？

具体的に補足。

>var result = fruits.FirstOrDefault(fruit => textBox.Text.Contains(fruit));

FirstOrDefaultメソッドに渡すpred引数の生成を、上のように書けるところが「凄い」んだけど、
(textBoxが自由変数なので、無名クラス定義の単純な構文糖とは違う)
その凄さがJavaに必要かどうかでしょう。

必要かはともかく、欲しい。

そういった機能を言語仕様に導入しないと
毎回手で書いた方がマシな状態になってしまうのだから
Javaにもその機能が必要でしょうよ

CがC++になったときみたいな論争だね。

>>485
数学的な素養がなくて抽象化もできないお前みたいなやつ
ばっかりだから、ＩＴ業界がデジタル土方って言われるんだよ。

今言えるのは、このスレみたいな状況下でクロージャぶち込んでも混乱するだけ。
プログラマーが苦労するか楽するかだけの問題ならね。

>>492
>このスレみたいな状況下で

２ちゃんねるを基準されても…

>>491
Javaはドカタ用の言語だろ？
ドカタじゃないならHaskellでもMLでも使っとけ

クロージャ使うとこんな感じで書くの？
int[] numbers = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };
System.out.println(numbers.sum());

public static int sum(this IEnumerable<int> e) {
　return numbers.fold(s => i => s + i, 0);
}

public static R fold(Func<R,Func<T,R>> f, R s, this IEnumerable<T> e) {
　R result = s;
　foreach (T item in e) {
　　result = f(result)(item);
　}
　return result;
}

楽に書けるようになれば土方だって幸せ。
通もうなる屁理屈と土方だって使える簡潔さ、両者を満たすのが理想。

というかfoldとかFirstOrDefaultがstatic関数として宣言されているのはどうして？
お馬鹿さんにも分かりやすいように教えて下さい。クロージャの扱いと関係ある？

関係ない

土方としてはクロージャよりBigDecimalで演算子使える方がうれしい
Java案件の多く(金額ベース)は金融なんだからよろしく頼むよ

>>499
泣いた。
演算子の再定義が無い事が今更ながら非人道的だと思えた。

つーかたかがクロージャ一つが要る要らないなんて話になる時点でどうかと思うんだけどね。
そんなにジェネリクスもクロージャも嫌なら、SUNに金出してずっとJDK1.4のサポートしろとでもごねるか、
JDK1.4相当のフリーの実装でもかっぱらってきて自社でサポートするかすればいいのに。
技術もない金も出したくないサポートもしたくない自社で責任持ちたくないドカタ以外使えない使いたくないだけどJavaコミュニティは俺らの要求にしたがって俺ら好みの実装をサポートし続けろってなにそれw

こんばんは、今宵もFX厨が通りますよ

def fruits = [ "apple", "banana", "orange" ];
var inputtext = "apple";
var msg = "";
 : 
SwingTextField { text: bind inputtext with inverse, editable: true }
SwingButton {
  action: function() {
     var hits = fruits[s | s == inputtext];
     msg = { if (sizeof hits == 0) "unmatch" else "match {hits[0]}" }
  }
}
Text { x: 0, y: 20, content: bind msg }
 :

ドカタとしてはControl Invocation SyntaxでRAIIできれば幸せ。

なんでもいいけど、コンパイルが通った後でtype mismatchとかいう例外が起きる言語は使い物にならないよ

>>504
それはつまりキャストのある言語(Java含む)は使い物にならないってことかね？

例外なしでいきなり逝く方が良いと

ジェネリクスがあるのに好き好んでダウンキャストする馬鹿なんてまだいるの？

>>495
それでいいと思うけど
LINQだと(s,i) => s + i と書くけどな

｛引数型リスト、返り値型、例外型リスト｝を全部まとめたものがクロージャの型宣言になって
やっぱりJavaだと型宣言を省略させるわけにはいかないから結構だるそうですね

そりゃ関数型の方でしょ。
クロージャなら戻り値型や例外型は型推論できるし
代入先の情報がありゃ引数型も型推論できる。

Control Invocation Syntaxって値返せないんでしょ
そんなあまり使い道のないケースを言語として特別扱いするのは
筋が悪い気がするよ

>>510
そもそもBGGAだと戻り値型と例外型は型推論してるしな

>>507
好き好んでダウンキャストはしないが、ライブラリ(Javaの標準ライブラリ含む)の都合で
ダウンキャストが避けられない場面はある。それよりも、上で言ってるのは言語の話
であってキャストをユーザが使うかどうかという話じゃないんだがな

>>511
値返せたほうが便利だけど値返せなくても十分使い道はあるよ。

>>511
クロージャはともかくControl Invocation Syntaxは必要かどうかは微妙なところ
だけど、Control Invocation Syntax無いと言語のファーストクラスの制御構造
(forやwhile)と同等のものが作れないからなー(breakとかcontinueなどが使えない
ので)。

>>510
>>代入先の情報がありゃ引数型も型推論できる。

これ重要だ。クロージャを受領する側では型定義を明示的に宣言させる
必要があるけど、実際にクロージャを作って投げつける側ではガンガン
型推論やってシンプルに書ける方がよい。

苦労はなるべくライブラリを作成する人に押しつける方向で。

クロージャの引数型の推論はC# 3.0でもScalaでもやってるし
Javaでもやってできないことは無いだろう。型システム上、
完全な推論は難しいと思うけど、ほとんどのケースでうまく推論できると思う

>>511
クロージャを引数に取って値返すメソッド書くのは自由だよ。

>>510
http://www.javac.info/closures-v05.html
これを読んで、あなたが何を言ってるのか理解しました。

たとえばこれで言えば
{int=>int} plus2 = {int x => x+2};

右辺をクロージャと言って左辺を関数型と言っているわけですね。
私の>>509では、この左辺の{int=>int}をクロージャの型といいました。
結局この部分は何も省略できないですよね。

>>518
Control Invocation Syntaxは扱い上、「文」だから値返せねえという話でしょ
>>511はクロージャだけあれば十分でControl Invocation Syntaxというシンタックスシュガー
は要らんという意見だと思う

なんかあれだな。１年前のクロージャ議論（英語）を見てるようだ。
プロトタイプ実装がダウンロードできるから使ってみるといい。
JAVAクロージャを使ったこともないのに理想であれこれ言う奴が多いから、まだPGの間で導入するかの合意が取れてなってないってのが動流が微妙な理由なのよ。1.7までまだ１年以上あるけど。

それよりも、C#でコード書くともう既に意味不明になってるな。
関数引数の中のthisとかなによ？ｗｗLINTとかドカタ用だしグチャグチャじゃんｗｗｗ
そういうのはVC＋＋だけでやれって。C#をMSBASICみたく汚さんでくれ。（もう遅いけど）
こうやってみるとJAVAは言語仕様の拡張は自然だし安心できる。

関数引数の中のthisは
「インターフェースに実装を持ったインスタンスメソッドを定義する」ためのやり方だな
コレクション一般に対してクロージャを適用するメソッドを書くためには
こういった機能が必要になる

30歳以上の給料の平均を
persons.filter({ Person p => p.Age >= 30 })
　　　　　.map({ Person p => p.Salary })
.average();

こう書けるようにするものだ
これがないと

average(
　　map(
　　　filter(persons, { Person p => p.Age >= 30 }),
{ Person p => p.Salary })))

こうなったり

Iterable<Person>
　result = filter(persons, { Person p => p.Age >= 30 })
　result = map(result, { Person p => p.Salary })
int ave = average(result);

こうなったりする。C#だと正確には

persons.Where(p => p.Age >= 30)
　　　　　.Select(p => p.Salary)
.Average();

こうだけどな

やり直し

30歳以上の給料の平均を
persons.filter({ Person p => p.Age >= 30 })
　　　　　.map({ Person p => p.Salary })
　　　　　.average();

こう書けるようにするものだ
これがないと

average(
　map(
　　filter(persons, { Person p => p.Age >= 30 }),
　　{ Person p => p.Salary })))

こうなったり

Iterable<Person>
　result = filter(persons, { Person p => p.Age >= 30 })
　result = map(result, { Person p => p.Salary })
double ave = average(result);

こうなったりする。C#だと正確には

persons.Where(p => p.Age >= 30)
　　　　　.Select(p => p.Salary)
　　　　　.Average();

こうだけどな

それって多重継承の問題が出てくると思うけど名前空間はどうやって解決してるの？

.NET のクロージャは LINQ のためにあると言っても過言ではないだろう。

「DTO のコレクションに対する操作」を簡潔に記述するための便利シンタックス
として利用するにとどめるのが「.NET 流」であって、クロージャクロージャと
大騒ぎして関数型言語風のプログラムを書き始めるのは、
むしろプログラマとして致命的にセンスがないと思うがどうか。

>>524
こんな風に定義するわけだけど

public static class StaticClass1
{
　public static void Method(this Interface1 i1){}
}

public static class StaticClass2
{
public static void Method(this Interface2 i2){}
}

基本的には名前がかぶると呼び出せない

public class Class : Interface1, Interface2{}

Class c = new Class();
c.Method(); //これは呼び出せない

代わりに
StaticClass1.Method(c);
StaticClass2.Method(c);
スタティックメソッドとして呼び出す

そんなにC＃が好きならC＃でやれよ。
いつのまにか君もMS信者になっちまっちゃってるのかも。

ん、なんかこのスレにアンチMSが紛れ込んでるぞ

>>523
> average(
> 　map(
> 　　filter(persons, { Person p => p.Age >= 30 }),
> 　　{ Person p => p.Salary })))
>
> こうなったり

average(map(filter(persons,
　　　　　　　　　　　{ Person p => p.Age >= 30 }),
　　　　　　　{ Person p => p.Salary })))

わざと見にくくしてないのなら、こうインデントしてくれ

Javaスレで違う言語の話ばかり延々とされてもな

じゃあC#の話は禁止で。

>>525
大騒ぎするもんでもないが、「DTOのコレクションに対する操作」を簡潔に記述するための
便利シンタックスとしてしかとらえられてないんだったら見方が狭いとしか言いようが無いな
あと、.NETのクロージャがLINQのためにあると言うけど、それだけではないでしょ
クロージャ自体はLINQが入るはるか前の.NET 2.0からあるんだし。

↑Javaと関係ないからレス禁止な

LINQのために追加されたのはラムダ式だな

ボクシングやアノテーションなんてのはC#の後追いなわけだし
プロパティもクロージャも後追いなわけで
Javaに追加する言語仕様の話をするならC#の話は避けて通れないだろ

お前Javaに追加する言語仕様の話は一切してなくてC#の言語仕様の紹介しかしてないだろ
だからスレ違いだっつーの

>>535
後追いっつうのはちと語弊があるな。別にクロージャはC#の専売特許でもなんでもない
そもそも関数型言語由来の機能だし。あと、BGGAのクロージャは、C#のそれとはかなり
違うものだから。

話をJavaのクロージャに戻すと、Control Invocation Syntaxは結構便利だと
思うけどなー。サンプル版使ってみたけど、これ使うの前提でIO関係のライブラリ
作ればこれまで面倒だった処理がかなりすっきり書けるよ。

Control Invocation Syntax使うために標準ライブラリを書き直すつもりなの？

>>535
ボクシングは関数型言語の後追いですね。
そのためにSPJがMSRに呼ばれました。

IO関連だけならライブラリ書き直す必要ないし。
コレクションでLINQ的な使い方するなら拡張メソッド導入するか
標準ライブラリ書き直しかする必要あるけど。

冷静に考えると、
ボクシング、アンボクシングは心底いらないと思う

http://journal.mycom.co.jp/column/jsr/058/index.html
ここにあるような自動クローズ機能を持つwith文だと
try {
String text = "";
BufferedReader reader =
new BufferedReader(new FileReader("in.txt"));

with(BufferedReader in : reader) {
text = in.readLine();
}
} catch(IOException ex) {
ex.printStackTrace();
}

結局withし忘れたらどうするんだという話になるでしょう
理想を言うと

try{
File file = new File("in.txt");
openRead( BufferedReader reader : file){ ...(ファイルを処理) }); //自動クローズ
}catch...

openを呼び出した時に渡すクロージャからしかアクセスできなくしたいじゃない

クロージャは導入されるから安心しろ。問題はそれがいつになるかだけ。
それと、専売特許以前に、C＃とJAVAを比較しても全く意味ない。もともとC#（.Net)がJava/JVMのマネでしょｗ

比較しても意味ない？
なんでそんな非科学的なの？
後を追ってる言語が先を行ってる言語を参考にするのは当たり前のことだろ
Javaはもはや後進言語だってことを認識しなさい

後進でいいよ。
下手に先進的な機能つけて失敗された方がかなわん。

>>546
MFCのことを侮辱するのはいい加減にしてください。

ん、なんかこのスレにMS信者が紛れ込んでるぞ

大きな改変がないんなら、リリースやめてもらったほうが1.4延命できていいんだが

>>549
既に死んでるじゃん、1.4。

JavaとC#が互いにどっちが先進的だとか何とか、アホかと
closureなんてsmalltalkにだってあるだろ

>>551
土方言語限定の井戸端会議ですから。

クロージャなんぞLispからあるわ
じゃあ今のJavaが目指してるのはLispか？違うだろ
Javaは今C#を目指してるんだよ

今となってはMFCのためにMSに金払って買ってたのがバカらしい

たぶんControl Invocation SyntaxもC#に先に入ると思いますw
javac.infoの中の人、MS行っちゃったし。

C#で実験してくれるならそれもいい。

Apache+Tomcatの構成が廃れない限りC#はJavaに勝てないと思う

MSにとってどういう扱いなのか知らないが、Javaにとっては完全にC#は実験台だよね。
C#がどんどん仕様追加して、美味しい（問題がなさそうな）とこだけJavaが頂戴する。

正直MSの方向性は謎

企業としては利益を追求しすぎでコミュニティにそっぽを向かれ
そのくせ、出てくる製品は先進的すぎて企業にはそっぽを向かれ

何を狙ってるのかさっぱりわからん

先駆者である必要はない
より使えるものになればそれでいい
使えなくなれば他を使えば済むだけ
道具のひとつと一緒に心中するなんてやつはいないだろ

誰にとって使えるものになってなきゃいけないかって視点だな
JavaやC#みたいな言語はドカタに使ってもらえなきゃ意味がないわけで
最近のMSはその辺り勘違いしている気がするな

おまいらマ板ネタになると俄然元気になるな

プログラマ以外Javaなんて使わないだろ

無名内部クラスとか
基本型が使えないジェネリックとか失敗だし
何よりブサイクでしょう
オートボクシングもボクシングを推奨してるみたいになって最悪

で、今度は引数の型が省略できないクロージャだよ
Javaの委員会っていうのは変態の集まりなの？
ブサイクなのが大好きなの？

オープンソースの台頭によりSUNが死滅してJava健全化。
喜んだのもつかの間、旗振り役がいなくなってJava死滅。
今後の予定です。

基本型をジェネリックに使うのはerasureでは無理だからな
C++みたいにコンパイル時に作るか，C#みたいに特殊化したコードを実行時に生成するかしないといけない

次のVM仕様で実行時タイプサポートが強くなるから、
もしかしたらGenericsでの基本型の扱いも変わるかもしれない。
今のVM仕様のままだと、他の言語で不便だから。

＞基本型が使えないジェネリックとか失敗だし

やばい黒柳徹子が頭から離れない

age棒はやっぱりというかMS狂信者なわけで・・・

genericsが基本型に対応したらT extends Object//基本型はダメ
が出てくるのかなw

Javaはもともと、委員会症候群により仕様が肥大化したC++への
アンチテーゼみたいな矜持があったように思うけどねぇ。
それで逆にJavaBeansやannotationなんかは、構文の拡張を
しないがためにかなり無理のある仕様になってしまったくらいだし。

いつからこうなったのか知らんが、このまま「書くのが楽なら何でもあり」な
Perlみたいになっていくのかね。

楽は目指してないような

JavaBeansを言語仕様に組み込んだところで（プロパティとか）、コンパイラが複雑になるだけだし変わらん。
Cがなぜ普及したかは、全ての言語機能をライブラリにしたからじゃなかったか？そういうの知らないで育ったゆとり世代なのか。ｗ

長い上にロジックが変。
悪いプログラムの見本のようなレス。

全ての言語機能だって？
ライブラリしか残らんじゃないか！
この世の終わりじゃ！

>>572
んでも、少なくともここでクロージャを欲している人はそういう意見なんじゃね？
その程度でいちいちクラスを起こすのは面倒いって。

面倒もあるけど、限られた言語機能の使い回しに伴うノイズが多すぎる。
特に匿名インナークラス。

一言で楽したいって言っても人によってイロイロあるからな
例えば楽したくても演算子オーバーロードは絶対駄目な人もいれば
BigDecimal特別扱いでいいからつけてよって人もいるし
インデクサ程度ならって人もいるし
制限なしの演算子オーバーロード欲しいって人もいる

後から読む人が犠牲になるような書き易さは害悪

Control Invocation Syntaxはライブラリの乱立を招きかねないという懸念があるよね

今だってじゅうぶん乱立しとるがな

乱立が必ずしも悪いとは思わんけどね
ライブラリ間で競争するだろうし

Control Invocation Syntaxあると、なんでライブラリ乱立するの？

あるとこでは自動クローズ構文がwithで
別のとこではusing, withは別の構文で使われてるみたいなことになるかもしれない

MSのVJ++のデレゲートは叩いたのになんでいまさらクロージャ？

>>584
標準ライブラリでもバイト配列への変換が getBytes だったり toByteArray だったりするわけで、
その程度なら乱立しなくても標準ライブラリ内で不統一って事もありうる

>>584
そんなのクラス名、メソッド名も同じじゃんw
>>585
JCPでやってることと、一企業の独善的な拡張は違うよ。

クロージャとVJ++のデレゲートは別モノだろ

>>588 kwsk

クロージャと同じなのはC#の匿名デリゲートだろ
VJ++のは関数オブジェクトじゃなくてメソッドポインタだし

javaのはなしから脱線してすまないが流れ上説明するよ。
delegateがクロージャとしての機能を持ったのはC#2.0(.NET2.0)からで
VJ++のdelegateはC#1.0のそれと同じで動的にも静的にもスコープは持たない。
安全な関数ポインタというだけのものだった。

そうえばjavaのクロージャは既存のメソッドとの互換は
あんまり考えてないように思えるけどどうなんだろ。
たとえば　int hoge(int i) { }　と　void func({int => int} f) { } があって
func(hoge) といった書き方ができないよね？

関数ポインタとメソッドポインタは全然違うわけだよ
メソッドポインタを関数ポインタで無理やり書けば

Result Method(void* obj, Arg arg1,...)
objの部分を型安全にしたのがメソッドポインタで、
objに処理に必要な変数を自動で入れてくれるのがクロージャ

VBやりすぎると頭おかしくなるって言うけど、C＃もやるすぎると頭おかしくなっちゃうんだね

>>587
JCPとかいってSunという一企業の独善的な拡張と大差ないだろ
だからApacheは反対票入れまくってるし

票も入れられねーし

>>587
言語仕様なんて、確固としたポリシーがありゃ独善でいいと思うが。
逆にコミッティシンドロームに陥るほうがまずいだろう。
＃MSに確固としたポリシーがあるかというのはされおいて。

それはされおき、独善の意味を良く考えれ

C#にはヘジたんという言語設計のプロがいるが
Javaは素人が寄せ集まってるだけなので
どちらが優れているのかは言わずもがな
このままでは差は開いて行くばかり

>>597
http://www.sanseido.net/

>>598
それを言うなら、Sunだって言語仕様策定のプロ中のプロのGuy Steele Jr.が居るだろw
まあ、Guy SteeleはJavaに関しては言語機能を追加する方向では
関わって無さそうな気はするけど。

>>600
仕様策定ではなく仕様書作成に関わってるだけじゃね？

GLSは仕様策定のプロというよりも仕様書書きのプロだろ

しかしSchemeは最初からボスと二人でやってるからなあ。
あれだけでも凄い。
他にもConnection Machine Lispがある。
これも強烈。

以前も書いたがライブラリの仕様はJCPのようなプロセスは必要だと思うが、
言語仕様は天才のひらめきが大事だと思うんだよな。
今の状況は船頭多くいして何とやらだ。

正直言ってGLSが最初から設計してたらJavaはもっとましな言語だっただろうな
というのはFortressの言語仕様見てて思った。近代的な静的型言語なら最初から
あれくらいは欲しいところだ(並列処理や演算子オーバーロード周りの部分はさすがに
チャレンジングなところがあるけど)

>>602
仕様書書くことと仕様策定は密接に関わりがある作業だと思う。
それに、仕様書書くだけじゃなくてC,Fortran,Common Lispとかの仕様
策定にも関わってたはずだけど。

Common Lispの仕様策定に関わってたらマイナスだろ
取捨選択せずにすべて取り込むとかセンスがない
ただし、あれを書き上げたのは天才

Ken Arnold や James Gosling がスルーされてカワイソス

ようやく分かった
Javaに足りないのはHPC対応だよ

はよ対応しろ

Javaは1.4.2で一応の終焉を迎えたというのが俺の見解。
結局の所、その後の言語の発展は難解さとのトレードオフだ。
近年のJavaはC#に振り回されすぎなんじゃないだろうか。

Java8ぐらいで互換性切って仕様を一新したほうがいい

そうだなｍ。もうJavaに未来はないな。SUNも潰れそうだしいっそのこと、勢いのあるAPPLEとかMSに吸収されちゃうべきじゃないか？

糞java.util.loggingをなんとかしろ

>>609
こういうのか？
http://www.nikkeibp.co.jp/archives/044/44150.html

>>612
個人的には、JavaはARMに吸収してもらいたい。
で、AppleからARMベースのフルスペックMacOSXマシンを・・・

VMでコード再利用が出来て、
豊富なライブラリが存在して、
通信、DB、GUIの仕様が決まっていれば、
便利だということを証明したことがJavano最大の功績だった。

なにこの過去に縋った流れ

お復習ですやん

鼻糞君がいるスレはここですか？

＞ C＃とJAVAを比較しても全く意味ない。もともとC#（.Net)がJava/JVMのマネでしょｗ

後から来たのに追い越され 泣くのが嫌なら、さあ歩け。
C# に追い越されてるぞ〜。さっさと歩けよ、Java

.NetでもJavaでも好きなほうで書いていけば問題無い

>>621
ひとりでやるんだったらね。
でもね、大勢で力を合わせて開発するとなつと、
好きな方をえらぶ、ってワケにはいかないんだよ。

このスレには安月給の万年派遣もいるんですか？

>>623
お前だけだと思うよ

>>624
そう泣くなよ。安月給仲間じゃないか。

しかし、なんだな
.NETとJavaは用途が異なるから似たような技術であっても
住み分けるはずだ、と言われていたが
最近はそうでもないんだな

まぁまだJavaの方が強いと思うけど、これから先はわからんね

そうですね。もっとC#はVB化していくのでしょうね。

今のVBは過去を引きずりつつC#に追いすがってる状態でしょ
Javaみたいに

macjavaはもうちょっとなんとかならんもんかね

どの言語使うか決めるのは俺なんだけど

VB化するC#とCOBOL化するJava
どっちがマシなんでしょうかｗｗｗｗｗｗｗｗ

>>630
サンデープログラマですか？

別に好きに選んでる人はいると思うけどな
俺は世間に流されるが！

>>632
サタデープログラマです。

フライディ・チャイナ・タウン歌いましょうか？

bsdもにたようなものだけどmacはsunが作ってないから無理。
それよりも、gnu classpathはどうなっちゃうの。もう終わり？

>>616
LispのVMが出れば最強、そういうことですね？

http://www.atmarkit.co.jp/fdotnet/special/linqtoxml/linqtoxml_01.html
これはいつJavaに入りますか？

LINQ to XMLは確かにすごく使いやすいけど
この標準無視の独自性はMSならでは
さすがにJavaにこういうのは入らないだろうな

>>638
川俣晶か…相変わらずイタい文章書いてるな、この人
＞XMLという技術を襲った最大の災厄とは、「僕の賢さ」を誇示しようとする
＞「精神の子どもたち」の大挙流入にあるといえる。
とか根拠レスで自分の思い込み書いてるだけだし。あと、技術的にも
間違いが多いから、この人の書く技術系記事は基本的に信用できん

その人とは関係ないけどVBの小ネタ記事なんかもっとすごいよ。
MSDNによくあるけど「特集１１号 これは目からうろこ！！VBプログラマ必見！」とかｗ

VBもC#も７年後も同じような言語仕様として存在するかどうか怪しいし、その人も同じ主張で責任を持っていられるかどうかも怪しい。
結局そういうキモイ世界で頑張ってられるようなITドカタが集まった世界、「類友ドカタ」ってことじゃね？ｗ

LINQだけど、ODBMSの標準化界隈では一応こんな話もあるという事で。
http://www.odbms.org/blog/2008/08/linq-is-best-option-for-future-java.html

>>492
苦労じゃ

どうしても言ってみたかったんです。ごめんなさい。。。

>>643
おまえはITドカタ決定！

>>163
JWebPaneﾏﾀﾞｰﾁﾝﾁﾝ

JDK7 build43
http://download.java.net/jdk7/changes/jdk7-b43.html
http://download.java.net/jdk7/binaries/

>>645
これ来たら、俺ブラウザwithJava祭りになると思う。

だよなー
けどずっと更新されないし。7じゃのらんだろうね

Androidは、既にandroid.webkit.WebView by Webkitってのが来てるんだよな。

実物のWebkit使えるから楽なんだろう

>>607GLSファンとしては看過できねー。
「取捨選択せずにすべて取り込む」ってのは例の
「Schemeは全員が納得したものだけ取り込む、CommonLispは誰か一人でも提案したものは取り込む」
というジョークの影響だと思うが、大ウソなので注意な。実際は取捨撰択されまくっとる。

提案されたものは全て取り込むとOn Lispに書いてあったぞ

>>652
Paul Grahamは別にANSI Common Lispの仕様策定に関わってたわけでも
ないだろうし鵜呑みにするのはどうかと。Paul Grahamって割とテキトーな
こと書いてること多いし

CLtLを読んだことがあれば、
取捨選択したことは分かります。
あの仕様書はノート付きですから。

>>649
WebViewとJWebPaneの戦いになるんですかね。

> JAVAは言語仕様の拡張は自然だし安心できる。

32bit文字型にintを使うのだけは勘弁して欲しいかな。
char型を32bitに拡張するなり、wchar型を導入するなり、
してほしかった。

基本型を追加したり変更するというのは、できないな。

なんで？

jdk7 build44
http://download.java.net/jdk7/binaries/
http://www.java.net/download/jdk7/changes/jdk7-b44.html

>>655
まあVMの仕様を変更しないことが優先だよね。
次のVMでは変るかも知れないが。

次のVMなんてでるわけねえだろ

あらゆるところにアノテーション付けまくれば型に別名付けられないこともない

また 「 : 」 が使われるのか・・・困ったときの 「 : 」 頼み、だな。

なんのこと？

>>657
基本型の変更は既存のソースへの影響が大きすぎる。
追加は変数名との衝突が考えられるのと、VMの変更が必要になる可能性がある。

もちろん、基本型の追加は、クラスほか、別の識別子とかぶる可能性もある。

基本型追加にしても char っつーか文字型 32bit にする必要性ってどれほどあるんだ？
サロゲートなくなっても合成文字まで消せるわけでもなし。

どっちかっつーと long が 128bit になるとか、128bit 整数型追加とかの方が現実的だと思うが。

>>664
新しい名前空間に追加すりゃいいじゃない
それが嫌ならdouble charでもいいし

基本型の追加程度でVMの変更が必要になるんなら
いずれ基本型が追加できるVMに変更せざるを得ないだろ

基本型の追加よりもBigDecimal等のために演算子の再定義を
認めた方が喜ばれるのでは。

>>667
ようするにintの別名がほしいだけか

>>666
そもそも必要だから欲しいって話じゃないし。
32bit文字型なんて要らんでしょ。byte[]でUTF-32扱えばいいだけだし。

>>669
128ビットCPUとか256ビットベクトル演算ユニットみたいなものを
普通に使うようになるかも知らんだろ
基本型追加できませんじゃどうしようもないだろ

>>671
必要になったときに追加すりゃいいじゃん。
それまでは DirectByteBuffer で我慢してもらう方向で。

C#なんかバージョンアップするたびにキーワードが増えてるんだよ
人によっては気持ち悪いと感じるかもしれないけどコンテキストキーワードにすれば無問題

>>671
何に怒ってるのか知らんが、まぁ落ち着け。

GPGPUやManyCoreに関してはJavaFXみたいにJavaの言語仕様の
外で利用出来る形(それこそOpenCLのサポートとか)から始まって、
利用形態が固まって汎用的になった部分から徐々にJava本体に
取り込む形になるのでは。

現状の様に使い道や使い方のコンセンサスも固まっていない状態で
言語仕様だけ先走っても良いものは出来ないと思う。

＞ 32bit文字型なんて要らんでしょ。byte[]でUTF-32扱えばいいだけだし。

？

JDK7で入るライブラリとしては、NIO2 と他に何があるんだろうか。

jsr166y

JVMって、charは32bitだよね？
さすがにchar配列はこっそり16bit単位でアロケートしてるんだろうけど。

VM Specification には char は 16bit 符号なし整数と書いてある。
演算時には iadd isub imul idiv で代用したりするけど、
だから char は int なんだとか byte は 32bit だ、とは言わんだろ普通は。

>>680
いい加減、頭壊れてる奴の相手するの止めたら？

boolean型同様、char型式もキャストや演算子に制限を加えておくべきだったな。
==,!=,<,>、あとStringやbyte[]との変換メソッドだけ用意しとけば
大抵のことはこなせたんじゃない？

これならあとでcharが32bit化になろうが、問題は少なかったはず。
VMではbooleanが32bitだ、とかいちいち気にする人いないし。

そこまでやるなら、char型削除で良いんじゃね？

>>682
「文字」に対する認識が甘すぎる。

>>684
キチガイをスルー出来ないおまえの認識の方が甘い

CharacterがNumberを継承してないあたり、
Sunでも当初から「charは数ではない」との認識は
あったんじゃないかな。

まああの時点では、20世紀的Cプログラミング
（'0' + (char)3 したら '3' ができましたとか）
を切り捨てるわけにもいかなかっただろうよ。

いつまでも配列のインデックスが32bitなのはどうなのよ？
ByteBufferのオフセットも32bitだからメモリマップとファイルでも2GBしか
アクセスできなくね？

EJB使うと、C/Sプログラムが好きなフォームで作れるからいいよね。

MSは今のところ、ASP.NETしかないからな〜。ブラウザ仕様しかつくれない。

そーいえば一時期、開発中の NIO2 で
long 使える java.nio.ByteBuffer が置いてあったけど
いつのまにかに削除されてるなぁ。

NIOのメモリマップドファイルは 64bit対応以前に
close() する手段がないって時点で使い物にならん。

そんなにでかいファイルは普通にGC候補じゃないの？

Javaの現行の仕様じゃ、RADに対応しきれない。
その点ではC#に分がある。
しかし、C#のポインタはいらないと思うな。
それはC言語でやればいい。

>>691
>Javaの現行の仕様じゃ、RADに対応しきれない。

どのあたりが？

ここは釣り掘かよ

http://www.atmarkit.co.jp/news/200901/29/mono.html

それでC#狂さんは、どのあたりに不満があるんですか？
C#に不満があるからこのスレに居座ってるんでしょｗ

>>692
プロパティがないあたり

プロパティがないのは致命的だよな。
コンポーネント指向にできない

>>697
コンポーネント指向(笑)
プロパティが無いのは面倒だけど、致命的というほどではないだろ。

>>696
RAD用のプロパティ仕様は最初からあっただろ

http://www.atmarkit.co.jp/fcoding/articles/python3/01/python301a.html

７０１

アクセッサメソッドの為の専用の構文がないだけで、
JavaBeans仕様に乗っ取るなら、IDEが補完するから気にしない。

配列プロパティがないのはどうかと思ってる

>>703
インデックス付きプロパティがあるから無問題

>>704
あったっけ？

>>700
なにが言いたい？

Python見習ってJavaも後方互換性捨てろって話では？
本人じゃないから外してるかも知れんけど

>>705
JavaBeans仕様の「7.2 Indexed properties」に書いてある
ケチ付ける前に仕様に目を通すくらいしろよ

おまえみたくヒマ人じゃないんで

>>707
それは無理だな
そんあことしたらJavaが捨てられてしまう

Pythonのポリシーが同じことの書き方を2とおり用意しない、ということなら、Javaのポリシーは後方互換だからな。

>>708
見てなかった。ありがとー

Java SE 6 Update12 release.

java.util.Dateの地獄のようなメソッドリストラ、いい加減に何とかして欲しい。

>>709
昼間っから2chやってるヒマ人のセリフかよw

>>714
javax.time の地獄のようなクラス群も何とかして欲しい。

地獄というほどでもないと思うがDateとCalendarの置き換えにしては大げさすぎだよな。

javax.timeいらんくね？

>>707
互換性がないなら、そもそもJavaである必要はないと思うんだけどな。
Scalaでいいじゃん、というか。(ScalaのEclipse Pluginはだめだめだけど)

次世代 Javaである
Java3 の出番だな。

そのまえに Java 2+とJava turboR も出しておこうか

自然画モードとPCMを取り入れるんですね。
わかります。

書き換えられるなら、高速モードで動かせるのか。

そういやさ、jdk7のビルドは淡々と進んでるけど
jdk6u10の成果ってマージされないじゃない？NimbusとかPluginとかの。

jdk7ではいつ取り込むんだろ？
ちょっと迷走しすぎじゃないかな・・・・jdk7

nio2とかjsr308とかも独自だし、いつ統合されんだろな？

jdk7 build46
http://download.java.net/jdk7/binaries/
http://www.java.net/download/jdk7/changes/jdk7-b46.html

typoとかの細かい修正がメイン

最近聞かなくなったけどクロージャはどうなったの？
jdk1.6の途中でjavafxスクリプト追加みたいな感じにクロージャも追加になるのかな。

C++もそうなんだけど、次の仕様のリファレンス実装をコーディングしていた
最重要人物がMS系の仕事しちゃってるんですよ。
ピンポイントで狙ってるんだと思う。

>>726
Devoxxの発表でクロージャ漏れた。>>258あたり

クロージャ便利なんだけどなぁ
クロージャを使うにはジャバだと少しトリック使わないといけないし、そろそろ導入して欲しい。

>>728
それって完全に決定事項なの？

>>730
JCPのページ見てもJava SE 7 Release Contentsみたいな
JSRが見当たらないから、完全に決定事項ってわけじゃなさそうだけど
とりあえず最新の公式発表って感じかなぁ？ 望み薄なのは確か。

だよなぁ。
つまんないなー

JavaSE 6 update14 early access
http://blogs.sun.com/SDNProgramNews/entry/java_se_6u14_early_access

6u10 の 次は、u14が熱いらしいぜ。
GCに手が入っている、期待しよう。

ってか、7はどうなってんの？

7は来年だ

ﾅ　ﾅﾝﾀﾞｯﾃｰ!!
　Ω ΩΩ

>>734

2010年とか書いてあるね
ttp://journal.mycom.co.jp/column/jsr/060/index.html

jdk7 build47
http://download.java.net/jdk7/binaries/
http://www.java.net/download/jdk7/changes/jdk7-b47.html

7の言語仕様ってもう固まったの？
固まってないのにビルドが進んでも全然使う気になれないんだけど

お前はここに来る必要すらない

言語は変わらんでしょ

>>738
固まってない。

jsr308 とか module は統合されるまで時間かかりそうだし
small language change は具体的に何やるのかも良くわからん。
multi catch と null handling と type inference は入りそうだけど、
string switch とかはどーなんだろ？

次のリリースはクロージャをキャンセルした代わりにアノテーションだらけになりそうだね。
あとは、nio2とswing frameworkかな。

javafxは使いたけどcpu 2Gが最低必要だからちょっと敷居が高いな。
flashでもそんなにハードリソース必要なのか？
javax.mediaのライブラリに力を入れないで、なんでjavafxのようなメディア操作用API (script language)の方に力を入れるのか良く分からん。

>>742
>javafxは使いたけどcpu 2Gが最低必要

この情報ってどこに書いてありますか

javafxダウンロードのsystem requiredのところ。もしかしたらcpu 1.8Gだったかも。

>>738
Java 7の変化は言語仕様だけじゃないぞ

>>744
ドモデス
Adobe Flexの方もみてみました。JavaFXのほうがRequirementsはやや高め？

NetBeans IDE 6.5 for JavaFX 1.1 Requirements
Microsoft Windows:
* Processors: Intel Pentium 4, Intel Centrino, Intel Xeon, or Intel Core Duo (or compatible) 1.8 GHz minimum (2.6 GHz Intel Pentium IV or equivalent recommended)
* Operating systems: Microsoft Windows XP with Service Pack 3 or Windows Vista Home Premium, Business, Ultimate, or Enterprise (certified for 32-bit editions)
* Memory: 512 MB of RAM (1 GB recommended)
* Disk space: 778 MB of free disk space (1 GB recommended)
* Web Browsers: Internet Explorer 6 minimum, FireFox 2.0 minimum
* Java SE Development Kit (JDK): JDK 6 Update 7 minimum (JDK 6 Update 12 recommended)
The JDK installation includes the Java Runtime Environment (JRE).
* Apple QuickTime Player: 7.5.5 minimum is required to run the JavaFX Mobile Emulator, which is currently available only on the Microsoft Windows platform. System restart is required after QuickTime installation.

FLEX BUILDER 3 FOR WINDOWS (STANDARD AND PROFESSIONAL)
* Intel Pentium 4 processor
* Microsoft Windows XP with Service Pack 2 or Windows Vista Home (Premium or Basic), Business, or Ultimate
* 1GB of RAM (2GB recommended)
* 500MB of available hard-disk space (additional 500MB required for plug-in configuration)
* Java Virtual Machine: Sun JRE 1.4.2, Sun JRE 1.5 (included), IBM JRE 1.5, or Sun JRE 1.6
* Eclipse 3.2.2, 3.3 and 3.4 for plug-in configuration (Eclipse 3.3 recommended for Windows Vista)
* Adobe Flash Player 9 software

>>742
swing の変更ってどこみりゃわかる？

>>746
NetBeans vs Eclipseみたいなもんだな

JavaFXがCPU2G要るって話じゃないのか。
単に開発環境のNetBeansがCPU2G必要って話か。
NetBeansなら、CPUは1Gでもいいが、メモリは2Gくらいあったほうがいいな。

javaFX SDKのjavafxcコンパイラで遊ぶだけならしょぼいPCでも大丈夫。
JDKさえ動けばとりあえず可。

たしかデモであったけど、スクリプトの変更がリアルタイムで確認できる奴は俺の持ってるCPU 1.4Gでは重すぎで全く実用にならない。
だからIDEというよりも、リアルタイム（コードとポトペタとの同期）にパワーがいるんじゃないかと思う。
デモの動きにストレスあったからたぶんjavafxを使うことはないだろうと思う。
これだとネットブック(1G程度）で現場で手早く開発というわけにはいかないなから、javafxはスクリプト感じはしない。

JavaFXは携帯がメインターゲットやろうな

swing frameworkだけど、java one の2006/2007年資料とか。java.netかな。
アプレットのinit(); start();みたく、 class Application initialize(); lanch()をオーバライドしていく感じで作られてる。
他にはリソース・バンドル・ファイル（GUI設定ファイル） file.propertiesと連携して、コンパイル時の静的にguiのフィールドを決定していくモデル。
だからjavafxは動的（リアルタイム）にフィールド変更だけど、java (swing)ではアプレットのモデルと同じ要領でアプリをつくっていって、各プロパティはリソースで解決するみたい。

javafxは携帯向けといわれてるけど、実際は3DとかTVとかコーディックも充実してるからSUNはデスクトップ（というかアプレットに組み込んでブラウジング）の方を狙ってんるんじゃないかな。
たとえばサンプルでも合ったけど時計とかのガジェットをデスクトップに持ってくるのとか。
グーグルも似たものをやってるけど、グーグルはアプリは作れるけど言語や構築のフレームワーク(airとかjavafx)をもってないからあくまでもWeb向けの企業なのかなと思う。

3Dとかビデオコーデック持ってると携帯向けと言えないとか、
googleはフレームワーク持ってないとか、
何なんですか、一体！

グーグル（アンドロイド）は携帯向けの組み込み向けみたいなフレームワークで、swing/javafxの視点で見みるとjavafxのようなコンテンツ作成を押し出したものとはあまり関係ない。
そのほかは、日本の３流ライターがいたようなIT情報サイトじゃなくて、ちゃんと英語の情報ソースを読んでよ。
NTT研究所ｗとかたいそうな肩書きなところも含めて、３流ライターが書く記事は素人のブログとドッコイで本人の夢や理想だらけで嘘・噂で語ってることが多いからね。どこかから金もらって書いてるって聞いたらたちまち信用しなくなるんじゃないの？

なんだその三流ライターみたいな論調はw

自分戦略研究所とか言うIT向け情報サイトもあるけど、ただの馬鹿サイトだろ。
R２５とか週間アスキーと同じで３流以下ｗ
週間アスキーなんかゴシップに近いけど、信用する奴いるの？ｗ

何と戦ってるんだお前は

>>759
お前は誰だ？
住所氏名を書いてみろよ

>>760
お前は誰だ？
住所氏名を書いてみろよ

それ、一生やってもつまんないから

>>761
三流ライター アルゴ君です

>>754
Pythonは言語じゃありませんか、そうですか。

>>756 が本人の夢や理想だらけで嘘・噂で語ってるようにしか見えないのは気のせいか

パイソンを言語だと考えるのはひょっとしたら夢じゃないのか？

アルゴ！アルゴ！

リズムにのって！

JavaFXの存在だけは理解できん
あれはなんのためにあるんだ？
Swingじゃダメなのか？

宣言的にUI部を書きたいって事らしいんだけど、
買い物だから、あまり親和性がないね。
rhinoもあんまり活躍してないし。この辺りは迷走気味だと思う。

XMLじゃなくてスクリプト言語にした意味がわからん
どうせデザイナに自動生成させるんだろ
人間が書くものじゃない
まだXMLならツール作りやすいとかメリットはあるだろうけど

>>769
Swingアプリはつくったことないんですが、WPFやAdobe AIRみたいなリッチアプリは、つくれるでしょうか？

>>771
Adobe Flex, WPFとアプリを作ってみたけど、mxmlやxamlは直に読むには少しうざったい感じがしたです。
JavaFX Scriptは、あえてxmlを選ばなかったみたいだけど、実際コードをみてみたり簡単なアプリ書いてみると、意外と直感的で、これもアリかという気もする。

あ、771氏へのレスになってないけど、デザイナに自動生成する（こともあるだろうけど）、そうとも限らんのではないかと

>>772
Swingもしらんのに良くこのスレに書き込むなw

>>774
Swingの専門のスレでしたか、それは失礼

JavaFXの批判とかそういことは、JavaFXを一通り勉強してから言うもんじゃないの？
妄想炸裂したいんなら別に構わないけどｗ

>>772
今Swing学習中なんだが、もんのすごいプリミティブ。Webアプリのある意味
ぬるい世界にいたんだが、組み立てればおっけーだけど組み立てることしか
できない世界から、凝ったことしようと思えば大抵のことはできるけど
その分細かいとこまで作り込まないといけない世界に来て呆然としてる:-)

ちなみにSwingアプリの代表例は、NetBeans, JUDE, FreeMindあたり。

あと、Swingについては専門スレがある。
http://pc11.2ch.net/test/read.cgi/tech/1227234261/
スレタイに「低速」と付いてはいるが、最近じゃDirectX/OpenGLでレンダ
リングしていてかなり高速になっているらしい。

Webアプリのある意味ぬるい世界とは具体的にどういうの？

>>778
HTML/HTTPによって基本的な仕組みがある程度単純化/パターン化されていて、
比較的少ないコード量で実用的なプログラムを書き易い点と、
規模が大きくなっても基本的な構造自体はあまり変わらない点。
Ajaxとかが入ってくるとややこしくなってくるけど。

>>777
Swingアプリを作るのは、そんなに容易でないという感触（実際、そういうIT記事もみかける）だったので、自分は敬遠していたけ。
でも、NetBeans使えばある程度簡単にSwingアプリ作られそうだし、ちょっと勉強したくなってきた。

一方、JavaFXでアプリ構築の容易さはあがったんじゃないかと思う。
ただ、まだ公開されたばかりで、足りないと思われる部分も沢山あるようには、思う。
(グラフィカルにJFXアプリを構築できるツールがないとか限られたSwingコンポーネントしか使えないとか)

どっちにしても、Swingを批判するつもりは全くなくって、むしろもっとがんばって欲しい。（もちろん、リッチGUIなアプリが構築できるJavaFXも）
NetBeansとかV2Cとか、「意外と」さくさく動いて心地よい。もっと、評価されていいような気がするなぁ。

で、それが次世代Javaの動向とどういう関係が？

>>781
ｽﾏﾝ、ちょっと話題がそれた

javafxスレがないからだろ。スレはお前がたてろ。

>>782
日記に書いてろ

JavaFXスレは確かに欲しいな 誰かお願い。

おまえがかけ

>>785
イラネ

で、新式のGCは速いのかね？

>>788
その「速い」って言う定義をまず聞こうか

「速い」に定義が必要なのか？速いは速いだろ。四次元の世界なら話は別だが。

まだ参照が残ってるのにGCされちまった。めちゃはやすぎ。

４次元ＧＣです

あなたって早いのね

>>790
じゃあ速いよ

>>790
レイテンシとスループットがどうたらこうたら

遅いよりいいだろ

>>795
GCにレイテンシとスループットは関係ないだろ。恥かかないようにGCの仕組みをちゃんと勉強してから発言したほうがよかったね。

>>788
それでは、百式のGCの威力を聞こうか

>>797
似たような概念(最大停止時間と効率)ならあるだろ。それくらい読み替えてやれよ。

いや、それ以前に普通にGCの性能評価に関する用語でスループットとかレイテンシて
使われるだろ。スループットは、GC全体にかかる時間、レイテンシは１回のGCの停止時間
に関する指標ね。

>>800
> スループットは、GC全体にかかる時間

おいおいw

＞スループットは、GC全体にかかる時間、レイテンシは１回のGCの停止時間 に関する指標ね。

そうなの？
それならソース出してよ

>>802
ttp://www.research.ibm.com/ismm04/slides/detlefs.pdf

G1-GCは
　Garbage-First: Low Latency, High Throughput Garbage Collection
だそうだよ。ソースはIBM。

Throughputってのはこなす量であってかかる時間じゃない。
>>800の語彙力に絶望。

まあ一連の無駄な流れを作った>>794は真っ先にGCされるべき存在だな。

すまん、>>794じゃなくて>>797

>>805-806

これら ２つ のレスは新式のGCが起動して既に再利用されています。

>>797
似たような概念(最大停止時間と効率)ならあるだろ。それくらい読み替えてやれよ。

>>805
人のせいにしちゃいかんよ。恥ずかしさを隠し切れずにアンカーをつけ間違えてるしねぇ

>>804
こなす量ってのは、GC全体にかかる時間に関するよね？

> スループットは、GC全体にかかる時間、
は間違い。以上。

いや、それ以前に普通にGCの性能評価に関する用語でスループットとかレイテンシて
使われるだろ。スループットは、GC全体にかかる時間、レイテンシは１回のGCの停止時間
に関する指標ね。

>>811
ちなみに正解は？

>>804
いや、GCのスループットが上がる＝GCの総停止時間(アプリケーション全体を通しての停止時間の和)
が減る、だから間違ってないよ。ぐぐってGC関係の論文やGC研究者での用語の使われ方でも調べてみたら？
あと、スループット＝GCの総停止時間(これなら確かに間違いだ)と言ったわけではなく、GCの総停止時間
に関する指標と言ったわけで、その辺勘違いしないでくれ。

補足すると、
＞スループットは、GC全体にかかる時間、レイテンシは１回のGCの停止時間
＞に関する指標ね。
の「に関する指標ね」はＧＣ全体にかかる時間、１回のＧＣの停止時間の両方にかかってるってこと。
書き方がまずかったのは認めるが。

ちょっと訂正
>>814は
誤
＞いや、GCのスループットが上がる＝GCの総停止時間(アプリケーション全体を通しての停止時間の和)
＞が減る
正
＞いや、GCのスループットが上がる＝GCによって消費される時間(アプリケーション全体を通してGCによって
＞消費される時間。ライトバリアなどのGCによるオーバーヘッドを含む)が減る
で。GCに付随した処理のオーバーヘッドを失念していた。

GCを語るスレはここですか？

というより馬鹿な人が無知を晒すスレのような気もする

>>818
それであなたはどれぐらい馬鹿なんですか？

>>797と同じくらいかな

>>820
レイテンシだもんねぇ

どうやら俺の出番のようだな。

このスレが荒れるとき、必ずアルゴ君がかかわってるわけだ。

盛り上がっているけど次世代の話じゃないね

jdk7 build48
http://download.java.net/jdk7/binaries/
http://www.java.net/download/jdk7/changes/jdk7-b48.html

AWT関連のバグ取りが多い。

>>823
アルゴ君乙

jdk7 build49
http://download.java.net/jdk7/binaries/
http://www.java.net/download/jdk7/changes/jdk7-b49.html

JIT、GC関連のバグ取り

>>803
GCに対する新しい改善が入ったの？？
それって、昔、みたGC Firstのことかな？

そんときみたドキュメントだと積極的にGCを行うことで
実行のつっかかりをなくすというものだったと思う。
で、トータルのGC時間は微妙に延びるというある意味当たり前な話だった。

それはともかく、jdk7のスペックはいつ固まるの？

jdk7 build50
http://download.java.net/jdk7/binaries/
http://download.java.net/jdk7/changes/jdk7-b50.html

NIO2が統合。

JavaのGUIといえばSwingだと思うんだけど、
FXのおかげでこれから廃れていく傾向にあるの？
それとも住み分け？

>>830
仮に住み分けだとすると、どういったところを分けることになる？

>>831
いや、ぜんぜん分からないんだけどさ、Javaの勉強を始めたわけさ。
したらGUIが弱いって言うじゃない？
でもまあ、Swingの勉強するかと思ってたのね。
そしたらJavaFXが次世代のGUI！みたいな記事をネットでみたから、
Swingの勉強しないで情報少ないけどJavaFXをがんばったほうがいいのか？
と思ってきいてみたのよ。これから勉強するのにいきなり時代遅れじゃちょっと。

JavaFXはSwingベース

>>833
あー、JavaFXの簡単な文法でSwingのクラスを呼ぶのか！
Swing頑張る(｀･ω･´)

>>832
自分もAdobeのFlex、MSのWPFをやったあとJavaでGUIをやってみようかと思ったけど、Swingにちょっとしり込み。
うーん、とりあえず両方勉強しておけば間違いないのかなぁ。
自分はJavaFXから勉強してま。

す。

jdk7 build51
http://download.java.net/jdk7/binaries/
http://download.java.net/jdk7/changes/jdk7-b51.html

G1GC関連のbugfix等

jdk7のコントロールパネルが縦にビヨーンって長いのって・・・・俺・・・・・・だけ？

結構前からなんだけど、直る気配がないから俺だけなのかな、って・・・・

jdk7 build52
http://download.java.net/jdk7/binaries/
http://download.java.net/jdk7/changes/jdk7-b52.html

なんもなし？

http://journal.mycom.co.jp/news/2009/04/02/030/

>>840
それは、Sunだけが悪いんじゃなく、疑心暗鬼にさせたMSにも責任あり。
Sunは、Javaの互換性に腐心している。
Harmonyって、OpenJDKと比べて何が違うのかな？

それはそうと、Java7は俺も今のままじゃ要らない。
仕様決めがｇｄｇｄ過ぎる。船頭多くして船山に登る状態。

>>841
えーと。

Sun が、JCK へのアクセスを制限してる、って話が主眼だと思うのだが。
JCK へのアクセス制限は、Java の処理系を本気で実装しようとしてる者たちを
この 10 年以上苛立たせてきた問題。

JCK は、むしろ「Java の互換性を保って」実装するためには必須なもの。

JCK へのアクセス制限が、例の MS の「Java に塩を混ぜたれ」戦略と、
どうつながるのかわからんのだが、説明してもらえる？

あ、俺は Sun の商売上のぎりぎりの戦略なんだろうなとは思ってる。
正しいか間違ってるか、なんて、結果が出たあとでもわからんな、とも。

>>843
んーっと、
>この条項があるために互換試験キットを使ったソースコードに同条項を追加する必要があり、
>この条項はOSSライセンスとは相容れない内容になっているため

って、ちゃんと互換性を保ってますよって制約になってると思うんだ。
JCK通したのが、どの状態のものか作る側に制約を掛けている訳で
JCK通した後、JCK通らないように改変したら作成者側に責任がでる、と。
なもんで、MSとの争いで、こんなことするようになったのかなぁ、と思った。
事情はよくしらんので、MSJVM問題前からこれがあったんだったら、すんません勘違い。

> JCK通した後、JCK通らないように改変したら作成者側に責任がでる、と。
記事内の「使用分野制限条項」ってのがそうなんか？

>>842>>844
お前等想像じゃなくてちゃんと理解して書けよ。
'Field of Use' clause (FOU)
はSunが非公開にしているから、詳細なことは分からないが、
基本的なことはいろいろな人が解説している。
>>845
FOUはそういうものではない。「利用領域」を制限しているだけなので。

ああ、原子力発電所で使うなとか、人命に関わる部分で使うな、とか？
(でも火星では使っていい・・・とか)

Sunはオープンソースをあまり上手く活用できてないな。
エンドユーザには好感を持って貰えるようになったが、
OSS業界人には反感を買うようになった印象がある。
証券コードをJAVAにしたりとかね。

法務部の考えがIPを守る方向なんだろうな。

来週から Sun JDK じゃなく、IBM JDK になるが、何か変わるかな。

LotusやRationalのようにSunブランドが残る可能性はないだろうか？

ていうか、IBM て自前で JDK の別実装持ってなかったっけ？
OpenJDK でマージされたんだっけ？

まだやっとるわい。マージするわけねえ
http://www.ibm.com/developerworks/java/jdk/aix/service.html

Linuxはこっちね。
http://www.ibm.com/developerworks/java/jdk/linux/download.html
http://www.ibm.com/developerworks/java/jdk/
z/OS(w
http://www-1.ibm.com/servers/eserver/zseries/software/java/
Windows版はlevonoへ。
http://www-307.ibm.com/pc/support/site.wss/document.do?sitestyle=lenovo&lndocid=MIGR-56888

IBMになったとたん、OpenJDKのライセンスがCPLになったりしてｗ

>>855
OpenJDKそのものが中止になりそうだな

もうちょっとマシな事をいえないのかねぇ

J 冗
D 談
K か！

つまんねー

>>851
Sun Bladeみたいな感じで残るんだろうね。
Microsystemsは消えるか。

jdk7 build53
http://download.java.net/jdk7/binaries/
http://download.java.net/jdk7/changes/jdk7-b53.html

Summary of changes の書式が変わった。
G1GCのバグ取り進行中。

>>852
少なくともJavaVMはSunとIBMで別実装。
SunとIBMのえろいひとが同じ職場でJDKを作成するとどれだけのものができるか期待している。

>>862
あのIBMがそんな無駄を放置するかな？
余剰人員として半分がリストラされるだけじゃね？

>>863
人員はともかく、IBMの特許技術をSunJVMに組み込めるなら期待できそうだな。

>>863 一時期、異なるVM実装のプロジェクトを商用で3つ、研究用であと2つ抱えてたIBMだからな。

http://wassr.jp/user/androdizaurus/statuses/4P7PEDXnsV

組み込み用の実装とか、jdk
もう M$ で 作っちゃえそうな mjk
そんな気だるい午後の昼下がりYO

一番稼いでるJDKはBEAのJDKだろうな

単体だとそうなのかな
IBM JDKもWASにバンドルされてるからその利益の一部をカウントしたら
引けをとらないと思うが

SunはOracleに買われた方がよかったんじゃね？

G1GCはユーザにstop-the-worldを気づかせないくらいにはリアルタイムなGCなのかな？
フルGCを含めない場合の処理性能は、従来型の方が良さそうな気がするが大丈夫かな。

>>869
Oracleにしてみればハードウェア部門が余計なんじゃない?

ｇｄｇｄぶりに嫌気が差して一年ほど追ってなかったけど
まだｇｄｇｄやってるみたいね。

>>871
ハードウェアを持ってフルスタックになったらいいんじゃね？

日立も自前JREで、GCストップを軽減とか言ってたな

>>873
ないない。
ソフトウェアに特化してるからこその暴利なんだよ。
>>874
国産と言うだけで、凄く小手先対応っぽい気がする・・・

自前っつっても基本はライセンス受けて貰ったコードをちょっと変更して
コンパイルしただけでしょ。特に Win で完全に自前な JavaVM って
Netscape に乗ってた Symantec とか MS JVM とか、JDK1.0〜1.1 頃まで
さかのぼらないとないような。

>>875
ありえん話じゃないだろう。Oracle専用ハードは昔からいくつか話が出てるし。
今ならHPと組んだHP Oracle Database Machine、一昔前はSunと組んだRawIronとか。

Teradataみたいにならないよう気をつけさえすれば。

>>877
Exadataって名前がTeradataに似てて不吉だなw

java 7は、とりあえずこのまま出してしまうのか、
プロジェクト刷新してやりなおしなのか。

7は欠番にして、8で仕切り直しがいいな。
互換性を犠牲にして、新しい言語にしてもいい。

そして、日付はlongで・・・・

互換性犠牲にして新しい言語なら、Scalaでいいんじゃない？

>>881
同感。Java言語に機能追加していくくらいならもう別言語でやってくれと思う．
多言語向けにJVMに機能追加していくのはありだと思うが．

CLI みたいになってくのかなー

>>882
同感
Java言語で物足りない人はGroovyみたいなのを作ればいい

いらない人は1.4使いつづければいいじゃん
そもそもこのスレに来る必要すらない

しかしJavaって5.0からC#の後追いで
ロクな機能ないね。

6.0でC#2.5ぐらいのレベルだから7.0がでてもC#4との差は歴然でしょ
.NET/Mono が言語的には箱庭としては攻守最強だろう。

> 言語的には箱庭としては攻守最強

>>885
Java言語自体に機能追加するのがいらないという話でJVMの改善は
まだまだやるべきだしやライブラリやフレームワークの整備が
不要だといってる訳じゃない。そこはちゃんと区別して考えてくれ。

>>886
言語的には今のJavaより良いのが使いたい人たちは
Scala試してみたり色々やってるよ。Scalaなら言語仕様的にはC#(3.0)よりも
強力と言ってもいいし。

ちなみに、5.0からC#の後追いってのは部分的にしか正しく無い。
Genericsが入ったのはJavaの方が先だし、Javaのtypesafe enumは
C#のenumよりはるかに強力だし。Genericsの機能そのものに関しては、
variance以外に関してはC#の方が強力だとは思うけども。

.NET/Mono が言語的には箱庭としては攻守最強だからに決まってんじゅあん。バカかおまえ？ｗ

おまえがな

Javaのenumはenumというよりも機能制限クラスって感じで気持ち悪い

俺は enum が出来るまではよく手作業で同じような定数クラス (private コンストラクタ
+ public static final ないくつかのインスタンス) を作っていたから、switch や
== が保証されて toString(), valueOf() が暗黙的に付いたのはありがたかったよ。

実際enumに抽象メソッド書いたりしてるような奴いるの?

書くでしょ。

いるよん。

後で誰かが勝手に増やしたりしないからenumなんであって
それならswitchでいい気がするんだけど

ぬほんごでおｋ

>>898
switch自体いらないよな。男ならifでいいだろ

ifだとfall throughできないからswitchの完全な置き換えにはならん。

>>898
値を割り振る必要がないからenumだろ。
後で誰かが増やすとか減らすとか、関係ないだろ。

>>884
GroovyはRubyユーザーにも評判いいね。
JRubyなんてのもあるがGrailsというGroovyベースのRuby on Railsもどきが素晴らしい。

>>901
switchはsyntax sugarとして欲しいが、fall throughは要らんなぁ。
つか、あれは害悪だ。
caseに条件を複数列挙できればそれで十分。

caseに条件を複数列挙できないから、fall throughが要るんじゃないのか？

case 1: case 2: case 3: hoge123(); break; //caseの中身を書かなければフォールスルー可
//case 4: hoge4(); コンパイルエラー
case 4: hoge4() goto case 5; //明示的に行き先を指定すればおｋ
case 5: break;
C#はこういうとっても意図的な仕様

警告とSuppressWarnings("fallthrough")で goto case以外はある程度代用可能

>>904
例えば for (int i = 0; i < loopCount; i++) hoge(); で loopCount が4以下と分かってる場合に
switch (loopCount) { case 4: hoge(); case 3: hoge(); case 2: hoge(); case 1: hoge(); case 0: }
みたいに高速化のためにループの展開したりする事もあるから、
caseに条件列挙さえできれば fallthrough 要らんとまではいえない。

そーいや project coin に caseに条件列挙できるようにする提案もあったな。
http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000213.html

>>908
ほんとに高速化すんの？それで。
あと、用途がそれなら、fallthrough不要でいい。

>>908
それ、fall throughがあったら元のループと違う挙動なんだが・・・・

つ Duff's device

スマンもう少し書く。loopCountがhoge()により不変であるという条件がいるという話。
fall throughでは、hoge()後に条件判定が入らないから。

ただ、高速化のためだけだったら別の手段があるから無くしてもいいと思う。
switch (loopCount) {
case 4: hoge();hoge();hoge();hoge();
case 3: hoge();hoge();hoge();
case 2: hoge();hoge();
case 1: hoge();
case 0: }
GoTo的な使い方が欲しいなら、別の構文があった方がいいと思うんだわ。

if と while 以外は利便性で導入されてるものだろ。今時うまいこと switch のジャンプ
テーブル使っても炊飯ジャー用のマイコン向けでもなければ意味はない。

>>912
> 高速化のためだけだったら別の手段がある
たとえば？

その下のやつはダメだろ。
量増えたら読めたもんじゃないし、コード肥大化のせいで低速化する可能性あるし。

そもそも break がないから挙動違うしな

>>913
この辺の最適化は低レベルインストラクションを持つ
VMインタプリタでは必須です。
まだまだ論文が書かれているような状況です。

>>914
その最適化のためなんだから、気にするほどのこたぁない。
増えるのはコードサイズだけでしょ。hotspotが効くまでずれこみがあるだろうが。
それに、こんな細かいチューニングがマイクロベンチならともかく実アプリで効くと思うか？
>>908 がGoogleのバックエンド書いてるとかならスマン。効くと思う。そのスケールの処理なら。

でも、Javaを使っている層全体ではswitchの誤用の害の方が多いと思うなぁ。
大抵の用途では、break;を書かなきゃ駄目で、それを書くことは冗長とも言えるし。

>>917
例えば >>908 だとJITコンパイラによって hoge() がインライン展開されるが
>>912 だとインライン展開すると展開後のコードがでかすぎてインライン展開を断念する可能性がある。
>>908 と >>912 は等価とはいえない。

気にするほどの事がないってんなら、そもそも forループでいいわけで。

>>917
> Javaを使っている層全体ではswitchの誤用の害の方が多い
JavaがC言語ライクなプログラミング言語だって視点でみると
breakなしにするとコード読むときにミスの元になるぞ。

C#もD言語もfallthroughしない場合はbreak書かせるでしょ。

>>918
俺はforでいいと思うよ。その方がコード短いし。
>>919
やっぱ、switchの挙動を変えるのは問題ありか・・・
んじゃ、fall-through無しのオプションを指定できるようにする・・・とか。
それじゃ間違う連中はその指定の方を忘れるよな・・・・

俺・・・始めにC言語設計した奴の問題だと思うわ・・・
アセンブラからあがってきたらbreakを書くことに疑問はないと思うけど
構造化プログラミングから入った奴とかは、面倒だなって思ってると思う。
そもそも、"switch"って単語が「処理を選ぶ」という意味だと思わせるのがよくないと思う。
Pascalのcase文やVBのSelect文と同じ挙動をするのがあればいいんじゃないか？

そろそろウザイ

「Javaがこんな言語だったら」という仮定の話は、そろそろ終わろうぜ。
すでに書かれているコードの挙動が変わるような仕様変更はありえないんだし。

Genericsが型情報を持たないのは失敗だったな。
T.class.newInstance() とか書けたら幅が広がったろうに。

1.4のバイトコードと互換、と言った時点で終わってた。

あれは Collection みたいな汎用コンテナ型クラスを作るためのものだと割り切っている。

割り切るも何も、多相型のための仕組みとしては十分でしょ。
メタプログラミングのための仕組みとごっちゃにするから話がややこしくなるだけで。

不十分。だからこそ、Google Collectionsとか出されてしまう訳で。

ジェネリック型の配列作れないのがめんどい。

>>927
Google Collections って、genericsが不十分だからできたっつーより
java.util の Collection API が貧弱なのが原因なのでは？

>>927
よく考えてみろよ。
Genericsでいえば、サンがやっているのはコレクション・フレームワークを作ることじゃなくて言語仕様を定めることだったんじゃないのか？
その仕様に基づいてグーグルはコレクションを作ったわけでいわば「後出しじゃんけん」だし、サンに文句をいうのはお門違いだろうな。

>>929
もちろんその意味合いもあるけど、>>923が書いているようなのも入ってる。
言語レベルのサポートがないから、あんまりきれいな構文にはならないけど。

>>930
サンはどうか知らないけど、後出しじゃんけんならJCPの方がうまいよ。

>>931
入ってたっけ？ クラス名教えて

だから、「多相型としては」十分と書いたんだがなあ。T.class.newInstance()
がしたいってのはどちらかというとメタプログラミングに関する要求であって、
「型システムに関する拡張としては」Java Genericsは十分な能力を持ってると思うよ。

>>932
俺の記憶違いだった。すまん。

Google Collectionsのは任意の型のnew（T.class.newInstance）じゃなくて、コレクション限定のやつ。
Map<String, List<String>> mapOfLists = Maps.newHashMap();

ttp://codezine.jp/article/detail/2397?p=2

>>933
CLR(C#のVM)は型情報を実行時に利用してるし、
Scala見たくJVMを利用する言語は
バイトコードに実行時に型情報がないせいでオーバーヘッドを生じてる。

訂正。

> バイトコードに実行時に型情報がないせいでオーバーヘッドを生じてる。
は
> バイトコードに型情報がないせいで実行時にオーバーヘッドを生じてる。
です。

何暑くなってんだ俺。冷却期間取るよ。

>>934
そんなのユーティリティレベルの話じゃないか…
それが実現できるのはJavaのGenericsに(十分とはいえないまでも)
型推論の機構があるからで、それを活用してないjava.utilのCollection APIに
文句言うならともかくGenericsに文句言うのは100年早いな

そもそもGoogle Collectionで満足なら、
言語仕様にも満足しているはずだ。

こういうの作ればいいだけの話なんだよな
http://s2container.seasar.org/2.4/s2-tiger/ja/apidocs/org/seasar/framework/util/tiger/CollectionsUtil.html

サンのCollectionはGenericsより前に使ったものだからグーグルの後出しじゃんけんと比べられる代物じゃないよなあ。
グーグルはすごい会社だって言う三流ITライターの戯言に君はまんまと乗せられちゃってるんじゃないの？

Javaの機能＝必要な機能、みたいな人が多いのに驚いた。
それ以外の人はもう他の言語に移ったのか。

Java Collection Frameworkは出てきたときから古くさかった
その前からJGLがすでにあったわけだから

>>935,936
それはもちろん知ってるよ。言いたかったのはオーバーヘッドの話ではなく、
型システムの話。もちろん、Java Genericsはerasureで実装されてるせいで
オーバーロードに制限あったりとか、型システムに関係する部分にも一部制限
かかってるけど、その辺はまあ我慢できるレベルだと思ってる。

一応、Javaでも↓みたいにすれば型を持たせられることは知られてるけどね。
ファクトリメソッド至上主義みたいなのがJavaの中にある気がする。

MyMap<String, Integer> map = MyCollections.newHashMap(String.class, Integer.class);

private static <K, V> MyMap<K, V> newHashMap(Class<K> keyClass, Class<V> valueClass) {
    return null;
}

JAVA Genericsの実行時型情報は、たしかインスタンスを持ってれば解決できるから、
必要な人は型問い合わせようのインスタンスを持たせるってのがセオリーだった気がした。
>>944みたく型のインスタンスではなくて、直接Classのインスタンスを持たせてもいいけど。
英語の記事読まないで三流ライターの戯言ばかり読んでると、日本独特の馴れ合いに引きずりこまれちゃって出てこれないくなるよ。

>>945
何言ってるんだ？インスタンスから型引数は取得できないよ
クラスやフィールド型、メソッドの引数型や返値型からは取得できる

>>944
何の意味がある？こっちの方がマシだろ

Map<String, Integer> map = newHashMap();

public static <K, V> HashMap<K, V> newHashMap() {
　return new HashMap<K, V>();
}

>>944は型情報を持ったHashMapを作る例だと

>>948
理解した

public class MyMap<K, V> extends HashMap<K, V> {
　private Class<K> keyType;
　private Class<V> valueType;

ってことか

細かいところが分かってないね。
ていうかGenericsを語るなら当然知ってないといけないところなんだけどね…

http://codezine.jp/article/detail/2397?p=2
ではファクトリーメソッドをマンセーしてるみたいだけど。

キャストって意外とコストって高いのか安いのか微妙だな。
マイクロベンチでキャストの有る無しの差を比べてみたが、
10億回キャストしても手元の環境だと300msくらいしか増えなかった。
（試したのはClientVM、ServerVMだと最適化されすぎて0msになったｗ）

genericsよりお前らのいってることが分からない
みんな端折りすぎなんだよ

>>951
お前のコスト安はどこからだよ！
俺、明日からキャスト沢山振りかけて食べることにするわ

閑話休題。

ごめん、JAMってどうなった？JSR-277は破綻したんだよな？
.jamアーカイブそのものが無くなったの？

jsr277は死亡、jsr294だけJava7に入る

JSR294だけでどうやってクラスパスの衝突を避けるの？
JAM（というかMODULE-INFディレクトリ）はJSR277の仕様でしょ？
結局の所、最新のjarを落としてきて後方互換性を盲信するのと何が違うんだろ。

jsr277がjsr294に取り込まれたんじゃないの？

>>951
知らないの？VM上ではキャストはコスト高いよ。
特にループ内部にキャストのコードを入れるときは無駄が多くなる。

IBMとapacheがOSGiに流れてる状況で、JSR277が出てきてもまとまらないよなあ。

ヒント：IBM=apache

どうでもいい言語機能よりさっさと native2ascii を捨てろよ。
UTF-8 を標準にしときゃ native2ascii かけた既存のプロパティファイルと互換保てるだろ。

XMLプロパティか

てかさ、Propertiesクラスそのものを非推奨にしようよ。
あれ何でHashMapベースなの？Mapをコンポジットしろよ。
出力した時は普通LinkedHashMapかSortedMapの動作を期待するだろ。

Propertiesはextends Hashtableだが。

ほぼどうでもいい重箱の隅だと思うのだが。

どうでもいいネタにふさわしいツッコミだと思うのだが。

スレ汚ししたいなら他所でどうぞ。

他所いけってさ>>961

SEIのXMLを利用できるAPIを総点検中なんだが、
XMLEncoder/Decoderがひっそりと enum に対応してた。
どっかにアナウンスがあったっけ？

jdk7 build54
http://download.java.net/jdk7/binaries/
http://download.java.net/jdk7/changes/jdk7-b54.html

awt関連のバグ取り。

大規模なシステムほどJAVAで組まれてると言われるけど、
実際はけっこーCも多いよね。
結局大量の処理をする場合Cの速度が優位になっていく。
事実Cで組まれたシステムが第一線で使われてるケースもかなり多い訳で。
JAVAがそれに対抗しろとは言わないが、汎用性ではJAVA・・でもやっぱシステム組んでもらえるならCがいいという構図は
なかなか変わりそうにないなぁと思った

ベンチマークだと、速度はともかくメモリ消費量は１桁違うみたいだね
ttp://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=java&lang2=gcc&box=1

そりゃぁ、年金から年間８００億円も融通してもらえるような超巨大企業なら
工数度外視でＣで開発したりできるだろね。
とにかくガバガバ金つかえ、納期気にすんな、人月？なにソレ？って漢字で
何年も何年もダラダラダラダラと、去年８００億円、ことし８００億円、来年も８００億円・・・
年金という金のなる木が枯れるまで、骨の髄までしゃぶり尽くすんだろ。
民営化とは名ばかりで、金の流れ道が少し変わっただけ。政府とズブズブやんけ。

大規模が処理量の大規模ならCなんだろうけど
機能数の大規模や開発者数の大規模の場合に
Cを選ぶとプロジェクトが遅延しまくるんじゃまいか

大規模で膨大なトランザクション抱えている所はどこも I/O がネックになってるから
C と Java 程度の速度差なんてたいした話ではないな。インフラならともかく、金融系の
膨大かつ毎年改訂の入るような業務ロジックを C で組むなんてアホも良いとこ。
大体、速度を求めるなら普通は開発リスクのないハードの増強に投資する。

トランザクション量で金融は大規模ではない
ネット証券大手でもTwitterやブログとは何桁も少ない
もちろん信頼性の要求も桁が違うがそもそも金融程度の
トランザクション量ならCを選ぶ必要はない
例外は証券取引所くらいか

トランザクションと HTTP リクエストの区別の付いていない方が居られるようだが…

976は当然トランザクションのことを書いている
それが分からないのは視野が狭いのではないか

元の話(>>971)ではトランザクションの話なんてしてないし
実際Cで書く意味があるかどうかはトランザクションより
HTTPリクエストの量だろうがな

おまいら C に幻想持ちすぎ。

それLinusに言ってみたら？

COBOL化まっしぐら

WEBアプリ以外はアプリに非ず、って風潮？

どこが？

>>979
元の話(>>971)ではトランザクションの話もＨＴＴＰの話もしてないし。
ただ「大規模なシステム」としか書いてない。
何の前提も無いときはＨＴＴＰの話がデフォルトというわけなのか。

>>976
DB/ホストへのアクセス量が全然違う。ブログと同じ程度のシステムしか組んだ事ないのかよ。

C言語と相性の悪い言語って基本的には無いと思う。
処理性能とフットプリントの小ささに信頼のある言語は他に見あたらない。
処理性能だけならいくつかのベンチマークではGNU CよりJavaのが速いから、
これはもう言語というよりコンパイラ屋をどれだけ囲ってるかの差だな。

Javaのメモリ周りの最適化はやりつくした感じ（スタック割り当てとか）だけど、
Cのほうは、JITの導入が始まってきた（LLVMとか）ところだからなあ。

>>985
>>979は>>977を見て書いたからHTTPが出てる
トランザクションは>>974-975の流れだな

>>986
君は金融しか経験がないようだな
いくらハイエンドのサーバでもOracle(RACも含む)なんかで集中型の
DBMSで運用できているという事実が金融はトランザクション量が
たいしたことないという事実を語っている
大規模ってのは君が考えてるより二桁三桁多いトランザクションをさばいてるよ

>>990
いや、単におまいがオープン系の世界しか知らんだけだと思う。

>>991
大手ネット証券やってますが何か？

ちょｗ
基幹系が Oracle で運用できてるってどこのサラ金の事だよｗ

バックはメインフレームだけどフロントのDBMSはOracleよ
ネット専業に限らず証券はだいたいそんなもん

>>992
でかいところだと赤と緑の某都銀にもっと巨大な某生保、損保最大手、某FRB生命なんかで
やってましたが何か (何をかまでは特定されるので言わない)。先日民営化されたバケモノは
何とか足抜けられたが。
というか、どう見てもトランザクション≒HTTPアクセスという認識で語ってるようにしか
見えないわけだが… 今時のブログは PHP を TP モニターで監視でもしてんの?

やっぱり金融バカかw

おまえ、やっぱりフロント側の、しかも Web 周りしか開発したことのないだろ。
トランザクションの話でブログ引き合いに出してるような時点で知れてんだよ。

2

証券バックもやったし銀行も少しだけやったよ
つか、後ろの方がトランザクション量的にはずっと少ないじゃん
バッチやディレイドオンラインのデータ量は多いけど効率いいから負荷少ないよね
保険はやったことないからどんな感じか興味あるけど次スレに持ち越して欲しくはないw

1000ならJava7年内リリース

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。