[mustang/Java SE 6] 次世代Javaの動向 4 [dolphin]

座標上の点の計算には便利そうだ。特に回転とか。
複素数クラスがあってもnewしまくるから遠慮してたけど、
言語に追加されるなら便利そうだけどな。

今のトレンドは言語に複素数を追加することなんじゃないか。
C,D,Pythonは既に言語レベルでサポートしてるし。

トレンドってほど支持する流れも否定する流れも大きくないと思うが……

>>933
頭悪そう
C99を使ってろ

>>936
ちなみに、何を作りたくて複素数型が必要なんだ？

>>934
C#の値型は、クラスと比べてどんなメリットがあるの？
コンパイル時に最適化されて
ランタイム負荷が小さいとか？

>>940
クラスのオブジェクトに比べ生成と削除のコストが低い。
値型は参照を介せずにスタックに直接値が格納されたり、
配列やクラスのメンバーとして直接その領域に値が格納されるので
ボクシングが発生しない限りGCの必要な実体が作られることがない。
このためプリミティブ型に近いパフォーマンスを発揮する。

>>939
必要ないんでしょ。

ってか、実際に複素数型が必要な分野のプログラム組んでる人間が
「演算子オーバーロードよりもプリミティブな複素数型」なんて言うとは考えられないし。

>>941
値型ってのが広い範囲を表すからいいたいことがあいまいだぞ

下手に構造体チックなものが登場されてもBeanの文化が壊れるから
ByteBufferで我慢が出来ないなら諦めてくれって方針で十分。

>>933
だから、それはプリミティブ型じゃないだろ。

Ｃ＃の値型みたいなのがほすぃ
って言いたかっただけなんじゃないか、と。

>>946
Java に C# の値型みたいなの導入すると
コンパイラ弄るだけじゃすまなくて、それこそ VMの変更が必要なりそうだし。
メソッドの戻り値で値型を使う場合とか。

それに、C# は最初から値型があったから良いけど、
Java の場合は generics 導入しちゃった後だからねぇ。
今から C# の値型みたいなものを追加したとしても
現時点でのプリミティブ型みたいに generics で使えなさそうだし。

Javaも遅かれ早かれVMの拡張は必要になると思うのだがいつごろ来ると思う？

>>948
おいおい……
バイトコードインストラクションの話ならJSR-292のinvokedynamic追加の検討中。
後は>>893がfunction type関連でVM拡張とか言ってる。

>>949
さんくす。複素数の議論でVM拡張は避けるべき的な話が出てたので確認してみた。
別にVM拡張前提で話をしてもかまわないわけだよね。

>>950
ここは「次世代Javaの動向」をヲチるスレだから、
新機能追加の要望とか、単なる妄想オナニーなら他所でやってくれ。

だれもVM拡張は避けろといってなくて、プリミティブ型を追加するならVM変更という話と、そんな無意味な要求は却下されるよという話が同時進行してただけかと。

>>951
ヲチするだけとはどこにも書いてないわけで。
しかも、最初から要望とか妄想オナニーばかりのスレで、950も過ぎてから言ったところで説得力ない。

>>953
今回ので言えば、既に >>935 で他所行けって出てるし。
他の話題でも他所行けってのは散々出てるし。

つまり、スレの流れについていけなくてわめいてるってわけか。

>>953
便所に落書きしても要望だとは思われないよな。普通は。

複素数を扱うライブラリがあれば便利だと思うが
言語仕様に含めるのはやり過ぎです。

ところで値型って、VBのByValを指しているの？

>>957
ここは予想や感想を述べる場所じゃないとのことなので、
そういう動向は今のところ無いということでおしまいらしい。

値型はVB.NET以降では、ユーザー定義型（Structure）、Enum、クラスを除くVBの基本データ型をさす。
VBのデータ型と.NET(CLR)のプリミティブ型は若干違うから注意。
ここではユーザー定義型（Structure）の意味で使ってる。
.NET(CLR)ではValueType C#ではstruct。
Javaだと参照型以外の型＝プリミティブ型＝値型という理解でいいのかな？（自信は無いが）

あとは質問か雑談スレへとかいわれそうだ。

>>956
「普通は。」ってなんだよ 9m(^x^

C#：全部ヒープに置いたら遅いだろ！struct導入する！
Java：エスケープ分析で自動的にスタックに置くｳﾏｰ

どうもsturct(値型）の話になってるようだけど、なんなら
typedef double complex[2];
でいいじゃん。どう実装されるかなんかはベンダ任せなんだけどね。

ベンダ任せなわけがない

Hさん、居るよね。

MさんとKさんもいるよね。

JCSPをクラスライブラリに組み入れるべきだ。
VMに組み込むべきだ。

JDK7 build12
http://download.java.net/jdk7/changes/jdk7-b12.html
http://download.java.net/jdk7/binaries/

IO関連とOpenJDK関連の修正が多いみたい。

Java FXとJava FX Scriptだそうです。
一波乱ありそうだな。ネットスケープにJavaの商標貸さなかったら
JavaScriptになってたんだろうな。

正直、JavaFXという名前は．．．
もうちょっとカッコ良い名前を考えてくれー

Flexと、ECMAScriptとかとどう絡むのか、だ。
そして、Pnutsとの絡みも・・・

JavaFX ScriptはXAMLの対抗馬って感じだね〜。
個人的にはXMLより見やすくて良さそう。

Groovyの立場は・・・・？

GroovyはJavaをベースにスクリプトを作ったタイプ
FXは新規におこしたもの、というよりは>>970のいうようにXAML対抗に見える

Javascriptは標準APIにきたことや、JRubyの力の入れ具合もすごいことで
Groovyがどんどん存在価値がなくなってるのは確かに悲しいかも

でも、実際Groovyのメリットがよく分かりませんが・・・
全然簡単じゃないし。速くもないし・・・・

JRubyよりJythonのが有力だろ。
Pythonは世界では結構使われてるが日本ではドマイナーという部分を引いても。

けど、サーバーサイドでrubyが祭り起こしたし
最近JRubyも1.0へ向けてラストスパートって所だから熱いよね。
JavaEEサーバと相性良いかも。

Groovyは更新遅いし、スクリプト言語らしい手抜きが出来ないし・・・
う〜んRhinoでLiveConnect使うよりJavaとの親和性高いんだけどね。
ただ、jdk6のRhinoはただの劣化品。

ランタイムさえあればいいというのは十分メリット
標準APIなんてそんなものだ

Pythonは各種IDEのサポート具合考えると日本以外でも注目されてないんじゃないの？
Googleでもそれほどマンセーじゃなかったのが意外だったけど

そういやJRubyのRoRのが本家より速いって記事を見かけたが
これは本家の実装がしょぼいってこと？

JVMは、HotSpotの性能が上がってきたからそれはあり得るな。
JVMの性能向上がポイントじゃないか？
同じ意味で、Jyphonも注目あびてんじゃないかと思う。

釣れますか？

新しいJREってサイズどのくらいなんだろうね。
Flash Player並にさくっとインストールされるようになると最高なんだけど。

今1.2のJDKもみると小さいな・・・
1.2、1.4とか1.5の大きさにそれぞれ驚いたものだ
>>976
JavaScriptingAPI上のスクリプトはコンパイルして実行できるから速くても驚かん
つーか、実際速いので運用はJavaVMでというのが現実的

ScriptingAPIのバイトコードコンパイラはオプションだぞ？
動的・静的共にバイトコードへコンパイル可能なRhinoが
すべてとっぱらわれてインタプリタモードのみになったんだぞ？
だから実装次第。

コンパイルモードのRhino早かったのに・・・。

だれか、Javaのクラスをバイナリーエディタで作成する方法を教えてくれませんか？

なんでここで聞くの？

>>981
ん？オプションであるというのは>>980の書き方でわかるはずだが

>>982
http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html