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

>>951
その辺の返し方がクソスレｗｗ

typedefもどきはやめてくれ
ソースコードが読みにくくなるんだよ

>>952
糞は無理して発言しなくていいよ。それよか、海外でもいいから、ねたブログとかないの？

今のクロージャの仕様はtypedefよりひどいじゃねーかww

interface F {
　int f1(int x, int y);
　String f2(int x, int y);
}

F f = { int x, int y => x + y };
f.invoke(10, 100);

なんだよこれ

どこかどう酷いのか書いてない用だけど…
おまえ、あたま大丈夫？

>>955
これってメソッドが2つあるからコンパイルエラーでは?
なんか問題あるの?

>>957
ところが仕様ではこれがOKなのさ
驚きだろ？

これ自体は、イヤな動きだけども、これはどのくらいの頻度でありうるものなのかな
そして、どのくらいの頻度で、問題のある動きになるのかな？

メリットはかなり大きいと思うが、割りにあうのかないのか

>>955
それならもうC#しかないな。C#でもDでもいいから、一緒にやらないか？

Scalaでいいよ！

scalaだけど少し調べてみたけど数年後には来そうだね。
でもグルービーと比べるとイマイチ違いがないんだよね（言語機能じゃなくて）。
グルービーはJSRで仕様堅めに入ってるから先が見込めるけど、scalaは（言語機能じゃなくて）普及の兆しを感じないな。

個人的にはjdk1.6で既にサポートされてるrhinoでいいんじゃないかと思う。

静的型でクラスファイルができるのと、スクリプトと、違いがないってのか。
しかもrhinoでいいんじゃないかとかいう。

その言語で作ったクラスをJavaで自由に扱えるかどうかも、でかいとおもうよ。

↑全く意味不明なので、書き直してもらえませんか？

rhinoやgroovyじゃ、Java言語の代わりにはなれません。

スクリプトサポートの目的はJavaの代わりになるかでなくて、Javaでは難しいところやかゆいところに手が届くって意味じゃないの？

個人レベルで使うなら何だっていいが、企業向け開発だとなぁ
言語仕様も大事だが、大手のサポートやツールの有無
つまり周辺環境がないとどうしようもない
今んところ実質的な代替はC#にしかできないでしょ
あとはRubyがちょっと流行ったくらい
JavaがgdgdになるならScalaもありかもしんないけど
企業向けに立ち上がるにはよほど運がないと無理でしょ

java langやjvmがサポートするのはフレームワークだと思うんだが、なんか外してないか？
まあ、このスレはこの程度かｗ

>>966
Scalaはスクリプトサポートではなく、Java言語の代替として使うことを考えられてる。
だから静的コンパイルされてクラスファイルを生成して動かす。
そうすると、Javaと同等かそれ以上の速さで動く。
クラスファイルだから、Javaからも比較的自由に使える。つまり特別な仕組みを使わなくてもServletやJPAのクラスが作れるということ。
部分的な適用がやりやすくなる。
で、今は、Javaの言語仕様拡張よりScalaじゃねぇの？って文脈。Javaの代わりになるかという話。

>>967
企業向けのエンドプログラマはJava1.4で充分でしょ。

言語オタクのおもちゃならScalaで十分
Javaになんでもかんでも詰め込んで欲しいとは思わん

>>969みたいな
こういう俺様俺様ってのはどこにでもいるよなｗｗC++なんかこんな奴らの固まりだしｗｗ

スカラもグルービも、ジャヴァも、クラスファイルを作ってJVMプラットフォームで動くんじゃなかったの？（.Netみたいに）

企業向けだって1.4じゃつらすぎる。5つかっててｵﾓﾀ。

rhinoもバイトコードコンパイラあるんだが

ジャヴァジャヴァ

>>958
v0.5って仕様にはclosure conversionはsingle methodを持つもの、
って書いてあるのでそのケースはエラーになると思ったんだけど、どっか他に仕様がある?
呼ばれるメソッドが不定に見えるのでエラーにするのが普通だと思うんだが。

あと最後のinvokeはFがinvoke持ってないからエラーになるような。invokeに関しては、function typeがinvokeを持つinterfaceとして扱われるのでは。

Tグループの会社を何件か見たが、どこもJava1.3が入ってたりして焦った。
定期的にアップグレードする計画を立てるのもシステム課の重要な仕事だな。

いろいろ動かなくなるからアップグレードしちゃだめだよ

>>976
それが普通だよなw
インタフェースのメソッドは一つらしい
でも例外的に他のメソッドの引数がObjectのときはOK
つまり正しくは以下のコードだったよ

interface F {
　int f1(int x, int y);
　String f2(Object x, Object y);
}

F f = { int x, int y => x + y };
f.invoke(10, 100);

invokeはクロージャを実行する特別メソッド
インタフェースとは全然関係ない
だから以下のように書けるようだ

{ int x, int y => x + y }.invoke(10,20);

これもなんだかどうしようもないよな
最初の例見ると可読性ないよw

>>978
部署に一台、事務処理専用マシンを作っていくのは基本だろ？

>>979　それが通るなら、逆にこれも通るのかな？


interface F {
　int f1(int x, int y);
　String f2(Object x, Object y);
}

class MyClass implements F{

int f1(int x, int y){
return x + y;
}

String f2(Object x, Object y){
return x.toString() + y.toString();
}
}



F f = new MyClass();
f.invoke(2,3);

>>981
それは無理だよ
どこにもクロージャ使ってないでそ

こいつは、メソッドレファレンスMyClass#meth()のこといってんじゃないの？

なんだそりゃw

Java 7の目玉機能は、クロージャだけなんですか？

モジュール？

>>979
その仕様はどこに書いてあるん?
なんでその例外的ルールがあるのかわらない。

それから、
F f = { int x, int y => x + y };
f.invoke(10, 100);
これはFがinvokeを持ってないので無理でしょ?
invokeはclosure literalが持つってだけで、特別なメソッドではないでしょ?
(だから>>981は無理なはず)

{int x, int y => x+y }.invoke(10,100)ができるのは分かる。
これはclosure literalがinvoke(int,int)を持つ型なので。

function typeがinvokeを持ってて、他のinterfaceの型に変換するときにそのinterfaceの持つ1つのメソッドに割り当てられるってことでは。
あと、literalに直接invoke呼ぶのはそんなに無いんじゃないだろうか。

>>985
プロパティ構文が一番じゃね?

こいつの主義からすれば、func.invoke(aho) じゃなくて、func(aho) とやりたいってのじゃないの？

どうせスカラー云々スクリプト云々って奴だろｗ
こいつの頭の中ではごっちゃになってて、サル脳だから理解できないんだろうｗｗ

>>987
たいして仕様を読んでないようなサルの相手をすることもないんじゃないの？
君も同じく相当ヒマだろうけどｗ

このスレって偉そうに言ってる奴はどこが悪いのか指摘すらできないんだよなwwww

>>990
なら仕様を読みまくってる君が簡潔に説明してみたらいいのではないだろうか
なんでここ見てるわけ？

>>991,992

くやしいのｗｗｗくやしいのｗｗｗｗｗｗ

> くやしいのｗｗｗ

知らねぇのに無理して使うなよ。ほしのあきじゃねぇんだから。
くやしいのうｗｗｗ

>>994
ゴミはまだ常任してんのか。
おまえのうんちくはイランから、はよ死ね。

くやしいのうｗｗｗ　くやしいのうｗｗｗ　(ｹﾞﾗ

何この糞ｗｗｗ
次スレもいらんわｗ

>>996
そんな雑学よりも、英語をみっちり勉強した方が自分スキル向上になるんじゃないでしょうか？

逝 っ て よ し ｗ

age 全開で自己援護に必死

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。