5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

1 :デフォルトの名無しさん:2008/09/04(木) 21:34:07
■■前スレッド■■
[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の動向 2
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/

2 :デフォルトの名無しさん:2008/09/04(木) 21:36:17
■■■関連スレ
【初心者】Java質問・相談スレッド119【歓迎】
http://pc11.2ch.net/test/read.cgi/tech/1220388885/
【徹底討論】Java3Dの可能性について考える
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/

3 :デフォルトの名無しさん:2008/09/04(木) 22:57:53


4 :デフォルトの名無しさん:2008/09/05(金) 00:22:41
クロージャーのことがまだ良くわかっていないのだが俺は、
クロージャーのことがよくわかる参考資料はないかね

5 :デフォルトの名無しさん:2008/09/05(金) 01:01:36
BCPLの仕様とそこからリンクしてあるチュートリアル嫁。カス野郎

6 :デフォルトの名無しさん:2008/09/05(金) 12:00:40
JDK7 build34
http://download.java.net/jdk7/changes/jdk7-b34.html
http://download.java.net/jdk7/binaries/

7 :デフォルトの名無しさん:2008/09/05(金) 23:46:52
6u10っていつ頃ですか?

8 :デフォルトの名無しさん:2008/09/05(金) 23:54:12
>>7
今秋予定。いまRCまできてる。

9 :デフォルトの名無しさん:2008/09/05(金) 23:56:40
NIO2 のバイナリ : jdk7build33 + NIO2
http://download.java.net/jdk7/jsr203/binaries/

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

10 :デフォルトの名無しさん:2008/09/05(金) 23:56:54
>>8
ありがとう。6u8や6u9が間にあると思ってたけど、すっとばすんだね。

11 :デフォルトの名無しさん:2008/09/06(土) 16:30:46
演算子オーバーロードーのことを気にする人がかなり減ったけど、あの熱気は一体なんだったんだろうと思う。
もし言語として必要(必須)なら今でも不満が出るんだろうけど、やっぱり一時の浮気心であって実際はどうでも良かったのかな…
この辺りはどう思う?

12 :デフォルトの名無しさん:2008/09/06(土) 16:35:03
BigIntegerやBigDecimalを除けば、
特に欲しいと思える機能ではないな。

13 :デフォルトの名無しさん:2008/09/06(土) 17:26:57
それだと、BigDecimalはextendsして自分でメソッドを定義すればいいんじゃない?

14 : :2008/09/06(土) 17:58:26
JDK 7はいつごろリリースされるの?
さらにEclipseが対応するのはいつごろ?

15 :デフォルトの名無しさん:2008/09/07(日) 07:10:08
JDK7のリリース予定は、いまのところ来年夏かな?
http://www.javaworld.com/javaworld/jw-05-2008/jw-05-rightsize.html

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

16 : :2008/09/07(日) 10:02:40
>>15
ありがとうございます。
まだまだ先ですね。

17 :デフォルトの名無しさん:2008/09/08(月) 14:48:21
>>11
あれは熱気じゃないだろw ただの荒らしがしでかしたもの。
過去に「C#って死滅しちゃうのスレ」でJavaアンチが散々煽っていたネタの一つw

18 :デフォルトの名無しさん:2008/09/08(月) 14:58:36
次のJVMではたくさんのスクリプト言語がサポートされるんですが、この選考基準はなんですか?
自分のスクリプトをevalさせるのは簡単ですか?

19 :デフォルトの名無しさん:2008/09/08(月) 21:59:58
コミュニティの数とか、歴史とかじゃない?
Pnutsのユーザーとかまだ居たりするのかな。

20 :デフォルトの名無しさん:2008/09/08(月) 23:03:03
>>18
何か追加される予定あったっけか?
今のところ Rhino しか入ってないと思ったが。

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

21 :デフォルトの名無しさん:2008/09/08(月) 23:07:52
>>20
つ JavaFX

22 :デフォルトの名無しさん:2008/09/08(月) 23:31:26
>>20
SPI登録っていってもCLASSPATHにJar通せば終わり

23 :デフォルトの名無しさん:2008/09/08(月) 23:31:50
JavaFXはRAD環境がないらしいけど、
βから作り始めてる猛者はいるのかな。

24 :22:2008/09/08(月) 23:32:43
悪い、実装する側の話ね。

25 :デフォルトの名無しさん:2008/09/09(火) 09:59:47
スクリプトサポートといっても、なんか難しそう・・・

26 :デフォルトの名無しさん:2008/09/12(金) 23:34:10

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

27 :デフォルトの名無しさん:2008/09/17(水) 02:24:34
ところで、前スレで、ScalaはJavaVMで動かすことを考えられた言語でネイティブにバイトコード対応してるから速いと書いたら、GroovyやRhinoでもバイトコード変換ができるという答えが返ってきてたんだけど、GroovyやRhinoのコードでJava言語よりも速いコードが吐けるの?

28 :デフォルトの名無しさん:2008/09/17(水) 07:10:27
>>27
バイトコードに変換するコンパイラがどれだけ頑張るかによる。

29 :デフォルトの名無しさん:2008/09/19(金) 08:45:05
>>28
今どきのJVMのJITは、Javaコンパイラが通常吐き出すバイトコードに、
かなり特化した最適化が行われているから、
いかにJavaコンパイラが吐き出すバイトコードに近いコードを生成するかが、
高速化の鍵になると思う。


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

31 :デフォルトの名無しさん:2008/09/19(金) 09:36:41
> 今どきのJVMのJITは、Javaコンパイラが通常吐き出すバイトコードに、
> かなり特化した最適化が行われている

具体的には?

32 :デフォルトの名無しさん:2008/09/19(金) 09:39:53
>>30
あのへんは InvokeDynamic使えればリフレクション使わなくてもよくなるかも。

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

34 :デフォルトの名無しさん:2008/09/21(日) 02:41:40
で、Scalaが速い理由は、単にバイトコード吐くからじゃなくて、
静的型付けで、しかもJavaに比較的近い型システムを持っているため、より
直接的にJVMのバイトコードにマッピングできるから。たとえば、scala.Int
型同士の加算は単にJVMのiadd命令になったりする。

35 :デフォルトの名無しさん:2008/09/21(日) 07:14:05
>>33
structural conformance とかもそうだね。

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

36 :デフォルトの名無しさん:2008/09/21(日) 08:19:06
interface MyIn
{
class MyCl {}
}
とすると、内部クラスはインターフェイスの規約どおり必ずpublic static final class MyCl
として扱われるんですか?

37 :デフォルトの名無しさん:2008/09/21(日) 08:26:45
>>34
そんな紹介記事読めば書いてあるような事を一生懸命書かなくても……

38 :デフォルトの名無しさん:2008/09/21(日) 08:29:53
>>36
誤爆しました。

39 :デフォルトの名無しさん:2008/09/24(水) 09:33:15
BeansBindingって7に含まれるのかな?

40 :デフォルトの名無しさん:2008/10/01(水) 01:12:46
>>39
たぶん含まれると思うけど。
7 のスペックリードの Danny Coward の追っかけでもやらんと最新の動向はわかんない。

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

41 :デフォルトの名無しさん:2008/10/01(水) 02:09:09
それ、ハッタリだって。

42 :デフォルトの名無しさん:2008/10/01(水) 09:15:52
>>40
あれま。closureはどうなるのかな。

43 :デフォルトの名無しさん:2008/10/26(日) 08:39:07
JDK7 build38
http://www.java.net/download/jdk7/changes/jdk7-b38.html
http://download.java.net/jdk7/binaries/

44 :デフォルトの名無しさん:2008/10/26(日) 08:49:53
おお
JColorChooserにHSLタブが追加されたんだw

45 :デフォルトの名無しさん:2008/10/27(月) 11:05:36
>>42
仕事はdotNetだけど、
バランスのために趣味でJava言語の設計と開発を続けると書いてある。> blog

46 :デフォルトの名無しさん:2008/10/31(金) 22:34:23
次世代ではないが、6u10はいつになったらダウンロード出来るんだ。

47 :デフォルトの名無しさん:2008/10/31(金) 22:37:36
英語ページからならはじめから。
日本語ページから落とさなくてもMulilingualだから
どうせ同じバイナリですよ

48 :デフォルトの名無しさん:2008/10/31(金) 23:52:48
自分も英語ページから落としたけど
日本語ページの放置っぷりに、Sunのやる気の無さが伺えたw

49 :デフォルトの名無しさん:2008/11/01(土) 02:36:38
JAVAって欠陥言語だろ?
本も種類多すぎだし、コードはクソ見づらくなるし
何がいいの?

50 :デフォルトの名無しさん:2008/11/01(土) 09:14:48
>>49
コボラー乙

51 :デフォルトの名無しさん:2008/11/01(土) 16:12:45
SwingLabsのJXTreeTableって標準で実装される可能性はない?
これだけは欲しいんだよねー

52 :デフォルトの名無しさん:2008/11/11(火) 00:06:35
JDK7 build39
http://www.java.net/download/jdk7/changes/jdk7-b39.html
http://download.java.net/jdk7/binaries/

53 :デフォルトの名無しさん:2008/11/21(金) 22:50:59
最近のJVMの進化は凄いね。部分的にだけどJavaがCの処理速度を超え始めてるよ。
ttp://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=java&lang2=gcc

54 :デフォルトの名無しさん:2008/11/22(土) 00:13:58
部分的ならかなり昔に越えてるよ。
1.4の頃からアルゴリズムの教科書に載っているようなプログラムは
Javaの方が早いのが結構あった。

55 :デフォルトの名無しさん:2008/11/22(土) 00:20:34
>>53
それ、最新のJVM使ってないんじゃね?

56 :デフォルトの名無しさん:2008/11/22(土) 03:14:27
>>54
6.0になると、体感で1.4の倍くらい速いしなぁ。

57 :デフォルトの名無しさん:2008/11/22(土) 20:53:05
6はGUIまわりが高速化されたイメージが強いな
性格にベンチしたわけじゃないので、あくまで個人的な感覚だけど

58 :デフォルトの名無しさん:2008/11/22(土) 21:06:44
>>53
Cでオレオレ言語とオレオレVM作って、Javaを巻き返したとしたら
Cが速い事になるんだろうか。それともオレオレ言語が速い事になるんだろうか。

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

59 :デフォルトの名無しさん:2008/11/22(土) 21:16:15
所詮最後は機械語な訳だから、動的コンパイルの勝利って視点が正しい気がする。

60 :デフォルトの名無しさん:2008/11/23(日) 01:15:57
gcc-llvmってのがあるから、
そいつがCも速くしてくれるかも知れない。
ただあまり低レベルな記述ができないほうが、
プログラム解析には有利なんだよな。

61 :デフォルトの名無しさん:2008/11/24(月) 21:44:20
JDK7 build39
http://download.java.net/jdk7/changes/jdk7-b40.html
http://download.java.net/jdk7/binaries/

62 :デフォルトの名無しさん:2008/11/24(月) 21:57:41
> build39

63 :デフォルトの名無しさん:2008/11/27(木) 23:02:28
次の目玉機能といえるクロージャや追加スクリプトとかの話題を最近聞かないんですけど、やっぱ止めちゃったんですか?


64 :デフォルトの名無しさん:2008/11/28(金) 01:40:06
Neal GafterがMicrosoft行ってから、
> Current prototype: http://www.javac.info/closures.tar.gz (updated 2008-08-11)
更新されてないからね。

65 :デフォルトの名無しさん:2008/11/28(金) 01:48:09
なんかこう
gdgd感が漂ってるよね・・・

66 :デフォルトの名無しさん:2008/11/28(金) 01:52:09
そのニアルってゴスリンの部下じゃなかったのか。
一度MSに行くともうSUNに戻ってもリーダーになれないような感じだけど、SUNの社風はそうでもないのか?
それともいい仕事する割には、ストレスに弱いのかw

67 :デフォルトの名無しさん:2008/11/28(金) 02:06:24
Sunつぶれそうだから逃げ出したんでしょ

68 :デフォルトの名無しさん:2008/11/28(金) 02:15:37
今のSUNはかなり儲かってんだが。
レイオフはよくあることだし、どっかの大学と提携して順調だろ?


69 :デフォルトの名無しさん:2008/11/28(金) 02:31:17
ニールはマイクロソフトのスパイだったって話だよ

70 :デフォルトの名無しさん:2008/11/28(金) 02:32:15
>>68
かなり儲かってる?どこが?
http://www.itmedia.co.jp/enterprise/articles/0810/31/news022.html

71 :デフォルトの名無しさん:2008/11/28(金) 02:39:07
おまえ、営業利益とか経常利益とか言われてもさっぱりで財務とか苦手だろw
隠さなくてもいいぞww


72 :デフォルトの名無しさん:2008/11/28(金) 02:47:48
Neal GafterはGoogleにいたんだよ。
GoogleのJavaのチーフ。Google Calendar作った。
その前はSunでJavaのコンパイラ。

73 :デフォルトの名無しさん:2008/11/28(金) 03:34:53
>>71
純損失が16億ドルあって「かなり儲かってる」といえる理由がわからないので、財務とか苦手なようだ。
ちょっと解説してもらえないだろうか?

74 :デフォルトの名無しさん:2008/11/28(金) 03:38:42
UNIX板にSunスレあるぞ。二人とも行け

75 :デフォルトの名無しさん:2008/11/28(金) 04:41:40
そういう話じゃないだろ

76 :デフォルトの名無しさん:2008/11/28(金) 05:02:23
そういう話だろ

77 :デフォルトの名無しさん:2008/11/28(金) 05:13:23
文脈よめねぇの?

78 :デフォルトの名無しさん:2008/11/28(金) 05:19:47
つうか、次世代Javaの動向にSunの経営状況が密接に関係あるのわかってないのか

79 :デフォルトの名無しさん:2008/11/28(金) 09:12:06
SunはヤバいからJDKの実質有償化をゴリ押ししてなんとか金にしようとしてるんでしょ

80 :デフォルトの名無しさん:2008/11/28(金) 09:21:12
jdk1.4のサポートを有料で継続するって話?

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

81 :デフォルトの名無しさん:2008/11/28(金) 09:25:41
古いのも次世代も、今後は出てから3年で無償サポート切られるよ

82 :デフォルトの名無しさん:2008/11/28(金) 09:28:16
新しいのはGPL化されたOpenJDKがあるからやろうと思えば自力で手を入れられるし。

83 :デフォルトの名無しさん:2008/11/28(金) 11:54:14
一般カスタマー向けじゃあるまないし、3年は早すぎだな
jvmやjdkライブラリも、もともと低額でも有償だったらあまり使われなかっただろうし
XBoxやPSとかみても5年から7年過ぎたらってところじゃないか?

84 :デフォルトの名無しさん:2008/11/28(金) 12:47:45
ゲーム機w

85 :デフォルトの名無しさん:2008/11/28(金) 12:55:37
携帯でも成功したので、jvmの次のターゲットはゲーム機ですよ?

86 :デフォルトの名無しさん:2008/11/28(金) 13:06:08
無償サポートのわけねえw

87 :デフォルトの名無しさん:2008/11/28(金) 13:41:40
ゲーム機が無償でもらえると聞いて

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

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

89 :デフォルトの名無しさん:2008/11/28(金) 18:20:51
dolphinっているかだろ?どうせなら、グランパスにしてほしかった。

90 :デフォルトの名無しさん:2008/11/28(金) 20:24:32
>>89
グランパスは8まで取っとくだろ常識的に考えて

91 :デフォルトの名無しさん:2008/11/28(金) 20:28:42
つまらん

92 :デフォルトの名無しさん:2008/11/28(金) 20:29:58
コードネームって廃止されたんじゃなかったっけ?

93 :デフォルトの名無しさん:2008/11/28(金) 20:41:11
相手にするだけ無駄だな

94 :デフォルトの名無しさん:2008/11/29(土) 16:12:53
>>90
激ウケwww

95 :デフォルトの名無しさん:2008/11/30(日) 13:37:05
>SUNは本来ハード会社だし、MSとはそもそも畑が違う。
javaが動く携帯ゲーム機作ってくれたら買うんだけどなぁ

96 :デフォルトの名無しさん:2008/11/30(日) 22:22:09
>>88

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

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


97 :デフォルトの名無しさん:2008/11/30(日) 23:51:37
PS3でjavaが動くと聞いて!

98 :デフォルトの名無しさん:2008/12/01(月) 00:03:03
>>96
必須ですよ。プロファイルがSEとはずいぶんと違いますが。
ネットで関連グッズ買わせるボーナス画面で既に使われてるはずです。
変わったエフェクトのメニューとか。

99 :デフォルトの名無しさん:2008/12/01(月) 01:23:00
でも携帯アプリみたく自分で作ったのが自由に転送できないなら、Java搭載かどうかはあまり意味ない。
それなら値段も安いしネットブックでやるし。
少し大きいけど、持ち運び可能な液晶と考えればそうでもない。

100 :デフォルトの名無しさん:2008/12/02(火) 15:28:15
クロージャもプロパティもサポートされないんですか・・・

101 :デフォルトの名無しさん:2008/12/02(火) 20:22:45
その代わりにJavaFXがサポートされます!

102 :デフォルトの名無しさん:2008/12/02(火) 22:15:20
JavaFXってコンシューマJREに載ってこなかったけどいつ出てくるの?
オーサリングツール作ってるってんなら待つけどさ。

103 :デフォルトの名無しさん:2008/12/02(火) 22:39:19
まだ先だろ。だいぶ待ってろ

104 :デフォルトの名無しさん:2008/12/02(火) 22:45:52
クロージャはサポートされないんですか。ならc#にします。

105 :デフォルトの名無しさん:2008/12/02(火) 23:46:15
>>102
JavaFXは今週プレリリース版出すらしいよ。

106 :デフォルトの名無しさん:2008/12/03(水) 13:33:09
Javaがレガシーだって? 冗談じゃないよ - James Goslingが語るJavaの現在
ttp://journal.mycom.co.jp/articles/2008/12/03/javasfather/index.html

107 :デフォルトの名無しさん:2008/12/03(水) 15:08:46
クロージャは早くて1年半後ってあったから、jdk1.7が出てから追加導入ってことになるかのかな。
SUNにはキャッシュが30億ドルあるってのが笑えた。
アメリカ本国が破綻することはないけど、タンス預金と同じ。
なんなら森ビルとか日本テレコムでも買収して固定資産化しろよw

108 :デフォルトの名無しさん:2008/12/03(水) 16:02:01
固定資産化ってアホか

109 :デフォルトの名無しさん:2008/12/03(水) 16:38:35
難しいことにアホが口を挟むなw

110 :デフォルトの名無しさん:2008/12/03(水) 17:31:42
>>108
おまえはそんなところにしか目がいかないのか?w

111 :デフォルトの名無しさん:2008/12/03(水) 19:43:47
オマエモナー

112 :デフォルトの名無しさん:2008/12/03(水) 20:35:33
FX 1.0、明日リリースだってー。

113 :デフォルトの名無しさん:2008/12/03(水) 22:52:55
>>112
Sunがいろいろ頑張ってるのはわかるんだけど、
さっぱり盛り上がってないよね……

114 :デフォルトの名無しさん:2008/12/03(水) 23:47:17
需要は少ないんだろうが、そろそろSwing上のハードウェア加算合成をサポートして欲しいなあ…

115 :デフォルトの名無しさん:2008/12/03(水) 23:52:27
名のあるゲームメーカーとかと組まなきゃ無理だろ。
Sun主導ででクライアントサイド技術が大成するとは思えない。

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

116 :デフォルトの名無しさん:2008/12/03(水) 23:58:12
Javaで商用アプリケーションはけっこうあるけど、商用のゲームなんか見たこと無いもんなあ。
Quake2エンジンはずいぶん前に移植できてるみたいだから、ポテンシャル的にはそこそこのものが動きそうな気もする。

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

117 :デフォルトの名無しさん:2008/12/04(木) 00:07:07
まぁでも、6u10以前のアプレットで作ったネットゲーム(RuneScape)で
億万長者になった人もいるにはいる。

118 :デフォルトの名無しさん:2008/12/04(木) 00:14:17
>>117
そういや、あのころJOGLはまだだろうし、Java3Dで頑張ってたのかな?

119 :デフォルトの名無しさん:2008/12/04(木) 21:34:40
 
【サンタクロース、トナカイの酒気帯び運用罪での逮捕に、マジ逆切れw】(ZDNet)
http://builder.japan.zdnet.com/story_media/20384793/081204_sun-james-gosling_02_400x300.jpg



120 :デフォルトの名無しさん:2008/12/05(金) 10:14:34
クロージャの導入にいつまでかかってんだよ
C#との差は広がるばかりだな

121 :デフォルトの名無しさん:2008/12/05(金) 13:22:41
C#4.0は動的型とジェネリック型共変反変サポートだったっけ

122 :デフォルトの名無しさん:2008/12/06(土) 23:37:08
JDK7 build41
http://download.java.net/jdk7/changes/jdk7-b41.html
http://download.java.net/jdk7/binaries/

123 :デフォルトの名無しさん:2008/12/07(日) 00:50:19
JavaFXになっても未だにmp3再生はJLayer頼りなの?
ttp://weblogs.java.net/blog/javakiddy/archive/2007/05/making_javafx_s.html

124 :デフォルトの名無しさん:2008/12/07(日) 01:49:34
JavaFXって速度はどうなの?
っていうかJavaってなんで遅いの?
ゴスリンはいまはCよりも速いとか言ってるけど、絶対遅くね?
納得のいく説明をマジ期待

125 :デフォルトの名無しさん:2008/12/07(日) 01:57:19
スレ違い

126 :デフォルトの名無しさん:2008/12/07(日) 02:13:18
>>124
Cは永遠に不滅だからねぇ

127 :デフォルトの名無しさん:2008/12/08(月) 02:14:25
起動時の速度が遅い
これは何ともできないね。常駐JVMとかできないと。
だから小さなベンチマークだとJavaは遅い。
実際・・・Jazelle入ってるARMとかで動かしてるLinuxとかで
Javaが速いプラットフォームとかあるのかな?

128 :デフォルトの名無しさん:2008/12/08(月) 03:30:07
>>124
どういう処理が遅い?

129 :デフォルトの名無しさん:2008/12/08(月) 23:02:45
>>116
http://www.getamped.jp/
Java製だったと思う。

130 :デフォルトの名無しさん:2008/12/08(月) 23:12:30
まじか。本当にそうならすごいな。
どうもインストールのとこ見るとJREのインストール促すような文章もなかったけど内包してるんかね。

131 :デフォルトの名無しさん:2008/12/08(月) 23:24:26
国産じゃないけどこんなのもあるね。

ttp://tribaltrouble2.com/

132 :デフォルトの名無しさん:2008/12/08(月) 23:30:14
今までjavaがゲームに向かないって言われてたのは、javaの精神からネイティブの個別対応に消極的だったからでしょ。
だからgcもかなりよくなってるし、ライブラリもかなりそろってるし、javaなら当たり前かなって感じはする。

133 :デフォルトの名無しさん:2008/12/09(火) 01:00:38
あれ?JInputってMacやLinuxにも対応してるのね。
これだとWebStartあたりでMMO作るのが一番楽かも知れん。
今ならサーバもクライアントもJavaでいけると思う。

134 :デフォルトの名無しさん:2008/12/09(火) 03:07:27
ベクトルユニットを使わずCPUで全部計算させていい程度のゲイムならjavaでもrubyでも実際のところ比べるほどの差はない。
ただ、無理して昔のPS1のような3D使うなら普通にクラッシュバンデブーとかの2D化とかスプライトの方がいい感じはする。

135 :デフォルトの名無しさん:2008/12/09(火) 14:13:45
微妙な違いが気持ち悪いがクラッシュバンディクーだよな?
2Dか?
http://jp.youtube.com/watch?v=buMA1evvbbI

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

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


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

138 :デフォルトの名無しさん:2008/12/09(火) 22:51:12
>ゲーム3Dは屈折とかちゃんと計算してないし

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

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

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

139 :デフォルトの名無しさん:2008/12/09(火) 22:58:14
マルチコアについてはハードを持ってないからあまり知らないけど、
gpuとかopengl/directxとかで計算を肩代わりさせるよりもよりもスレッドとマルチコアが主流になると思う。

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

140 :デフォルトの名無しさん:2008/12/09(火) 23:05:13
これ(>>138)人工無能だよ。多分。
似たようなのが前にもJava初心者スレに湧いていた。

141 :デフォルトの名無しさん:2008/12/09(火) 23:08:08
JVM自体の拡張は無いものかな?
そろそろSIMDをサポートしてもいいような気もするんだが。
JVMの命令レベルでサポートしてくれれば、標準ライブラリにも反映されるだろうし。

142 :デフォルトの名無しさん:2008/12/09(火) 23:37:07
>>140
知らない話になるとすぐ人工無能とかいっちゃうあたりは、その人工無能は君のことじゃないの?

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

144 :デフォルトの名無しさん:2008/12/09(火) 23:52:33
>>141
つ invokeDynamic

145 :デフォルトの名無しさん:2008/12/09(火) 23:58:13
>>141
そういう計画は次期JVM本流では全くないです。

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

146 :デフォルトの名無しさん:2008/12/10(水) 14:10:58
あと2−3年もすればマルチコア一色になるからダイレクトXを使いこなせるって考え方も変わるんじゃないか?
そりゃGPU使えればかなり魅力的だけど、べつにGPUの機能やライブラリを使わなくてもある程度同等ならもう十分だし。
ただ(東工大の例も考えれば)GPUは並列にしないとあまりうまみがないし、個人のPCでGPUを多段式(予算6万として3枚以上)にする人は滅多いにいないだろう。

147 :デフォルトの名無しさん:2008/12/10(水) 15:13:57
http://blogs.sun.com/darcy/entry/small_language_changes_jdk_7
http://www.jroller.com/scolebourne/entry/java_7_small_language_changes

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

148 :デフォルトの名無しさん:2008/12/11(木) 00:42:57
>>138
屈折自体を計算する必要がない?3Dグラフィックわかってる?
アニメっぽいテクスチャのべた塗りでいい?それほんとにやったらどんなしょぼいもんができるかわかってる?
バーチャファイター1だぞ。
カートゥーンレンダリングのこと言ってる?

149 :デフォルトの名無しさん:2008/12/11(木) 00:44:56
マルチコア一色?あと10年は掛かるな。
アップデートしなくちゃいけないのは人間だて。

150 :デフォルトの名無しさん:2008/12/11(木) 00:53:58
マルチコア一色?Larrabeeのことか?

151 :デフォルトの名無しさん:2008/12/11(木) 00:55:52
ゲーマーと同じ発想のようですけど、デテールにこだわるなら勝手にどぞ。
デテールにこだわるあまり3Dを熟知しているゲームPGを20人も雇うなら人件費の方が大きいよね。


152 :デフォルトの名無しさん:2008/12/11(木) 01:05:50
open glがデフォで使えるようになったのは1995-1998頃から普及しだして3年ぐらいじゃなかったか?
PCと一緒にグラフィックカードも買ってくれるようになってからだったしな。
ただライブラリが貧弱で実際プログラムする敷居は高かったけど。

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

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

153 :デフォルトの名無しさん:2008/12/11(木) 01:09:20
(Sunが真面目に取り組む気があるなら)将来的にはJOGLよりJava3Dのが速いんだろうな。

154 :デフォルトの名無しさん:2008/12/11(木) 01:34:28
JOGLよりJava3Dのが速いかどうかは、ハードの問題でライブラリ(アルゴ)はあまり関係ないんじゃないの?
それよか、自分で実装するのも面倒だし、特定ハードの機能に依存しないアルゴがあればいいよ。
遅いかもしれないけどそれは先も書いたとおり、速いか遅いかはハードの問題。この辺りは、古参兵だと今だにごっちゃなんだろうけどw


155 :デフォルトの名無しさん:2008/12/11(木) 01:43:42
抽象度が高い方がハードウェア特性を吸収しやすいってことだよ。
結局の所ソフトウェアのボトルネックは大抵が人間系だ。

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

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

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



157 :デフォルトの名無しさん:2008/12/11(木) 01:50:05
ところで >>151はゲーム作成のコスト削減の話をしてただけなのか。

158 :デフォルトの名無しさん:2008/12/11(木) 01:51:13
わかったことは、「アルゴ」なんて言葉つかうやつは、信用できないってことだな。

159 :デフォルトの名無しさん:2008/12/11(木) 02:31:58
ナルトのレンダリングってかなり高度だと思う。

160 :デフォルトの名無しさん:2008/12/11(木) 02:40:31
>>158
ALGOLの作者に謝れ!

161 :デフォルトの名無しさん:2008/12/11(木) 03:11:40
>>157-160
おまえらの相手なんかしてたからageちまったじゃないか!どうしてくれるんだよ!

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

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

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

162 :デフォルトの名無しさん:2008/12/11(木) 03:30:07
それにはJava VMの仕様の一部としてバーチャルSIMD演算器を
定義する必要があるだろう。

163 :デフォルトの名無しさん:2008/12/11(木) 05:34:41
http://weblogs.java.net/blog/alex2d/archive/2008/12/jwebpane_projec_1.html

そろそろ来るのか?

164 :デフォルトの名無しさん:2008/12/11(木) 05:36:43
>> 161
なんか、がんばって知ってる難しい単語ならべたようにしか見えない。

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

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

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

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


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

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


167 :デフォルトの名無しさん:2008/12/11(木) 05:55:51
>>164
知らない話題になると揚げ足取りに変身するのは、どの分野にもいるね。
君みたいなゴミはうん千うん万と見てきたよw

168 :デフォルトの名無しさん:2008/12/11(木) 05:58:51
>>164
昔からいるスレ主だろうけど、君は知らない話題に首を突っ込まないでエスケープ解析だけを頑張ってればいいよw

169 :デフォルトの名無しさん:2008/12/11(木) 06:05:01
>>167
受け流すヒマがあれば、合理的な反論の一つもしてみたらどうだ?

170 :デフォルトの名無しさん:2008/12/11(木) 06:05:29
>>164
人の批判をするなら
まずはアンカーぐらいちゃんと付けられるよ
うになってからじゃないの?ダサww

171 :デフォルトの名無しさん:2008/12/11(木) 06:15:29
補完とか漢字も分かってないのに批判しだして調子に乗ってるのは笑えるw
ていうかどの分野でもこういうゴミが沸いてくるから何にも教えたくなくなるよな。
こういうゴミが一つでもいると、逆にスレを徹底的に荒らす実験でもしようかと思うww
ま、スレが荒れるのも自業自得なんじゃね?ww

172 :デフォルトの名無しさん:2008/12/11(木) 06:20:27
合理的な反論とか意味分からんww
>>164を見るに、全くわかってないお子ちゃまじゃんかww
あまりのお馬鹿に笑いが止まらないし鼻くそが吹き飛んだじゃないか!

173 :デフォルトの名無しさん:2008/12/11(木) 06:24:54
>>166
リアルでは「ジャバしかやったことありませーん」とか言うレベルだろ。
だから話についていけないし、java.netのキチガイブログを読んでばかりで、次から次と最新技術の追っかけやってるしか能がない。
おまえなんか厨房レベル、つまりジャバ・アイドルの追っかけと同じだろ?ww

174 :デフォルトの名無しさん:2008/12/11(木) 06:25:43
アンカー間違えたw
>>163
早く死ね

175 :デフォルトの名無しさん:2008/12/11(木) 06:37:37
>>172
朝から顔まっかにして・・・
結局どういう補間が精度わるいか書かないし、DirectXもわけわかってないし。
連投してレス先間違えまくるほど、痛いところつかれたんだな。

176 :デフォルトの名無しさん:2008/12/11(木) 06:41:18
あまりに高度・技術な話題に、このスレの住人はついて来れないって落ちだろ。
この程度のスキルで調子に乗るなら、このスレは国内外のリソースとかブログ紹介とかの路線でいいんじゃね?


177 :デフォルトの名無しさん:2008/12/11(木) 06:48:00
頑張って難しい単語を理解しようとするのは良い心がけですが、難しい単語が理解できないからといって人のせいにするのはいけません。まず「補完」の漢字すら言われないとそのまま間違って覚えてたでしょww
人のことを「ソフト(ダイレクトX)って書いちゃうってことは、DirectXわかってないことバレバレだし」なんていってるヒマがあるなら、そういう癖はすぐに直した方がいいですよ。

178 :デフォルトの名無しさん:2008/12/11(木) 06:54:04
>>175
連衡てなんだよ。おまえはさ、妄想もいいかげんにしたらどうだ?おまえがいるとスレが荒れるだろ。


179 :デフォルトの名無しさん:2008/12/11(木) 06:55:30
>>175
補間の漢字も知らなかった奴が「書いて欲しい。分かってない」とかマヌケなことぬかすな。ゴミw

180 :デフォルトの名無しさん:2008/12/11(木) 07:14:06
人工無能君に一人芝居モードでも追加されたのか?

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

181 :デフォルトの名無しさん:2008/12/11(木) 07:24:02
>>164
>補完で繰り返し収束するようなアルゴリズムなら、ハードが速くなると解決するね。

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

182 :デフォルトの名無しさん:2008/12/11(木) 08:00:22
はい補間と補完まちがえました。スミマセン。

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

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

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

183 :デフォルトの名無しさん:2008/12/11(木) 08:09:17
アルゴリズムをちゃんと勉強したことあるなら、>>161 みたいにアルゴリズムの問題がハードが速くなったところで解決できないなどという思想は持ってないな。

184 :デフォルトの名無しさん:2008/12/11(木) 08:20:32
>>166
そういうのはJITの仕事です。

185 :デフォルトの名無しさん:2008/12/11(木) 08:21:35
ゲーム屋って近視眼の馬鹿が多いね。

186 :デフォルトの名無しさん:2008/12/11(木) 08:24:06
>>182
もしナンチャッテじゃなくて少しでも勉強したことがあるなら、そのアルゴに名前とかあるんじゃないの?
O[n log[n]]がハードの性能によってO[n]になったりすることは無いんじゃないかな。
難しい話題に飛び込んで赤っ恥をかく性格だし、ここらへんが人工無能君の限界だったかw

187 :デフォルトの名無しさん:2008/12/11(木) 08:29:48
>そうすると、ハードが遅いときに十分な精度まで求められなかったのが、ハードが速くなると繰り返しを多くして十分な精度が求めれる。

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


188 :デフォルトの名無しさん:2008/12/11(木) 08:31:00
>>182
それで、あなたの脳味噌は補完されましたか?ww

189 :デフォルトの名無しさん:2008/12/11(木) 08:39:23
所詮ゴミなんだし、いじめるのもそのへんで・・・

190 :デフォルトの名無しさん:2008/12/11(木) 08:47:07
お母さんがゲームばかりしていると馬鹿になりますって言ってました。

191 :デフォルトの名無しさん:2008/12/11(木) 09:26:50
がんばって煽ってみたけど逆に恥じかいたって落ちか。
お父さんが言ってたけど「知らないことに頭突っ込んじゃいけない」典型例だな。

192 :デフォルトの名無しさん:2008/12/11(木) 09:53:50
>>182
こういう人が他のスレで暴れてスレが荒らされるんでしょうね。
どんなにスキルが上がってもコメネケーション・スキルは中学生レベルですか。
育ちが悪く、どこにいってもいじめられてたんでしょうね・・・

193 :デフォルトの名無しさん:2008/12/11(木) 09:57:56
論理的思考力が中学生以下の大人よりましだ

194 :デフォルトの名無しさん:2008/12/11(木) 10:20:50
論理的思考力w

195 :デフォルトの名無しさん:2008/12/11(木) 10:38:32
スルー出来ないのは厨房だからw
よっぽど悔しかったんだろ?www

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

197 :デフォルトの名無しさん:2008/12/11(木) 11:44:21
マッキントッシュといっても最近の若いもんには通じません><

198 :デフォルトの名無しさん:2008/12/11(木) 12:08:30
アイマックってのはビックマックの友達か何かですか?

199 :デフォルトの名無しさん:2008/12/11(木) 13:19:19
>>198
http://ja.wikipedia.org/wiki/IMac

200 :デフォルトの名無しさん:2008/12/11(木) 13:36:46
>>186
連立方程式の解き方なら、ガウスザイデル法だろ
「有効桁(精度)とアルゴリズムの区別もついてない」って何言ってるの?
がんばってオーダーの話もちだしたようだが、精度の問題がハードの速度改善で解決できる例をあげただけだろ。定数項の問題。

201 :デフォルトの名無しさん:2008/12/11(木) 14:32:06
>>136 が単純なCGの例としてあげてるのであろうナルトのムービー見たらかなり高度なCGで、PS3のCellじゃないとできないような負荷がかかっていそうで笑った。

202 :デフォルトの名無しさん:2008/12/11(木) 23:15:05
>>200
がんばって勉強したみたいだね。
おこちゃまは早くおうちに帰りなw

203 :デフォルトの名無しさん:2008/12/11(木) 23:18:52
>>200
端点の近くで大きく振動する補間関数といわれてすぐ思いつかないならモグリだな。
おまえも大恥かきに来たんだろ?w

204 :デフォルトの名無しさん:2008/12/11(木) 23:21:51
ここ何のスレだっけ?

205 :デフォルトの名無しさん:2008/12/11(木) 23:26:45
いまだにアルゴの話で負けて悔しがッてる奴がいるんだろ。
どうせ一日中wiki読んで勉強でもしてたんじゃないか(笑)
>>201とかみても妄想癖強そうだし、こいつの人生は一生負け組w

206 :デフォルトの名無しさん:2008/12/11(木) 23:28:19
そもそも連立方程式とかいいだしてる辺りから分かってないよねw

207 :デフォルトの名無しさん:2008/12/11(木) 23:29:20
同じ奴が何度もレスしてファビョってるだけだな
そろそろ正常化したいんでよそでやってくれ

208 :デフォルトの名無しさん:2008/12/11(木) 23:30:59
なんか、「ドンキホーテ」って感じだよね。どの板(分野)にもいるんだろうけど。
負け組みに人はどんなにスキルが向上してもやっぱり負け組みなのかw

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

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

210 :デフォルトの名無しさん:2008/12/11(木) 23:36:16
次世代Javaの話題なんてこのスレはやってないじゃん。
ただの英語ブログの紹介でしょ。サルでも出来るw

211 :デフォルトの名無しさん:2008/12/11(木) 23:37:40
哀れな男だ

212 :デフォルトの名無しさん:2008/12/11(木) 23:39:15
「補完」も知らなければ「連立方程式」を持ち出したりして、頑張って食いつこうとしてるだけの厨房だったか。厨房なのに変な自尊心があるんだろ。無能のクセにw

213 :デフォルトの名無しさん:2008/12/11(木) 23:39:19
>>209
文脈で検出ってできるのかね? 積和が連続してるっぽかったら変換とか?

214 :デフォルトの名無しさん:2008/12/11(木) 23:42:57
ゴスリングも指摘してたが未だに1.4.2とか使って、
Java5以降の構文が使えない環境とか今後どうなるんだ?
SE for Businessとか契約する日本の企業なんてほとんどいないだろ

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

216 :デフォルトの名無しさん:2008/12/11(木) 23:57:28
>>213
分岐命令が入らないで積和が連続している部分を見つけられれば、SIMD命令への変換はできそう。
ただ、for文の積和をSIMD化しようとすると、ループアンロールをかけないとマッチングしないような気がする。

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

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

217 :デフォルトの名無しさん:2008/12/12(金) 00:00:14
>>214
1.4.2なコードなんてゴロゴロしてるよ。
つか、俺はまだ5.0以降が使われてる仕事のコードは見たことがない……。orz

218 :デフォルトの名無しさん:2008/12/12(金) 00:01:06
>気がする

ってなんだよw

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

219 :デフォルトの名無しさん:2008/12/12(金) 00:02:34
>>217
自分はホビープログラマだけど、5.0から生産性が一気に上がった気がするけどなあ…
(特にジェネリクス関係とか)
業務用では使われてないとすればもったいない話だ。

220 :デフォルトの名無しさん:2008/12/12(金) 00:05:58
>>216
この程度でいきがってるしな・・・
ちょっと知ってる程度で突っ込みいれると恥じかきますよ
財務の話とかも全然しらないんでしょうにw

それよか、他の有用な技術的リソースないですか?(日・英)

221 :デフォルトの名無しさん:2008/12/12(金) 00:08:33
>>219
まぁ、今後は5.0以降を使うことが確定してるけどな。6.0には行けないけど。
問題はなかなか仕事が取れないことでな……。orz

222 :デフォルトの名無しさん:2008/12/12(金) 00:13:21
>>217
俺は次の案件でJava6使ってくるぜ!
会社にJavaの資産が殆どないから気楽なもんだ。

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

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

224 :デフォルトの名無しさん:2008/12/12(金) 00:29:14
クロージャはあってもなくても大して生産性は変わらないかな。
リスナとかComparatorみたいな委譲用のクラスは昔からあるんだし。

225 :デフォルトの名無しさん:2008/12/12(金) 00:30:23
jdk1.2でも1.5でも動くし全く同じ性能なわけで、1.5やgenericsを強制させる必要もないんじゃない?
早く移行してくれって言うゴスリン大先生の意見も十分わかるが、おれは君ほどゴスリン大先生のシンパではない

226 :デフォルトの名無しさん:2008/12/12(金) 00:33:15
ブログネタしか投下できないんじゃ、その程度(権威主義)が限界だろ。
所詮タイマー付き人工無能だし

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

227 :デフォルトの名無しさん:2008/12/12(金) 00:35:53
この板にも、ID表示が欲しいところだな

228 :デフォルトの名無しさん:2008/12/12(金) 00:36:55
出す出す詐欺ならぬ出さない出さないツンデレなSunは、
6u11に合わせて1.3のアップデートを出したりようと分からんけどねw

229 :デフォルトの名無しさん:2008/12/12(金) 00:38:49
>5.0から生産性が一気に上がった気がするけどなあ…

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

230 :デフォルトの名無しさん:2008/12/12(金) 00:41:32
>>228
そもそも6u10とか、アップデートと思わせといて大改造だったしな。
Java6からマイナーバージョンが消えたけど、6.1とか6.5と名乗ってもいいくらいだ。

231 :デフォルトの名無しさん:2008/12/12(金) 00:42:27
確かに生産性が上がるんなら大部分のプロジェクトは1.5に移行してもいいし、おかしいよなw
マーケティング上(文系w)の宣伝文句に騙されてるだけじゃないの?

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

233 :デフォルトの名無しさん:2008/12/12(金) 00:51:10
>>232 はなにをいきがってるんだ?
基本的な連立方程式アルゴリズムも知らずに>>182書いちゃって、恥ずかしくてファビョってんのか。
連投、自作自演してバレてないと思ってるんだろうか?

234 :デフォルトの名無しさん:2008/12/12(金) 00:57:13
ん?アノテーションとか使い出してから生産性は普通に上がってるけど。

235 :デフォルトの名無しさん:2008/12/12(金) 01:07:21
>>225
可読性がまるで違う。ジェネリクスのないコレクション使いまくりのソースを追っかけるのがどれだけ大変か。
結局PC上じゃ追い切れずに、印刷して赤ペン持って机上で解析したさ……。

236 :デフォルトの名無しさん:2008/12/12(金) 01:11:30
>>209
SSE命令は1.4.2からHotspotコンパイラが利用してますよ。
JVMの起動オプションすらろくに設定したことない人?
このスレにはまだ早いのでは?

237 :デフォルトの名無しさん:2008/12/12(金) 01:50:10
最初の一行だけでいいのに。
なんで余計な言葉付け足すかなー

238 :デフォルトの名無しさん:2008/12/12(金) 01:57:06
>>237
おまえが無能だからだろw

239 :デフォルトの名無しさん:2008/12/12(金) 02:01:10
アノテーションは便利ですけど、コードの保守ですよね?
プロジェクトもせいぜい2−3年程度ならいらない感じですけど、
ドキュメント化すればいい程度ならアノテーションは不要だし、それによってどういう生産性が上がるんですか?

240 :デフォルトの名無しさん:2008/12/12(金) 02:01:35
>>171
>こういうゴミが一つでもいると、逆にスレを徹底的に荒らす実験でもしようかと思うww
>ま、スレが荒れるのも自業自得なんじゃね?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

241 :デフォルトの名無しさん:2008/12/12(金) 02:02:14
自分の無能さをわかってないから世の中が無能に見える典型だな。

242 :デフォルトの名無しさん:2008/12/12(金) 02:03:16
>>235
たぶんあなたはOOやUMLとかの近代手法的を使ったプログラミングの設計には向いてないんじゃないですか?
あなたの脳内は未だにフローチャットの延長か何かの旧式のままなんでしょうけどw

243 :デフォルトの名無しさん:2008/12/12(金) 02:06:40
>>239
XMLの記述が減る。
短いプロジェクトなら、記述量が減るのはうれしいだろ。
Javaで宣言的なコードがまがりなりに書けるというのはいい。

244 :デフォルトの名無しさん:2008/12/12(金) 02:07:57
>>240
その「アルゴ君」とはあなたのことじゃないんですか?w
いい歳して、恥さらしするのもいいかげんにしなさい

245 :デフォルトの名無しさん:2008/12/12(金) 02:11:46
>>240
ここでは収束する計算の例としてガウスザイデル法を使いました。

246 :デフォルトの名無しさん:2008/12/12(金) 02:14:03
>>240,241
あなたは確かに無能のようですね。
多少スキルがあるみたいですけど、せいぜい中級車って程度ですよw

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

247 :デフォルトの名無しさん:2008/12/12(金) 02:15:01
>>182は人口無能君ww

248 :デフォルトの名無しさん:2008/12/12(金) 02:17:40
>>240
てか、あんたいいかげんウザイよ
なんか説教してるようだけどまた漢字間違えてるし、高度な知識があるわけでもないくせにいいかげんその高慢な態度を改めた方がいいんじゃないですか?

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

249 :デフォルトの名無しさん:2008/12/12(金) 02:19:24
>>246-248
同一人物だろ。かまってちゃんか

250 :デフォルトの名無しさん:2008/12/12(金) 02:24:25
風紀委員長が女便所に常任していると聞いてやって来ました!

251 :デフォルトの名無しさん:2008/12/12(金) 02:27:46
>>236
> JVMの起動オプションすらろくに設定したことない人?

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

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

252 :デフォルトの名無しさん:2008/12/12(金) 02:27:53
海外のブログだとそういうアホ記事が多いよね
英語でかいてあるから、それも大事な部分が砕けた英語だったりするとなおさら日本人だと分かり辛いんだけど
そういうアホ記事に洗脳されちゃう人なんじゃないの?根っからの理系とかw

253 :デフォルトの名無しさん:2008/12/12(金) 02:30:25
>>251
切れたorz
何をどう使ってるのか、という情報も見つからないんだよね。

254 :デフォルトの名無しさん:2008/12/12(金) 02:31:20
>>252
だなw

255 :デフォルトの名無しさん:2008/12/12(金) 02:33:20
>>252>>254 のような自作自演、前も見たな。

256 :デフォルトの名無しさん:2008/12/12(金) 02:35:51
>>255がどんどんとこのスレの主になっていく件について?

257 :デフォルトの名無しさん:2008/12/12(金) 07:12:11
>>240
そもそも、ageで煽って回ってる人は何をしたいのかわからん。
他の人の書き込みを煽るだけで、話題を提供しようとしてるわけでもないし。

258 :デフォルトの名無しさん:2008/12/12(金) 07:44:28
http://hamletdarcy.blogspot.com/2008/12/java-7-update-from-mark-reinhold-at.html

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

259 :デフォルトの名無しさん:2008/12/12(金) 07:47:04
演算子オーバーロードは未来永劫Javaに入ることはないんじゃなかったっけ?

260 :デフォルトの名無しさん:2008/12/12(金) 08:14:19
Multi catch (yes!)
null checks (yes!)
とかいってる奴のブログなんか紹介するんな。キモイ。
それにjdk1.7は1年半も先だし、上で指摘されたばっかりなのにおまえは洗脳されやすいんだなw

261 :デフォルトの名無しさん:2008/12/12(金) 08:22:06
>>258
Java7があと1年遅れればそのへんも復活するかもよ

262 :デフォルトの名無しさん:2008/12/12(金) 08:41:29
>>257-259
提供してみた話題は叩かれるし、それでも我慢してスレに張り付いてるのはよっぽどヒマ人なんですねw


263 :デフォルトの名無しさん:2008/12/12(金) 08:46:50
indexerも入んないの?

264 :デフォルトの名無しさん:2008/12/12(金) 09:03:40
closure 要らんから、せめて function type だけでもくれ。

265 :デフォルトの名無しさん:2008/12/12(金) 09:18:49
アップデートとブログ紹介しか出来ない人工無能に、ヒマ人とか直接言っちゃったらかわいそうだろ。

266 :デフォルトの名無しさん:2008/12/12(金) 09:20:26
>>263
そもそも入るなんて話あったの?

267 :デフォルトの名無しさん:2008/12/12(金) 09:31:02
aheのウィッシュリストにはあった

268 :デフォルトの名無しさん:2008/12/12(金) 10:42:36
なんだ。ただミーハーだったのかw

269 :デフォルトの名無しさん:2008/12/12(金) 10:49:58
indexerや演算子オーバーロード付けるくらいならもうjava言語捨ててC#準処にするべき

270 :デフォルトの名無しさん:2008/12/12(金) 10:54:12
そういう考え方もあってもいいけどね

271 :デフォルトの名無しさん:2008/12/12(金) 11:15:43
javaVMで動くC#を

272 :デフォルトの名無しさん:2008/12/12(金) 11:26:44
逆だろ。.Netに手軽にアクセスできるjvm (java)。

273 :デフォルトの名無しさん:2008/12/12(金) 11:35:46
そっちの方はScalaが頑張ってるね

274 :デフォルトの名無しさん:2008/12/12(金) 11:59:55
ほんとか!で.Netで動くScalaじゃ意味ないよな。結局やってることはjrubyと同じだし。

275 :デフォルトの名無しさん:2008/12/12(金) 16:17:20
>>267
ウェブ・ブックマークのネタはもう切れたんですか?w

276 :デフォルトの名無しさん:2008/12/12(金) 17:59:10
BigDecimal シンタックスの話なんてあったのか。欲しかった

277 :デフォルトの名無しさん:2008/12/12(金) 18:02:53
なかったと思う

278 :デフォルトの名無しさん:2008/12/12(金) 18:32:19
演算子オーバーロードの文脈の中で
ユーザ側で自由に定義できる演算子オーバーロードはダメだけど
BigDecimalなんかは特別扱いで演算子使えるようにしようかって話はあった。

279 :デフォルトの名無しさん:2008/12/12(金) 18:47:26
さすが、JAVAのことなら隅々まで追いかけてますねw

280 :デフォルトの名無しさん:2008/12/12(金) 19:18:57
前スレか前々スレあたりで出てたと思ったが。

281 :デフォルトの名無しさん:2008/12/12(金) 19:24:10
>>276
http://blogs.sun.com/dannycoward/resource/Java7Overview_Prague_JUG.pdf
の 28枚目あたりにある。

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

282 :デフォルトの名無しさん:2008/12/12(金) 20:28:18
multi catch って型の扱いどうなるんだろ?
ExceptionA extends Exception { public void method(){} }
ExceptionB extends Exception { public void method(){} }
catch (ExceptionA | ExceptionB ex) で ex.method() 呼べたら面白いけど
たぶん無理だろうなぁ。

283 :デフォルトの名無しさん:2008/12/12(金) 20:39:33
インデクサってか演算子オーバーロードの類は要りません。
もちろんプロパティとかも要りません。
メタプログラミングをこれ以上推奨しないでくれ。

284 :デフォルトの名無しさん:2008/12/12(金) 20:43:29
>>282
無理だろうな
使えるのThrowableのメソッドだけだろ

285 :デフォルトの名無しさん:2008/12/12(金) 20:57:41
Javaってgetほにゃららとかsetほにゃららとかやり続ける気なの?
馬鹿馬鹿しくならない?

286 :デフォルトの名無しさん:2008/12/12(金) 21:14:48
>>284
Throwableだけに制限する必要は無いでしょ。一般には
Exception1,Exception2,...ExceptionNの共通のスーパークラスを計算できるはずだから
そのスーパークラスのメソッドは呼び出せるようにすればOK

287 :デフォルトの名無しさん:2008/12/12(金) 21:55:48
>>283
そんなものはメタプログラミングでも何でもない。

288 :デフォルトの名無しさん:2008/12/13(土) 00:27:37
>>285
言語仕様を次々と拡張されるよりはマシ

289 :デフォルトの名無しさん:2008/12/13(土) 00:49:16
>>272
IKVMどうだ?
http://www.ikvm.net/

290 :デフォルトの名無しさん:2008/12/13(土) 02:54:50
>>289
そんなのあるのか。
普通に想像できることは他の人が既にやってるよな。

291 :デフォルトの名無しさん:2008/12/13(土) 22:01:08
JavaFXってJCPで管理されてる仕様ではないよね?
Java7でクロージャ導入して、FX向けのアノテーションもバリバリサポートしてくれないかなぁ。

292 :デフォルトの名無しさん:2008/12/14(日) 01:50:12
JavaFXは結構はまるよね。プロパティ設定のコード書くのも楽だしIDEいらないぐらい。
コーデックとかメディアプレヤァに力入れてるけど、2.0になったら3Dとかもやるのかな?

293 :デフォルトの名無しさん:2008/12/21(日) 16:31:03
JDK7 build42
http://download.java.net/jdk7/changes/jdk7-b42.html
http://download.java.net/jdk7/binaries/

294 :デフォルトの名無しさん:2008/12/23(火) 19:13:19
で、Java7でのマルチコア対応ってどうなってるの?
並列APIはできてるし、後はJVMレベルでどれくらい対応するんだろう?

現状は放置?

295 :デフォルトの名無しさん:2008/12/23(火) 19:31:36
>>294
どんな機能を期待してるの?
単にスレッドが各コアに分散されることを期待してるだけなら、1.3か1.4
あたりからネイティブスレッド対応なので、既に対応済みとも言えるが。

296 :デフォルトの名無しさん:2008/12/23(火) 21:43:35
コンパイラで並列化した中間コードを吐けるようにしてくれ

297 :デフォルトの名無しさん:2008/12/23(火) 21:44:56
>>296
必要ないです。

298 :デフォルトの名無しさん:2008/12/23(火) 21:55:27
>>297
なんで?
あったら便利にならんかね?

299 :デフォルトの名無しさん:2008/12/23(火) 22:00:12
普通に書いたプログラムを自動で解析してなんとか並列化してくれ

300 :デフォルトの名無しさん:2008/12/23(火) 22:02:45
んじゃあMVMだな
これが出来ればマルチコア対策になるんだが、無理そうだよね

301 :デフォルトの名無しさん:2008/12/23(火) 22:47:20
>>298
コンパイラじゃなくてVMの仕事です。

302 :デフォルトの名無しさん:2008/12/23(火) 22:47:51
すまんが>>300の理屈が理解できないので詳しく教えて欲しい。
結局、マルチコア対応を行わなければ、MVMで合っても並列処理できなくね?
MVMでもネイティブスレットレベルでしか並列化できないような気がするんだが。

303 :デフォルトの名無しさん:2008/12/23(火) 23:24:57
>>300
MVMがマルチコア対策になる理由がわからない。
メモリ等のリソース効率はともかく、CPUの利用という意味では、
複数VMを立ち上げるのとそう変わらないのでは?
それとも俺が何か勘違いしてる?



304 :デフォルトの名無しさん:2008/12/23(火) 23:35:35
MVMのおかげで僕にも彼女g

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


306 :デフォルトの名無しさん:2008/12/23(火) 23:53:20
あきらめろ
MVMはJNIがあるかぎり実現は出来ない
絶対に、だ

307 :デフォルトの名無しさん:2008/12/23(火) 23:57:40
>>305
それって>>299の要求してるモノなの?

308 :305:2008/12/24(水) 00:08:26
>>299に返事してません

309 :デフォルトの名無しさん:2008/12/24(水) 00:18:58
排他制御の効率化なんてMVM以外でもやってんだろ

310 :デフォルトの名無しさん:2008/12/24(水) 02:28:10
http://www.infoq.com/jp/articles/java-threading-optimizations-p1

311 :デフォルトの名無しさん:2008/12/24(水) 02:41:00
>>306
MVMを利用する条件にJNIの利用禁止をつければよくね?
SingleVMも生かしておけばいいと思うんだが。

312 :デフォルトの名無しさん:2008/12/24(水) 06:53:43
MVM-lite という項目はある。maybe付きだが
http://java.dzone.com/articles/java-7-update-mark-reinhold-de

313 :デフォルトの名無しさん:2008/12/31(水) 03:08:19
SwingFreamworkが入らないかもしれない、というだけで幻滅した

314 :デフォルトの名無しさん:2008/12/31(水) 07:24:53
>>310
全然役にたたねえなこの記事ww

315 :デフォルトの名無しさん:2008/12/31(水) 08:38:18
>>313
swingはいらない子
遅いし、遅い

316 :デフォルトの名無しさん:2008/12/31(水) 17:13:53
Swingはやればできる子。WinFormsなんかにくらべるとよっぽど筋がいい。
でもSwingFrameworkは、使いにくいからいらないです。

317 : 【吉】 【447円】 :2009/01/01(木) 08:51:50
おみくじ

318 : 【中吉】 【1973円】 :2009/01/01(木) 12:22:26
てst

319 :デフォルトの名無しさん:2009/01/01(木) 23:15:38
で、delegateは入らないの?
lambdaは?

320 :デフォルトの名無しさん:2009/01/02(金) 00:01:09
delegate気持ち悪くない?
eclipse使えば一発で挿入してくれるしいらんわー

321 :デフォルトの名無しさん:2009/01/02(金) 00:04:19
これだからIDE使っての開発しかした事のない奴は。。。

322 :デフォルトの名無しさん:2009/01/02(金) 00:08:03
IDEじゃなくてもそんなもんPGなら挿入してくれるようなのつくっときゃいいっしょ

323 :デフォルトの名無しさん:2009/01/02(金) 00:09:46
今どきIDE使わない環境なんてあるの?

324 :デフォルトの名無しさん:2009/01/02(金) 00:15:30
>>323
つ 現場によりけりでない場所もある

325 :デフォルトの名無しさん:2009/01/02(金) 00:39:00
で、delegateは入らないの?
lambdaは?

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

326 :デフォルトの名無しさん:2009/01/02(金) 01:24:37
JVMのモジュール化のほうが先だと思うんだよなぁ・・・


327 :デフォルトの名無しさん:2009/01/02(金) 01:53:39
もうめんどくせえからScala使っちまえよ

328 :デフォルトの名無しさん:2009/01/02(金) 03:34:14
一番簡単なのはdelegateとlambdaを金輪際使わなければ良いんだよ☆

329 :デフォルトの名無しさん:2009/01/02(金) 03:36:21
もうレガシーとして余生を送れよ

330 :デフォルトの名無しさん:2009/01/02(金) 06:27:49
swingに限らないが、もうちょっと速くならないだろうか
そういえば、似たようなことしてるのに、.NETは速いのはなんでかね??

331 :デフォルトの名無しさん:2009/01/02(金) 16:42:55
言語仕様がクソすぎてIDE無しじゃとてもプログラミングできない。

332 :デフォルトの名無しさん:2009/01/02(金) 18:12:45
例えばどこらへんの仕様?

333 :デフォルトの名無しさん:2009/01/02(金) 18:14:41
イベントリスナとかイベントリスナとか

334 :デフォルトの名無しさん:2009/01/02(金) 18:51:29
イベントリスナは言語仕様じゃなくて標準ライブラリの部分だろ
イベントリスナというモデルを採用せざるを得なかった言語仕様が糞だというのなら
話はわかるが。個人的には最初からクロージャがあってそれをベースにした
イベントモデルになってたら良かったなあと思う

335 :デフォルトの名無しさん:2009/01/02(金) 19:22:16

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

336 :デフォルトの名無しさん:2009/01/02(金) 21:42:52
関数型もラムダ式もないからイベントリスナが必要になり
無名内部クラスなんていう全くシンプルでも便利でもない
ウンコみたいなものに頼らざるを得なくなった

337 :デフォルトの名無しさん:2009/01/02(金) 22:17:14
関数型は欲しい。
Generics入れるときにいじったんだから、そこで入れちゃえば良かったんだ

338 :デフォルトの名無しさん:2009/01/02(金) 23:23:23
そうするとポインタ型も導入するか。

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

339 :デフォルトの名無しさん:2009/01/02(金) 23:40:38
>>338
アドレスってGCの世代管理で変化するんじゃないの?

340 :デフォルトの名無しさん:2009/01/03(土) 00:07:23
そりゃ機能を追加すりゃあ、その部分については便利になるだろうが、
なんでもかんでも追加すりゃいいってもんじゃないよな。
言語仕様に手を入れるなんて、不便でどうしようもない部分を直す
程度でいいよ。
新しいパラダイムを使ってみたいだけなら、Scalaでもなんでもあるし。

341 :デフォルトの名無しさん:2009/01/03(土) 00:15:54
また麻布か・・・

342 :デフォルトの名無しさん:2009/01/03(土) 08:34:32
まぁC++よりはずいぶんマシな言語だからな
正直言語使用としてこれ以上必要なものはないわ
後はJVMのほうの改良ぐらいじゃねーの?

343 :デフォルトの名無しさん:2009/01/04(日) 08:07:21
結局、JAVAは別の言語の実行環境などの役割にシフトして行くだろう
JAVAに替わるものが出ない間は



344 :デフォルトの名無しさん:2009/01/06(火) 02:55:57
>>338
「難しい、理解できない」ではなくて、「正しく動くことを保証するのが難しい」だろが。

345 :デフォルトの名無しさん:2009/01/06(火) 02:56:44
関数型はいらない。
クロージャーが欲しい

346 :デフォルトの名無しさん:2009/01/06(火) 05:50:25
関数型なしでクロージャをどこに入れとけばいいんだ

347 :デフォルトの名無しさん:2009/01/06(火) 11:56:54
匿名クラスにローカル変数を取り込めるようにするとか
例の{int, int => int}よりはマシな気がする

348 :デフォルトの名無しさん:2009/01/07(水) 16:50:46
evalが欲しい

349 :デフォルトの名無しさん:2009/01/07(水) 17:58:08
evalは流石に・・・

350 :デフォルトの名無しさん:2009/01/07(水) 18:37:39
evalするならGroovyでいいじゃないか

351 :デフォルトの名無しさん:2009/01/07(水) 19:42:31
Rhinoのこともたまには思い出してください。

352 :デフォルトの名無しさん:2009/01/07(水) 23:38:35
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イベント関係のメソッドをまとめて記述
}
}

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

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

353 :デフォルトの名無しさん:2009/01/07(水) 23:52:18
イベントに対する処理をクロージャで書くべきではないのは同意だけど,クラスは無くていいよね
メソッドをそのままオブジェクトとして渡せれば一番わかりやすい
まとめてインターフェイスにしてるとイベントを後で追加するときに困るし

354 :デフォルトの名無しさん:2009/01/08(木) 00:02:59
>>348
つjavax.script API
対応言語の一つに「Java」がある:-)

355 :デフォルトの名無しさん:2009/01/08(木) 00:15:14
ボタンをポチッと押したら変数aの値をインクリメントしたいだけなのに〜
って場合には、簡易な記法でクロージャーを使えると有り難い。

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

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

356 :デフォルトの名無しさん:2009/01/08(木) 00:20:44
>>355
> ググッとソースを下にスクロールしないと

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

357 :デフォルトの名無しさん:2009/01/08(木) 00:48:49
>>355
>ボタンをポチッと押したら変数aの値をインクリメントしたいだけなのに〜
>って場合には、簡易な記法でクロージャーを使えると有り難い。

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

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

358 :デフォルトの名無しさん:2009/01/08(木) 01:36:41
今な享楽に生きる大雑把な自分は、やっぱりクロージャ欲しい。

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

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

359 :デフォルトの名無しさん:2009/01/08(木) 02:32:11
クロージャの主な用途は
コレクションに対して一気に処理を適用したり
Openした後自動的にCloseするようにしたりといった
メソッドを引数として与えることで再利用を促進することだよ

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

361 :デフォルトの名無しさん:2009/01/08(木) 02:47:41
>>359
javascriptにある onClick= ってのは魅力的じゃないか?
コレクションていうのも分かるんだけど、Cで言えばqsortに関数ポインタ渡すのとやってることは大して差はないし。

362 :デフォルトの名無しさん:2009/01/08(木) 03:11:50
>>359
両方とも無名クラスでも出来るんじゃないかい。

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

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

363 :デフォルトの名無しさん:2009/01/08(木) 04:43:56
>>362
何を言いたいのか意味が分からないんだけど
ただ短く書きたいだけってならsetter/getterのプロパティ表記と同じことじゃないの?w
MartinFowlerの見解なんかも、君の脳味噌じゃ理解できなかったようだ(笑)

364 :デフォルトの名無しさん:2009/01/08(木) 08:06:36
swing関連のフレームワークが欲しいが、それはベンダが提供すれば言い話だしな・・・
sunが提供してNetBeansに組み込んでくれないかな〜
そうすればMFCのようにデファクトになるのに

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



365 :デフォルトの名無しさん:2009/01/08(木) 08:39:26
>>364
Swing Application Frameworkは、すでにsunが提供してNetBeansに組み込まれてるわけで
クロージャーなくて困らないのはクロージャーつかったことないからじゃないのかな。

366 :デフォルトの名無しさん:2009/01/08(木) 11:27:53
>>364
swingがGUIのフレームワークなわけで、既にjdk 1.2で取り込まれて、デファクトになってるがそれでも不満か?wq

367 :デフォルトの名無しさん:2009/01/08(木) 11:45:08
フレームワークは玉葱の皮のような状態だからね〜

368 :デフォルトの名無しさん:2009/01/08(木) 21:04:03
ネイティブコードでコンパイルできるようにならんかねぇ

369 :デフォルトの名無しさん:2009/01/08(木) 23:15:57
>>365
おんなじJavaを使っても、クロージャを使ったことがある人は困って、
使ったことがない人は困らない?
そりゃ変な理屈だろう。

370 :デフォルトの名無しさん:2009/01/08(木) 23:19:38
携帯電話のない世界に住む人が携帯電話がなくて困るわけがないだろう

371 :デフォルトの名無しさん:2009/01/09(金) 00:00:27
クロージャのない言語はクソ

372 :デフォルトの名無しさん:2009/01/09(金) 00:05:46
Control invocation syntax 萌え
ビバ、BGAA!



373 :デフォルトの名無しさん:2009/01/09(金) 01:56:22
>>369-370
今日のベストアンサー賞

374 :デフォルトの名無しさん:2009/01/09(金) 22:16:10
しかしJavaが和暦に対応したばっかりなのにもう平成が終わりそうだよ!

375 :デフォルトの名無しさん:2009/01/09(金) 23:45:01
でも、携帯電話があったらなぁ、と夢想はする。

376 :デフォルトの名無しさん:2009/01/10(土) 02:22:33
>>370
それはクロージャが携帯電話みたいに一度使ったら手放せないほど
便利だという前提での話だね。
アマチュア無線だったらまぁ、あれば便利なんだろうけど、それがない
世界に行っても俺は困らないや。

377 :デフォルトの名無しさん:2009/01/10(土) 06:01:33
クロージャーは便利だね。一度クロージャーがある環境になれると、クロージャーなしの環境は不便。
クロージャーがある環境というのは、文法がクロージャーに対応してるだけじゃなくて、ライブラリもクロージャー前提になってるのな。

378 :デフォルトの名無しさん:2009/01/10(土) 07:48:37
クロージャがあれば苦労しなくて済む

379 :デフォルトの名無しさん:2009/01/10(土) 08:09:06
クロージャはJavaFx Scriptで使えるから暫くはこれで遊んでいよう。

380 :デフォルトの名無しさん:2009/01/10(土) 08:23:56
しかし、
クロージャは入らない

残念w

381 :デフォルトの名無しさん:2009/01/10(土) 10:07:36
java7は地味なリリースになりそうだな・・・
目新しいのはJAMぐらい?

382 :デフォルトの名無しさん:2009/01/10(土) 12:40:04
クロージャって便利何だけど、今のjavaに自然に含める文法を考えるのが相当難しいんだよな。
正直 => みたいな文字が入るぐらいなら無いほうがマシって気にもなる。

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

383 :デフォルトの名無しさん:2009/01/10(土) 12:49:50
クロージャでクロー知らずジャ

384 :デフォルトの名無しさん:2009/01/10(土) 13:16:59
button.Click += (sender, e) => {
 var averageAge = persons.Where(p => p.Sex == local_Sex).Select(p => p.Age).Average();
 MessageBox.Show(averageAge.ToString());
}
今のC#なんかこんなことになってるからなw

385 :デフォルトの名無しさん:2009/01/10(土) 13:26:04
やっぱり
+=
これにはとても抵抗があるな。パッとみ、Clickの回数を+=するとも見えるし、
オーバーロードと分かっていても抵抗がある。

386 :デフォルトの名無しさん:2009/01/10(土) 13:28:32
ただ、こういうの(簡略表記というか)はjavafxの方に流れてるからなぁ。

387 :デフォルトの名無しさん:2009/01/10(土) 13:30:10
>>385
オーバーロードは違うな
プロパティと一緒だよ
プロパティに=を使ったらgetter/setterアクセサメソッドの呼び出しになるでしょ
それと同様に,+=はaddアクセサ,-=はremoveアクセサの呼び出し

388 :デフォルトの名無しさん:2009/01/10(土) 13:48:08
javafxだとイベント系の処理はクロージャよりbindで済ませることが多いかな。

389 :デフォルトの名無しさん:2009/01/10(土) 14:30:06
今落ち着いて考えると、
ジェネリクスはいらなかったと思うんだ

390 :デフォルトの名無しさん:2009/01/10(土) 14:32:43
いやさすがにそれはない

391 :デフォルトの名無しさん:2009/01/10(土) 14:34:09
ワイルドカードはいらなかった

392 :デフォルトの名無しさん:2009/01/10(土) 14:35:37
ジェネリクスをイレージャタイプにしてしまったのは拙速だったとはいわれてるね。

393 :デフォルトの名無しさん:2009/01/10(土) 15:24:14
VMの互換性の重視と
必要ないって意見に配慮して穏健なものにしたからだろうね。

394 :デフォルトの名無しさん:2009/01/10(土) 16:28:34
GenericsはC++のテンプレートと全く違うんだけど?
違いが分からないなら使わない方がいいよ。どうせ「長くて可読性が」どうとかこうとかなんでしょ

395 :デフォルトの名無しさん:2009/01/10(土) 16:44:00
ランタイムサポートされたGenericsの世界を知らないの?
C#なら型やメソッドを型パラメータごとに動的生成したりnew T()とかできるんだぜ

396 :デフォルトの名無しさん:2009/01/10(土) 16:57:07
Mbeanをもっと作りやすくしろ


397 :デフォルトの名無しさん:2009/01/10(土) 17:06:06
>>394
なに頓珍漢なこと言ってるんだ。
イレージャタイプって意味も分かってないのか。

398 :デフォルトの名無しさん:2009/01/10(土) 17:24:44
Googleで検索しても実質0件だがなあ

399 :デフォルトの名無しさん:2009/01/10(土) 18:11:20
『「実質0件」でぐぐって50件くらいしかないから「実質0件」という日本語はあまり使われていない』
というのと似たようなものだな

400 :デフォルトの名無しさん:2009/01/10(土) 18:12:10
ググっても意味がわかんなかったといっておる

401 :デフォルトの名無しさん:2009/01/10(土) 18:17:33
英語分からない人は、こういうこと知る機会は制限されてるでしょ。


402 :デフォルトの名無しさん:2009/01/10(土) 18:22:15
Type Erasure(型消去)ってことね
イレージャタイプじゃでてこんわね

403 :デフォルトの名無しさん:2009/01/10(土) 19:04:53
>>397
それなら、イレージャタイプから消えた方情報(クラスなど)を動的に知る方法を教えてくれませんか?

404 :デフォルトの名無しさん:2009/01/10(土) 19:10:18
erasure形式っていうことじゃねぇの?

405 :デフォルトの名無しさん:2009/01/10(土) 19:11:18
>>403 は子供みたいなこと言ってるし、これは荒れるな

406 :デフォルトの名無しさん:2009/01/11(日) 00:24:41
互換性との兼ね合いでこうなりました、終了。でいいじゃん。
new T()はできないけど、
T newInstance(Class<T> cls) { return cls.newInstance(); }
で実用上困らないし。

407 :デフォルトの名無しさん:2009/01/11(日) 00:31:51
>>406
T.classとかできないからそのgenericクラスorメソッドから
そのメソッド呼ぶのが難しい
どこか(大抵はコンストラクタか)でClassオブジェクトもらわんと

408 :デフォルトの名無しさん:2009/01/11(日) 00:37:56
>>392
Genericsも寸止めあったぞ。拙「速」ではなかった。
しかしすごい残尿感が今でもある。

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

409 :デフォルトの名無しさん:2009/01/11(日) 01:39:07
リアルで残尿感が・・・寄る年波(泣

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


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


411 :デフォルトの名無しさん:2009/01/11(日) 05:20:26
だから、C++のテンプレートとは全く違うっていってんでしょ。
>>405-407

412 :デフォルトの名無しさん:2009/01/11(日) 05:22:38
クロージャやプロパティや実体を持ったジェネリックがC#にはあるでな

413 :デフォルトの名無しさん:2009/01/11(日) 05:29:39
>>411
誰がC++と比べてるんだ?

414 :デフォルトの名無しさん:2009/01/11(日) 08:45:01
>>408
BGGAのGの一つはゴスリンのGだぞ。

415 :デフォルトの名無しさん:2009/01/11(日) 08:56:34
closureのためにC#に行くのは癪だからjavafxで暫く様子見かな。
/* * save usdkrw.fx
javafxc usdkrw.fx
javafx usdkrw
*/
function getfuncs() {
// 空の関数配列がうまく作れないので要素を1つもつ配列を作ってみた
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();


416 :デフォルトの名無しさん:2009/01/11(日) 09:04:11
結局C#でも

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

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

417 :デフォルトの名無しさん:2009/01/11(日) 09:51:31
>>411
C++のテンプレートとの違いなんて話題になってないよ。
それをいきなりC++のテンプレートと違うなどとわめいても、だれも相手にしない。

418 :デフォルトの名無しさん:2009/01/11(日) 10:01:17
.NET4.0のように、並列機能を強化して欲しい
あっちはfor loopを自動で並列化してくれるようになるらしいぞ

419 :デフォルトの名無しさん:2009/01/11(日) 10:14:14
あれは並列化するだけだし
その程度ならクロージャさえあれば簡単に出来る

420 :デフォルトの名無しさん:2009/01/11(日) 10:25:36
>その程度ならクロージャさえあれば簡単に出来る
本当?
クロージャを知らないJava世代の俺に例を教えてくれ

421 :デフォルトの名無しさん:2009/01/11(日) 10:29:56
Parallel.For(0, 10000, i =>
{
// 重い処理
});

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

422 :デフォルトの名無しさん:2009/01/11(日) 10:29:58
コンパイラいじったり言語仕様拡張していくのはC++で十分。
MSお得意の「拡張・吸収・淘汰」によって技術を食べていっちゃうMSの手口知らないの?
そんなことしていると、そのうちに蛙まで食べちゃう「カオナシ」になっちゃうよw

423 :デフォルトの名無しさん:2009/01/11(日) 11:04:51
>>410
まあクロージャ入るのは間違いないだろうね。BGAAが。
>>409
いまさら実行時サポートなしのやつだけなのか!って驚きの方が大きかったが。
>>417
C++と同じところ(erasure type)が話題になっていたわけだからね。

424 :デフォルトの名無しさん:2009/01/11(日) 11:13:46
>>420
BGAA提案ならfor文に相当するものをユーザ定義できる。
>>421の{ //重い処理 }に相当するループ変数を引数とするクロージャを、
生成したスレッドに実行させる新しい並列forを定義するだけ。

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

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


425 :デフォルトの名無しさん:2009/01/11(日) 11:15:25
クロージャと通常の処理の外からの見分けが付かないのは
危険極まりないと思うがね

426 :デフォルトの名無しさん:2009/01/11(日) 11:19:10
BGAA

427 :デフォルトの名無しさん:2009/01/11(日) 11:19:32
>>425
提案読んだことないのが丸分かりだね。
このスレで意見を書くのはまだ早いのでは?

428 :デフォルトの名無しさん:2009/01/11(日) 11:32:57
ニューnファンネルバリアって射撃属性だよね?
だったらスナイプつけて雑魚即死で余裕だぜ!!

429 :デフォルトの名無しさん:2009/01/11(日) 11:37:38
>>415
つScala。クロージャが欲しいだけでも学ぶ価値あり、と思ってる。
ただ、IDE(つかEclipseのScala Plugin)がヘボいのが難点……。

430 :デフォルトの名無しさん:2009/01/11(日) 11:40:56
>>427
きみ、ヤバイよww
バカ丸出しだしw

431 :デフォルトの名無しさん:2009/01/11(日) 11:51:28
Lock lock = new ReentrantLock();
withLock(lock) {
  System.out.println("Under 'withLock' control.");
}

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

432 :デフォルトの名無しさん:2009/01/11(日) 11:53:21
そんなん問題にしてる奴なんかいない

433 :デフォルトの名無しさん:2009/01/11(日) 11:56:12
だったら問題にせえよ
演算子オーバーロードも認めないくせに
なんで制御構造の独自定義を認めるんだよ

434 :デフォルトの名無しさん:2009/01/11(日) 11:59:51
BGAA君

435 :デフォルトの名無しさん:2009/01/11(日) 12:05:27
演算子オーバロードを認めて何かいいことあんの?ただの構文砂糖なだけじゃないか。w
上にもデリゲート結合+=の例で書いてあるけど、可読性云々はなしよw

436 :デフォルトの名無しさん:2009/01/11(日) 12:10:09
構文糖衣ったって+より*が優先されるメソッドなんて作れんだろ
しかしそれがないと多倍長整数も複素数もまともに作れんのだ

437 :デフォルトの名無しさん:2009/01/11(日) 12:25:13
BGGAとBGAAとあるの?

438 :デフォルトの名無しさん:2009/01/11(日) 12:25:33
俺は演算子オーバーロードも欲しい。
C++やHaskellでの例を見ても、
変態的な演算子オーバーロードは決して流行らず廃れていく。
可読性のあるものだけ残っていく。
boost::expressiveみたいなのが主流になることはない。

439 :デフォルトの名無しさん:2009/01/11(日) 12:29:55
おれよくライブラリとか作るけど、例えば多倍長とかも c=a.sub(b);で実際全く問題なんだが?
たとえば、x=a.sub(b).mul(c)でいいんでないの。
どうせ何も作ったことないで人の言いなりロボット君なんだろうけどwwBGAA君もww

440 :デフォルトの名無しさん:2009/01/11(日) 12:33:22
可読性

441 :デフォルトの名無しさん:2009/01/11(日) 12:33:48
>おれよくライブラリとか作るけど

442 :デフォルトの名無しさん:2009/01/11(日) 12:34:15
ですか(笑)

443 :デフォルトの名無しさん:2009/01/11(日) 12:36:19
>x=a.sub(b).mul(c)でいいんでないの。

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

444 :デフォルトの名無しさん:2009/01/11(日) 12:38:19
クロージャも算子オーバーロードもないJAVAなんか糞言語。HTTTPだけあれば俺たちは幸せ!

445 :デフォルトの名無しさん:2009/01/11(日) 12:41:54
そうやってPGの方に宗教的制約を課すなら、そもそも演算子オーバーロードなんか不要でもいいんじゃないの?
JAVAの世界にいる本物のSEや本物の職人ではそういう意見が多いんですわwRUBYIZMなんかよりもよりも実利的ですなww

446 :デフォルトの名無しさん:2009/01/11(日) 13:05:28
表現が全く説得力ないよなあ
意見が多い、か。

447 :デフォルトの名無しさん:2009/01/11(日) 13:10:34
常に張り付いてる奴もいるし、雑学ばっかり増やしてるひまあったら手を動かせ。
くだらんスレだw


448 :デフォルトの名無しさん:2009/01/11(日) 13:14:35
>>443
おまえの頭はおかしいからな。

449 :デフォルトの名無しさん:2009/01/11(日) 13:35:17
Control Invocation Syntaxは別にクロージャ使ってること隠してないでしょ
見ればControl Invocation Syntax使ってるのは一目でわかる(=クロージャ
使ってることが一目でわかる)んだから。なんつーか、BGGAの提案書まともに
読んだこと無いやつが多過ぎだよ

450 :デフォルトの名無しさん:2009/01/11(日) 13:37:24
あと、クロージャとか関数型の便利さを知りたいならScalaやってみると良いよ
基本的に言語仕様のほとんどの部分でScalaの方が優れてるし(制御構造に
関しては一部劣化してるが)

451 :デフォルトの名無しさん:2009/01/11(日) 13:40:23
>>449-450
創価学会ってそんなにいいところなんですか?
みんな笑顔で楽しそうなんですけど・・・

452 :デフォルトの名無しさん:2009/01/11(日) 13:41:18
>>450
何が優れてるって?w

453 :デフォルトの名無しさん:2009/01/11(日) 13:46:34
確かにScalaの言語仕様はJavaみたいなウンコのはるか高みにあるね

454 :デフォルトの名無しさん:2009/01/11(日) 14:10:27
>>453
それでウンコの上で馴れ合って楽しいんですか?

455 :デフォルトの名無しさん:2009/01/11(日) 14:12:31
俺はJavaの後進性をあげつらって楽しんでるだけだよ

456 :デフォルトの名無しさん:2009/01/11(日) 14:32:39
学会さんですもんね

457 :デフォルトの名無しさん:2009/01/11(日) 14:33:36
あの・・・・BGAAってなんですか?

458 :デフォルトの名無しさん:2009/01/11(日) 14:37:36
ほんとなんなんだろうな

459 :デフォルトの名無しさん:2009/01/11(日) 17:28:53
Java6があまり進化しなかった代わりにJava7は大幅に進化するって聞いてたんですけど、
どの辺がすごくなるんですか!?

460 :デフォルトの名無しさん:2009/01/11(日) 17:37:37
すごくなる予定はありません

461 :デフォルトの名無しさん:2009/01/11(日) 17:46:14
>>450
まぁそういうの必要な人はScalaとか使うのが正解だよな。
わざわざJavaに追加する必要もない。

462 :デフォルトの名無しさん:2009/01/11(日) 19:53:57
>>461
確かにJavaに追加する必要があるかは議論の余地があるけど
クロージャのある言語をろくに使ってみたことも無いやつが良し悪し
についてまともな議論できるものかねえ。

463 :デフォルトの名無しさん:2009/01/11(日) 20:01:36
クロージャがあると

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("一致しません。");

こうなるんだぜ

464 :デフォルトの名無しさん:2009/01/11(日) 20:14:28
VB?何か汚いなあ

465 :デフォルトの名無しさん:2009/01/11(日) 20:15:45
逆にクロージャいれると何か困ることある?
便利そうなのはなんとなく分かったけど。

466 :デフォルトの名無しさん:2009/01/11(日) 20:22:17
クロージャ使ってるソースコードが
慣れないと読みにくいというのがあるかな

467 :デフォルトの名無しさん:2009/01/11(日) 20:24:11
慣れてなくても読みやすいものなんて

468 :デフォルトの名無しさん:2009/01/11(日) 20:28:02
Javaに入るとして、クロージャの引数は型宣言無しで使えるのでしょうか。
クロージャが入ってくると高階関数を使いたくなるのは自然だと思いますが
(それがないならコレクションに対するシンタックスシュガー程度にしかならない)
型推論のサポートが無いままJavaに突っ込まれても、ちょっとマゾいんじゃないかと思います。

469 :デフォルトの名無しさん:2009/01/11(日) 20:34:37
クロージャ入れた後で型推論付き(引数の型宣言なし)もできるようにするのは
そんなに難しくないから、とりあえず型推論なしで入れちゃってもOKだと思うぞ。

470 :デフォルトの名無しさん:2009/01/11(日) 20:39:06
いや無理でしょう。やはりJavaには馴染まない気がします

471 :デフォルトの名無しさん:2009/01/11(日) 20:39:15
>>463
FirstOrDefaultの定義は?
それが汎用的に書けるのが利点だというのはわかるんだけどさ。

472 :デフォルトの名無しさん:2009/01/11(日) 20:46:37
というか型推論がないとコレクションに対するシンタックスシュガーとして
すら使いたくないなぁ。面倒くさくて。
というわけで型推論もクロージャも欲しいです。ものぐさとしては。

473 :デフォルトの名無しさん:2009/01/11(日) 20:51:03
ですね。
でも型推論を入れてしまうと、クロージャに限らない話になってしまって
(少なくとも見た目的には)もうJavaがJavaでなくなるような雰囲気があります。
だから馴染まないと書きました。

474 :デフォルトの名無しさん:2009/01/11(日) 21:06:48
>>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メソッドをその引数のインスタンスメソッドのようにして呼び出す記法

475 :デフォルトの名無しさん:2009/01/11(日) 21:27:10
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流」だと思うのですが。

476 :デフォルトの名無しさん:2009/01/11(日) 21:27:55
手が滑った。firstMatchedの戻り値はStringに読みかえて下さい

477 :デフォルトの名無しさん:2009/01/11(日) 21:39:33
Predicateクラス作れったってめんどくさくて誰もやらないでしょう
関数に分けるより直接書いちゃったほうがコードもむしろ読みやすい気がする

478 :デフォルトの名無しさん:2009/01/11(日) 21:43:05
Predicateクラスでも作って引数に渡すのがJava流というのはその通りだと思うし
Google Collections Libraryでも実際にそんな感じのクラスがあったりするけど
いちいち必要になるたびに別個にクラス作らなきゃならんのがダサい
無名クラス使えば記述量は多少減らせるけど煩雑だしな

479 :デフォルトの名無しさん:2009/01/11(日) 21:44:43
いや、そういうの(Predicateクラス作れ)をめんどくさいという人
(or そういうのがめんどくさいと感じる規模のプログラム)なら
Javaで書こうとするのが間違ってる。

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

480 :デフォルトの名無しさん:2009/01/11(日) 21:46:57
いやいや、小さいプログラムに限った話じゃないし、スクリプト言語関係無いから
クロージャ=スクリプト言語由来の機能だとでも思ってる?

481 :デフォルトの名無しさん:2009/01/11(日) 21:49:24
関数型言語由来の機能ですよ。

closure = environment + function
object = state + function


482 :デフォルトの名無しさん:2009/01/11(日) 21:59:44
DBにアクセスして結果をブラウザに返すだけのプログラムしか作ってないんだろ?
クロージャとかホントにいるの?

483 :デフォルトの名無しさん:2009/01/11(日) 22:05:27
Predicateクラスの中で必要なのは条件のメソッドの中身だけで
他の部分はノイズでしょう

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

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

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

484 :デフォルトの名無しさん:2009/01/11(日) 22:06:55
クロージャいらね。

485 :デフォルトの名無しさん:2009/01/11(日) 22:11:32
関数型とかわけわかんねえものは要らねえよな。
プログラミングは数学じゃねえぞ。

486 :デフォルトの名無しさん:2009/01/11(日) 22:14:15
>>483
>FirstOrDefaultのような抽象化は現状のJavaの言語機能では現実的じゃないし
>だからといってコレクションに対する定型的な処理を毎回手で書くのもバグの元

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

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

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

487 :デフォルトの名無しさん:2009/01/11(日) 22:18:50
具体的に補足。

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

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

488 :デフォルトの名無しさん:2009/01/11(日) 22:28:31
必要かはともかく、欲しい。

489 :デフォルトの名無しさん:2009/01/11(日) 22:29:07
そういった機能を言語仕様に導入しないと
毎回手で書いた方がマシな状態になってしまうのだから
Javaにもその機能が必要でしょうよ

490 :デフォルトの名無しさん:2009/01/11(日) 22:34:57
CがC++になったときみたいな論争だね。

491 :デフォルトの名無しさん:2009/01/11(日) 22:43:47
>>485
数学的な素養がなくて抽象化もできないお前みたいなやつ
ばっかりだから、IT業界がデジタル土方って言われるんだよ。

492 :デフォルトの名無しさん:2009/01/11(日) 22:47:05
今言えるのは、このスレみたいな状況下でクロージャぶち込んでも混乱するだけ。
プログラマーが苦労するか楽するかだけの問題ならね。

493 :デフォルトの名無しさん:2009/01/11(日) 22:55:08
>>492
>このスレみたいな状況下で

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

494 :デフォルトの名無しさん:2009/01/11(日) 22:55:27
>>491
Javaはドカタ用の言語だろ?
ドカタじゃないならHaskellでもMLでも使っとけ

495 :デフォルトの名無しさん:2009/01/11(日) 23:01:29
クロージャ使うとこんな感じで書くの?
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;
}


496 :デフォルトの名無しさん:2009/01/11(日) 23:01:38
楽に書けるようになれば土方だって幸せ。
通もうなる屁理屈と土方だって使える簡潔さ、両者を満たすのが理想。

497 :デフォルトの名無しさん:2009/01/11(日) 23:05:36
というかfoldとかFirstOrDefaultがstatic関数として宣言されているのはどうして?
お馬鹿さんにも分かりやすいように教えて下さい。クロージャの扱いと関係ある?

498 :デフォルトの名無しさん:2009/01/11(日) 23:07:41
関係ない

499 :デフォルトの名無しさん:2009/01/11(日) 23:08:19
土方としてはクロージャよりBigDecimalで演算子使える方がうれしい
Java案件の多く(金額ベース)は金融なんだからよろしく頼むよ

500 :デフォルトの名無しさん:2009/01/11(日) 23:11:32
>>499
泣いた。
演算子の再定義が無い事が今更ながら非人道的だと思えた。

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

502 :デフォルトの名無しさん:2009/01/11(日) 23:17:06
こんばんは、今宵も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 }
 :


503 :デフォルトの名無しさん:2009/01/11(日) 23:17:29
ドカタとしてはControl Invocation SyntaxでRAIIできれば幸せ。

504 :デフォルトの名無しさん:2009/01/11(日) 23:18:44
なんでもいいけど、コンパイルが通った後でtype mismatchとかいう例外が起きる言語は使い物にならないよ

505 :デフォルトの名無しさん:2009/01/11(日) 23:20:34
>>504
それはつまりキャストのある言語(Java含む)は使い物にならないってことかね?

506 :デフォルトの名無しさん:2009/01/11(日) 23:21:23
例外なしでいきなり逝く方が良いと

507 :デフォルトの名無しさん:2009/01/11(日) 23:21:31
ジェネリクスがあるのに好き好んでダウンキャストする馬鹿なんてまだいるの?

508 :デフォルトの名無しさん:2009/01/11(日) 23:22:21
>>495
それでいいと思うけど
LINQだと(s,i) => s + i と書くけどな

509 :デフォルトの名無しさん:2009/01/11(日) 23:26:01
{引数型リスト、返り値型、例外型リスト}を全部まとめたものがクロージャの型宣言になって
やっぱりJavaだと型宣言を省略させるわけにはいかないから結構だるそうですね

510 :デフォルトの名無しさん:2009/01/11(日) 23:30:39
そりゃ関数型の方でしょ。
クロージャなら戻り値型や例外型は型推論できるし
代入先の情報がありゃ引数型も型推論できる。

511 :デフォルトの名無しさん:2009/01/11(日) 23:32:32
Control Invocation Syntaxって値返せないんでしょ
そんなあまり使い道のないケースを言語として特別扱いするのは
筋が悪い気がするよ

512 :デフォルトの名無しさん:2009/01/11(日) 23:33:15
>>510
そもそもBGGAだと戻り値型と例外型は型推論してるしな

513 :デフォルトの名無しさん:2009/01/11(日) 23:33:49
>>507
好き好んでダウンキャストはしないが、ライブラリ(Javaの標準ライブラリ含む)の都合で
ダウンキャストが避けられない場面はある。それよりも、上で言ってるのは言語の話
であってキャストをユーザが使うかどうかという話じゃないんだがな

514 :デフォルトの名無しさん:2009/01/11(日) 23:35:57
>>511
値返せたほうが便利だけど値返せなくても十分使い道はあるよ。

515 :デフォルトの名無しさん:2009/01/11(日) 23:36:17
>>511
クロージャはともかくControl Invocation Syntaxは必要かどうかは微妙なところ
だけど、Control Invocation Syntax無いと言語のファーストクラスの制御構造
(forやwhile)と同等のものが作れないからなー(breakとかcontinueなどが使えない
ので)。

516 :デフォルトの名無しさん:2009/01/11(日) 23:41:50
>>510
>>代入先の情報がありゃ引数型も型推論できる。

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

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

517 :デフォルトの名無しさん:2009/01/11(日) 23:44:21
クロージャの引数型の推論はC# 3.0でもScalaでもやってるし
Javaでもやってできないことは無いだろう。型システム上、
完全な推論は難しいと思うけど、ほとんどのケースでうまく推論できると思う

518 :デフォルトの名無しさん:2009/01/11(日) 23:45:44
>>511
クロージャを引数に取って値返すメソッド書くのは自由だよ。


519 :デフォルトの名無しさん:2009/01/11(日) 23:49:01
>>510
http://www.javac.info/closures-v05.html
これを読んで、あなたが何を言ってるのか理解しました。

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

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

520 :デフォルトの名無しさん:2009/01/11(日) 23:49:46
>>518
Control Invocation Syntaxは扱い上、「文」だから値返せねえという話でしょ
>>511はクロージャだけあれば十分でControl Invocation Syntaxというシンタックスシュガー
は要らんという意見だと思う

521 :デフォルトの名無しさん:2009/01/12(月) 06:28:45
なんかあれだな。1年前のクロージャ議論(英語)を見てるようだ。
プロトタイプ実装がダウンロードできるから使ってみるといい。
JAVAクロージャを使ったこともないのに理想であれこれ言う奴が多いから、まだPGの間で導入するかの合意が取れてなってないってのが動流が微妙な理由なのよ。1.7までまだ1年以上あるけど。

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

522 :デフォルトの名無しさん:2009/01/12(月) 09:05:12
関数引数の中の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();

こうだけどな

523 :デフォルトの名無しさん:2009/01/12(月) 09:10:08
やり直し

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();

こうだけどな

524 :デフォルトの名無しさん:2009/01/12(月) 10:19:16
それって多重継承の問題が出てくると思うけど名前空間はどうやって解決してるの?

525 :デフォルトの名無しさん:2009/01/12(月) 10:47:01
.NET のクロージャは LINQ のためにあると言っても過言ではないだろう。

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

526 :デフォルトの名無しさん:2009/01/12(月) 10:53:44
>>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);
スタティックメソッドとして呼び出す

527 :デフォルトの名無しさん:2009/01/12(月) 11:04:37
そんなにC#が好きならC#でやれよ。
いつのまにか君もMS信者になっちまっちゃってるのかも。

528 :デフォルトの名無しさん:2009/01/12(月) 11:07:45
ん、なんかこのスレにアンチMSが紛れ込んでるぞ

529 :デフォルトの名無しさん:2009/01/12(月) 11:18:26
>>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 })))

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

530 :デフォルトの名無しさん:2009/01/12(月) 11:18:55
Javaスレで違う言語の話ばかり延々とされてもな

531 :デフォルトの名無しさん:2009/01/12(月) 11:24:18
じゃあC#の話は禁止で。

532 :デフォルトの名無しさん:2009/01/12(月) 11:34:56
>>525
大騒ぎするもんでもないが、「DTOのコレクションに対する操作」を簡潔に記述するための
便利シンタックスとしてしかとらえられてないんだったら見方が狭いとしか言いようが無いな
あと、.NETのクロージャがLINQのためにあると言うけど、それだけではないでしょ
クロージャ自体はLINQが入るはるか前の.NET 2.0からあるんだし。

533 :デフォルトの名無しさん:2009/01/12(月) 11:41:55
↑Javaと関係ないからレス禁止な

534 :デフォルトの名無しさん:2009/01/12(月) 11:42:40
LINQのために追加されたのはラムダ式だな

535 :デフォルトの名無しさん:2009/01/12(月) 11:49:54
ボクシングやアノテーションなんてのはC#の後追いなわけだし
プロパティもクロージャも後追いなわけで
Javaに追加する言語仕様の話をするならC#の話は避けて通れないだろ

536 :デフォルトの名無しさん:2009/01/12(月) 11:53:35
お前Javaに追加する言語仕様の話は一切してなくてC#の言語仕様の紹介しかしてないだろ
だからスレ違いだっつーの

537 :デフォルトの名無しさん:2009/01/12(月) 11:59:06
>>535
後追いっつうのはちと語弊があるな。別にクロージャはC#の専売特許でもなんでもない
そもそも関数型言語由来の機能だし。あと、BGGAのクロージャは、C#のそれとはかなり
違うものだから。

538 :デフォルトの名無しさん:2009/01/12(月) 12:02:00
話をJavaのクロージャに戻すと、Control Invocation Syntaxは結構便利だと
思うけどなー。サンプル版使ってみたけど、これ使うの前提でIO関係のライブラリ
作ればこれまで面倒だった処理がかなりすっきり書けるよ。

539 :デフォルトの名無しさん:2009/01/12(月) 12:07:42
Control Invocation Syntax使うために標準ライブラリを書き直すつもりなの?

540 :デフォルトの名無しさん:2009/01/12(月) 12:10:07
>>535
ボクシングは関数型言語の後追いですね。
そのためにSPJがMSRに呼ばれました。

541 :デフォルトの名無しさん:2009/01/12(月) 12:11:48
IO関連だけならライブラリ書き直す必要ないし。
コレクションでLINQ的な使い方するなら拡張メソッド導入するか
標準ライブラリ書き直しかする必要あるけど。

542 :デフォルトの名無しさん:2009/01/12(月) 12:54:34
冷静に考えると、
ボクシング、アンボクシングは心底いらないと思う

543 :デフォルトの名無しさん:2009/01/12(月) 13:06:39
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を呼び出した時に渡すクロージャからしかアクセスできなくしたいじゃない

544 :デフォルトの名無しさん:2009/01/12(月) 13:06:48
クロージャは導入されるから安心しろ。問題はそれがいつになるかだけ。
それと、専売特許以前に、C#とJAVAを比較しても全く意味ない。もともとC#(.Net)がJava/JVMのマネでしょw

545 :デフォルトの名無しさん:2009/01/12(月) 13:18:37
比較しても意味ない?
なんでそんな非科学的なの?
後を追ってる言語が先を行ってる言語を参考にするのは当たり前のことだろ
Javaはもはや後進言語だってことを認識しなさい

546 :デフォルトの名無しさん:2009/01/12(月) 13:22:43
後進でいいよ。
下手に先進的な機能つけて失敗された方がかなわん。

547 :デフォルトの名無しさん:2009/01/12(月) 13:34:49
>>546
MFCのことを侮辱するのはいい加減にしてください。


548 :デフォルトの名無しさん:2009/01/12(月) 13:35:55
ん、なんかこのスレにMS信者が紛れ込んでるぞ

549 :デフォルトの名無しさん:2009/01/12(月) 14:15:05
大きな改変がないんなら、リリースやめてもらったほうが1.4延命できていいんだが

550 :デフォルトの名無しさん:2009/01/12(月) 14:32:43
>>549
既に死んでるじゃん、1.4。

551 :デフォルトの名無しさん:2009/01/12(月) 14:56:57
JavaとC#が互いにどっちが先進的だとか何とか、アホかと
closureなんてsmalltalkにだってあるだろ

552 :デフォルトの名無しさん:2009/01/12(月) 15:05:07
>>551
土方言語限定の井戸端会議ですから。

553 :デフォルトの名無しさん:2009/01/12(月) 15:13:17
クロージャなんぞLispからあるわ
じゃあ今のJavaが目指してるのはLispか?違うだろ
Javaは今C#を目指してるんだよ

554 :デフォルトの名無しさん:2009/01/12(月) 15:15:49
今となってはMFCのためにMSに金払って買ってたのがバカらしい

555 :デフォルトの名無しさん:2009/01/12(月) 15:16:49
たぶんControl Invocation SyntaxもC#に先に入ると思いますw
javac.infoの中の人、MS行っちゃったし。


556 :デフォルトの名無しさん:2009/01/12(月) 15:20:29
C#で実験してくれるならそれもいい。

557 :デフォルトの名無しさん:2009/01/12(月) 15:21:19
Apache+Tomcatの構成が廃れない限りC#はJavaに勝てないと思う

558 :デフォルトの名無しさん:2009/01/12(月) 15:27:35
MSにとってどういう扱いなのか知らないが、Javaにとっては完全にC#は実験台だよね。
C#がどんどん仕様追加して、美味しい(問題がなさそうな)とこだけJavaが頂戴する。

559 :デフォルトの名無しさん:2009/01/12(月) 15:30:38
正直MSの方向性は謎

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

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

560 :デフォルトの名無しさん:2009/01/12(月) 15:35:53
先駆者である必要はない
より使えるものになればそれでいい
使えなくなれば他を使えば済むだけ
道具のひとつと一緒に心中するなんてやつはいないだろ

561 :デフォルトの名無しさん:2009/01/12(月) 15:42:42
誰にとって使えるものになってなきゃいけないかって視点だな
JavaやC#みたいな言語はドカタに使ってもらえなきゃ意味がないわけで
最近のMSはその辺り勘違いしている気がするな

562 :デフォルトの名無しさん:2009/01/12(月) 15:51:44
おまいらマ板ネタになると俄然元気になるな

563 :デフォルトの名無しさん:2009/01/12(月) 15:55:04
プログラマ以外Javaなんて使わないだろ

564 :デフォルトの名無しさん:2009/01/12(月) 16:10:32
無名内部クラスとか
基本型が使えないジェネリックとか失敗だし
何よりブサイクでしょう
オートボクシングもボクシングを推奨してるみたいになって最悪

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

565 :デフォルトの名無しさん:2009/01/12(月) 16:11:31
オープンソースの台頭によりSUNが死滅してJava健全化。
喜んだのもつかの間、旗振り役がいなくなってJava死滅。
今後の予定です。

566 :デフォルトの名無しさん:2009/01/12(月) 16:22:01
基本型をジェネリックに使うのはerasureでは無理だからな
C++みたいにコンパイル時に作るか,C#みたいに特殊化したコードを実行時に生成するかしないといけない

567 :デフォルトの名無しさん:2009/01/12(月) 16:32:29
次のVM仕様で実行時タイプサポートが強くなるから、
もしかしたらGenericsでの基本型の扱いも変わるかもしれない。
今のVM仕様のままだと、他の言語で不便だから。


568 :デフォルトの名無しさん:2009/01/12(月) 16:40:35
>基本型が使えないジェネリックとか失敗だし

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

569 :デフォルトの名無しさん:2009/01/12(月) 16:47:23
age棒はやっぱりというかMS狂信者なわけで・・・

570 :デフォルトの名無しさん:2009/01/12(月) 17:33:41
genericsが基本型に対応したらT extends Object//基本型はダメ
が出てくるのかなw

571 :デフォルトの名無しさん:2009/01/12(月) 23:01:14
Javaはもともと、委員会症候群により仕様が肥大化したC++への
アンチテーゼみたいな矜持があったように思うけどねぇ。
それで逆にJavaBeansやannotationなんかは、構文の拡張を
しないがためにかなり無理のある仕様になってしまったくらいだし。

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

572 :デフォルトの名無しさん:2009/01/12(月) 23:11:15
楽は目指してないような

573 :デフォルトの名無しさん:2009/01/12(月) 23:16:22
JavaBeansを言語仕様に組み込んだところで(プロパティとか)、コンパイラが複雑になるだけだし変わらん。
Cがなぜ普及したかは、全ての言語機能をライブラリにしたからじゃなかったか?そういうの知らないで育ったゆとり世代なのか。w

574 :デフォルトの名無しさん:2009/01/12(月) 23:16:40
長い上にロジックが変。
悪いプログラムの見本のようなレス。


575 :デフォルトの名無しさん:2009/01/12(月) 23:18:11
全ての言語機能だって?
ライブラリしか残らんじゃないか!
この世の終わりじゃ!



576 :デフォルトの名無しさん:2009/01/12(月) 23:52:08
>>572
んでも、少なくともここでクロージャを欲している人はそういう意見なんじゃね?
その程度でいちいちクラスを起こすのは面倒いって。

577 :デフォルトの名無しさん:2009/01/13(火) 00:07:59
面倒もあるけど、限られた言語機能の使い回しに伴うノイズが多すぎる。
特に匿名インナークラス。

578 :デフォルトの名無しさん:2009/01/13(火) 00:17:09
一言で楽したいって言っても人によってイロイロあるからな
例えば楽したくても演算子オーバーロードは絶対駄目な人もいれば
BigDecimal特別扱いでいいからつけてよって人もいるし
インデクサ程度ならって人もいるし
制限なしの演算子オーバーロード欲しいって人もいる

579 :デフォルトの名無しさん:2009/01/13(火) 07:33:18
後から読む人が犠牲になるような書き易さは害悪

580 :デフォルトの名無しさん:2009/01/13(火) 08:57:27
Control Invocation Syntaxはライブラリの乱立を招きかねないという懸念があるよね

581 :デフォルトの名無しさん:2009/01/13(火) 09:06:44
今だってじゅうぶん乱立しとるがな

582 :デフォルトの名無しさん:2009/01/13(火) 09:13:54
乱立が必ずしも悪いとは思わんけどね
ライブラリ間で競争するだろうし

583 :デフォルトの名無しさん:2009/01/13(火) 09:27:10
Control Invocation Syntaxあると、なんでライブラリ乱立するの?

584 :デフォルトの名無しさん:2009/01/13(火) 09:51:45
あるとこでは自動クローズ構文がwithで
別のとこではusing, withは別の構文で使われてるみたいなことになるかもしれない

585 :デフォルトの名無しさん:2009/01/13(火) 10:02:49
MSのVJ++のデレゲートは叩いたのになんでいまさらクロージャ?

586 :デフォルトの名無しさん:2009/01/13(火) 10:42:10
>>584
標準ライブラリでもバイト配列への変換が getBytes だったり toByteArray だったりするわけで、
その程度なら乱立しなくても標準ライブラリ内で不統一って事もありうる

587 :デフォルトの名無しさん:2009/01/13(火) 10:42:46
>>584
そんなのクラス名、メソッド名も同じじゃんw
>>585
JCPでやってることと、一企業の独善的な拡張は違うよ。

588 :デフォルトの名無しさん:2009/01/13(火) 10:43:52
クロージャとVJ++のデレゲートは別モノだろ

589 :デフォルトの名無しさん:2009/01/13(火) 10:59:55
>>588 kwsk

590 :デフォルトの名無しさん:2009/01/13(火) 11:21:34
クロージャと同じなのはC#の匿名デリゲートだろ
VJ++のは関数オブジェクトじゃなくてメソッドポインタだし

591 :デフォルトの名無しさん:2009/01/13(火) 11:25:12
javaのはなしから脱線してすまないが流れ上説明するよ。
delegateがクロージャとしての機能を持ったのはC#2.0(.NET2.0)からで
VJ++のdelegateはC#1.0のそれと同じで動的にも静的にもスコープは持たない。
安全な関数ポインタというだけのものだった。

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


592 :デフォルトの名無しさん:2009/01/13(火) 12:02:33
関数ポインタとメソッドポインタは全然違うわけだよ
メソッドポインタを関数ポインタで無理やり書けば

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

593 :デフォルトの名無しさん:2009/01/13(火) 12:14:50
VBやりすぎると頭おかしくなるって言うけど、C#もやるすぎると頭おかしくなっちゃうんだね

594 :デフォルトの名無しさん:2009/01/13(火) 22:15:04
>>587
JCPとかいってSunという一企業の独善的な拡張と大差ないだろ
だからApacheは反対票入れまくってるし

595 :デフォルトの名無しさん:2009/01/13(火) 22:49:32
票も入れられねーし


596 :デフォルトの名無しさん:2009/01/13(火) 23:28:35
>>587
言語仕様なんて、確固としたポリシーがありゃ独善でいいと思うが。
逆にコミッティシンドロームに陥るほうがまずいだろう。
#MSに確固としたポリシーがあるかというのはされおいて。

597 :デフォルトの名無しさん:2009/01/13(火) 23:37:32
それはされおき、独善の意味を良く考えれ

598 :デフォルトの名無しさん:2009/01/13(火) 23:53:25
C#にはヘジたんという言語設計のプロがいるが
Javaは素人が寄せ集まってるだけなので
どちらが優れているのかは言わずもがな
このままでは差は開いて行くばかり

599 :デフォルトの名無しさん:2009/01/13(火) 23:54:12
>>597
http://www.sanseido.net/

600 :デフォルトの名無しさん:2009/01/13(火) 23:57:13
>>598
それを言うなら、Sunだって言語仕様策定のプロ中のプロのGuy Steele Jr.が居るだろw
まあ、Guy SteeleはJavaに関しては言語機能を追加する方向では
関わって無さそうな気はするけど。

601 :デフォルトの名無しさん:2009/01/14(水) 00:13:41
>>600
仕様策定ではなく仕様書作成に関わってるだけじゃね?

602 :デフォルトの名無しさん:2009/01/14(水) 00:18:19
GLSは仕様策定のプロというよりも仕様書書きのプロだろ

603 :デフォルトの名無しさん:2009/01/14(水) 00:32:40
しかしSchemeは最初からボスと二人でやってるからなあ。
あれだけでも凄い。
他にもConnection Machine Lispがある。
これも強烈。

604 :デフォルトの名無しさん:2009/01/14(水) 00:41:06
以前も書いたがライブラリの仕様はJCPのようなプロセスは必要だと思うが、
言語仕様は天才のひらめきが大事だと思うんだよな。
今の状況は船頭多くいして何とやらだ。

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

606 :デフォルトの名無しさん:2009/01/14(水) 00:55:17
>>602
仕様書書くことと仕様策定は密接に関わりがある作業だと思う。
それに、仕様書書くだけじゃなくてC,Fortran,Common Lispとかの仕様
策定にも関わってたはずだけど。

607 :デフォルトの名無しさん:2009/01/14(水) 07:10:41
Common Lispの仕様策定に関わってたらマイナスだろ
取捨選択せずにすべて取り込むとかセンスがない
ただし、あれを書き上げたのは天才

608 :デフォルトの名無しさん:2009/01/14(水) 11:00:55
Ken Arnold や James Gosling がスルーされてカワイソス

609 :デフォルトの名無しさん:2009/01/14(水) 11:32:50
ようやく分かった
Javaに足りないのはHPC対応だよ

はよ対応しろ

610 :デフォルトの名無しさん:2009/01/14(水) 12:33:23
Javaは1.4.2で一応の終焉を迎えたというのが俺の見解。
結局の所、その後の言語の発展は難解さとのトレードオフだ。
近年のJavaはC#に振り回されすぎなんじゃないだろうか。

611 :デフォルトの名無しさん:2009/01/14(水) 12:57:27
Java8ぐらいで互換性切って仕様を一新したほうがいい

612 :デフォルトの名無しさん:2009/01/14(水) 13:02:58
そうだなm。もうJavaに未来はないな。SUNも潰れそうだしいっそのこと、勢いのあるAPPLEとかMSに吸収されちゃうべきじゃないか?

613 :デフォルトの名無しさん:2009/01/14(水) 13:20:27
糞java.util.loggingをなんとかしろ

614 :デフォルトの名無しさん:2009/01/14(水) 13:43:31
>>609
こういうのか?
http://www.nikkeibp.co.jp/archives/044/44150.html

615 :デフォルトの名無しさん:2009/01/14(水) 16:12:42
>>612
個人的には、JavaはARMに吸収してもらいたい。
で、AppleからARMベースのフルスペックMacOSXマシンを・・・

616 :デフォルトの名無しさん:2009/01/14(水) 17:23:44
VMでコード再利用が出来て、
豊富なライブラリが存在して、
通信、DB、GUIの仕様が決まっていれば、
便利だということを証明したことがJavano最大の功績だった。

617 :デフォルトの名無しさん:2009/01/14(水) 18:01:24
なにこの過去に縋った流れ

618 :デフォルトの名無しさん:2009/01/14(水) 19:16:24
お復習ですやん

619 :デフォルトの名無しさん:2009/01/14(水) 19:23:54
鼻糞君がいるスレはここですか?

620 :デフォルトの名無しさん:2009/01/14(水) 20:53:59
> C#とJAVAを比較しても全く意味ない。もともとC#(.Net)がJava/JVMのマネでしょw

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

621 :デフォルトの名無しさん:2009/01/14(水) 21:18:35
.NetでもJavaでも好きなほうで書いていけば問題無い

622 :デフォルトの名無しさん:2009/01/14(水) 21:20:30
>>621
ひとりでやるんだったらね。
でもね、大勢で力を合わせて開発するとなつと、
好きな方をえらぶ、ってワケにはいかないんだよ。

623 :デフォルトの名無しさん:2009/01/14(水) 21:27:52
このスレには安月給の万年派遣もいるんですか?

624 :デフォルトの名無しさん:2009/01/14(水) 22:43:19
>>623
お前だけだと思うよ

625 :デフォルトの名無しさん:2009/01/14(水) 22:44:55
>>624
そう泣くなよ。安月給仲間じゃないか。

626 :デフォルトの名無しさん:2009/01/14(水) 23:11:20
しかし、なんだな
.NETとJavaは用途が異なるから似たような技術であっても
住み分けるはずだ、と言われていたが
最近はそうでもないんだな

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

627 :デフォルトの名無しさん:2009/01/14(水) 23:38:30
そうですね。もっとC#はVB化していくのでしょうね。

628 :デフォルトの名無しさん:2009/01/15(木) 00:11:59
今のVBは過去を引きずりつつC#に追いすがってる状態でしょ
Javaみたいに

629 :デフォルトの名無しさん:2009/01/15(木) 00:29:16
macjavaはもうちょっとなんとかならんもんかね

630 :デフォルトの名無しさん:2009/01/15(木) 01:13:44
どの言語使うか決めるのは俺なんだけど

631 :デフォルトの名無しさん:2009/01/15(木) 01:17:45
VB化するC#とCOBOL化するJava
どっちがマシなんでしょうかwwwwwwww

632 :デフォルトの名無しさん:2009/01/15(木) 01:24:13
>>630
サンデープログラマですか?

633 :デフォルトの名無しさん:2009/01/15(木) 01:25:18
別に好きに選んでる人はいると思うけどな
俺は世間に流されるが!

634 :デフォルトの名無しさん:2009/01/15(木) 01:29:56
>>632
サタデープログラマです。

635 :デフォルトの名無しさん:2009/01/15(木) 01:33:13
フライディ・チャイナ・タウン歌いましょうか?

636 :デフォルトの名無しさん:2009/01/15(木) 01:34:59
bsdもにたようなものだけどmacはsunが作ってないから無理。
それよりも、gnu classpathはどうなっちゃうの。もう終わり?

637 :デフォルトの名無しさん:2009/01/15(木) 14:08:48
>>616
LispのVMが出れば最強、そういうことですね?

638 :デフォルトの名無しさん:2009/01/17(土) 22:58:19
http://www.atmarkit.co.jp/fdotnet/special/linqtoxml/linqtoxml_01.html
これはいつJavaに入りますか?

639 :デフォルトの名無しさん:2009/01/17(土) 23:11:21
LINQ to XMLは確かにすごく使いやすいけど
この標準無視の独自性はMSならでは
さすがにJavaにこういうのは入らないだろうな

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

641 :デフォルトの名無しさん:2009/01/18(日) 03:27:56
その人とは関係ないけどVBの小ネタ記事なんかもっとすごいよ。
MSDNによくあるけど「特集11号 これは目からうろこ!!VBプログラマ必見!」とかw

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

642 :デフォルトの名無しさん:2009/01/18(日) 05:28:59
LINQだけど、ODBMSの標準化界隈では一応こんな話もあるという事で。
http://www.odbms.org/blog/2008/08/linq-is-best-option-for-future-java.html

643 :デフォルトの名無しさん:2009/01/20(火) 00:47:05
>>492
苦労じゃ

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

644 :デフォルトの名無しさん:2009/01/20(火) 01:26:21
>>643
おまえはITドカタ決定!

645 :デフォルトの名無しさん:2009/01/20(火) 11:42:31
>>163
JWebPaneマダーチンチン

646 :デフォルトの名無しさん:2009/01/20(火) 11:53:08
JDK7 build43
http://download.java.net/jdk7/changes/jdk7-b43.html
http://download.java.net/jdk7/binaries/

647 :デフォルトの名無しさん:2009/01/20(火) 21:56:08
>>645
これ来たら、俺ブラウザwithJava祭りになると思う。

648 :デフォルトの名無しさん:2009/01/20(火) 22:22:58
だよなー
けどずっと更新されないし。7じゃのらんだろうね

649 :デフォルトの名無しさん:2009/01/20(火) 23:28:37
Androidは、既にandroid.webkit.WebView by Webkitってのが来てるんだよな。

650 :デフォルトの名無しさん:2009/01/21(水) 11:50:15
実物のWebkit使えるから楽なんだろう

651 :デフォルトの名無しさん:2009/01/21(水) 20:08:37
>>607GLSファンとしては看過できねー。
「取捨選択せずにすべて取り込む」ってのは例の
「Schemeは全員が納得したものだけ取り込む、CommonLispは誰か一人でも提案したものは取り込む」
というジョークの影響だと思うが、大ウソなので注意な。実際は取捨撰択されまくっとる。

652 :デフォルトの名無しさん:2009/01/22(木) 19:43:46
提案されたものは全て取り込むとOn Lispに書いてあったぞ

653 :デフォルトの名無しさん:2009/01/22(木) 20:17:41
>>652
Paul Grahamは別にANSI Common Lispの仕様策定に関わってたわけでも
ないだろうし鵜呑みにするのはどうかと。Paul Grahamって割とテキトーな
こと書いてること多いし

654 :デフォルトの名無しさん:2009/01/22(木) 23:00:14
CLtLを読んだことがあれば、
取捨選択したことは分かります。
あの仕様書はノート付きですから。

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


655 :デフォルトの名無しさん:2009/01/30(金) 02:09:45
> JAVAは言語仕様の拡張は自然だし安心できる。

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

656 :デフォルトの名無しさん:2009/01/30(金) 04:56:20
基本型を追加したり変更するというのは、できないな。

657 :デフォルトの名無しさん:2009/01/30(金) 05:02:50
なんで?

658 :デフォルトの名無しさん:2009/01/30(金) 07:45:42
jdk7 build44
http://download.java.net/jdk7/binaries/
http://www.java.net/download/jdk7/changes/jdk7-b44.html

659 :デフォルトの名無しさん:2009/01/30(金) 10:14:52
>>655
まあVMの仕様を変更しないことが優先だよね。
次のVMでは変るかも知れないが。

660 :デフォルトの名無しさん:2009/01/30(金) 10:20:20
次のVMなんてでるわけねえだろ

661 :デフォルトの名無しさん:2009/01/30(金) 10:34:39
あらゆるところにアノテーション付けまくれば型に別名付けられないこともない

662 :デフォルトの名無しさん:2009/01/30(金) 12:44:58
また 「 : 」 が使われるのか・・・困ったときの 「 : 」 頼み、だな。

663 :デフォルトの名無しさん:2009/01/30(金) 13:02:09
なんのこと?

664 :デフォルトの名無しさん:2009/01/30(金) 14:53:19
>>657
基本型の変更は既存のソースへの影響が大きすぎる。
追加は変数名との衝突が考えられるのと、VMの変更が必要になる可能性がある。

665 :デフォルトの名無しさん:2009/01/30(金) 14:54:11
もちろん、基本型の追加は、クラスほか、別の識別子とかぶる可能性もある。

666 :デフォルトの名無しさん:2009/01/30(金) 15:02:52
基本型追加にしても char っつーか文字型 32bit にする必要性ってどれほどあるんだ?
サロゲートなくなっても合成文字まで消せるわけでもなし。

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

667 :デフォルトの名無しさん:2009/01/30(金) 18:23:39
>>664
新しい名前空間に追加すりゃいいじゃない
それが嫌ならdouble charでもいいし

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

668 :デフォルトの名無しさん:2009/01/30(金) 18:30:02
基本型の追加よりもBigDecimal等のために演算子の再定義を
認めた方が喜ばれるのでは。

669 :デフォルトの名無しさん:2009/01/30(金) 18:35:53
>>667
ようするにintの別名がほしいだけか

670 :デフォルトの名無しさん:2009/01/30(金) 19:06:47
>>666
そもそも必要だから欲しいって話じゃないし。
32bit文字型なんて要らんでしょ。byte[]でUTF-32扱えばいいだけだし。

671 :デフォルトの名無しさん:2009/01/30(金) 19:19:08
>>669
128ビットCPUとか256ビットベクトル演算ユニットみたいなものを
普通に使うようになるかも知らんだろ
基本型追加できませんじゃどうしようもないだろ

672 :デフォルトの名無しさん:2009/01/30(金) 20:03:30
>>671
必要になったときに追加すりゃいいじゃん。
それまでは DirectByteBuffer で我慢してもらう方向で。

673 :デフォルトの名無しさん:2009/01/30(金) 20:09:39
C#なんかバージョンアップするたびにキーワードが増えてるんだよ
人によっては気持ち悪いと感じるかもしれないけどコンテキストキーワードにすれば無問題

674 :デフォルトの名無しさん:2009/01/30(金) 20:15:53
>>671
何に怒ってるのか知らんが、まぁ落ち着け。

675 :デフォルトの名無しさん:2009/01/30(金) 20:39:47
GPGPUやManyCoreに関してはJavaFXみたいにJavaの言語仕様の
外で利用出来る形(それこそOpenCLのサポートとか)から始まって、
利用形態が固まって汎用的になった部分から徐々にJava本体に
取り込む形になるのでは。

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

676 :デフォルトの名無しさん:2009/01/30(金) 21:42:20
> 32bit文字型なんて要らんでしょ。byte[]でUTF-32扱えばいいだけだし。



677 :デフォルトの名無しさん:2009/01/31(土) 00:08:54
JDK7で入るライブラリとしては、NIO2 と他に何があるんだろうか。

678 :デフォルトの名無しさん:2009/01/31(土) 00:19:58
jsr166y

679 :デフォルトの名無しさん:2009/01/31(土) 11:02:52
JVMって、charは32bitだよね?
さすがにchar配列はこっそり16bit単位でアロケートしてるんだろうけど。

680 :デフォルトの名無しさん:2009/01/31(土) 11:46:13
VM Specification には char は 16bit 符号なし整数と書いてある。
演算時には iadd isub imul idiv で代用したりするけど、
だから char は int なんだとか byte は 32bit だ、とは言わんだろ普通は。

681 :デフォルトの名無しさん:2009/01/31(土) 11:49:32
>>680
いい加減、頭壊れてる奴の相手するの止めたら?

682 :デフォルトの名無しさん:2009/01/31(土) 13:14:45
boolean型同様、char型式もキャストや演算子に制限を加えておくべきだったな。
==,!=,<,>、あとStringやbyte[]との変換メソッドだけ用意しとけば
大抵のことはこなせたんじゃない?

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

683 :デフォルトの名無しさん:2009/01/31(土) 13:28:35
そこまでやるなら、char型削除で良いんじゃね?

684 :デフォルトの名無しさん:2009/01/31(土) 13:53:47
>>682
「文字」に対する認識が甘すぎる。

685 :デフォルトの名無しさん:2009/01/31(土) 14:05:59
>>684
キチガイをスルー出来ないおまえの認識の方が甘い

686 :デフォルトの名無しさん:2009/01/31(土) 17:11:26
CharacterがNumberを継承してないあたり、
Sunでも当初から「charは数ではない」との認識は
あったんじゃないかな。

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

687 :デフォルトの名無しさん:2009/01/31(土) 17:21:08
いつまでも配列のインデックスが32bitなのはどうなのよ?
ByteBufferのオフセットも32bitだからメモリマップとファイルでも2GBしか
アクセスできなくね?

688 :デフォルトの名無しさん:2009/01/31(土) 17:28:13
EJB使うと、C/Sプログラムが好きなフォームで作れるからいいよね。

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

689 :デフォルトの名無しさん:2009/01/31(土) 17:34:39
そーいえば一時期、開発中の NIO2 で
long 使える java.nio.ByteBuffer が置いてあったけど
いつのまにかに削除されてるなぁ。

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

690 :デフォルトの名無しさん:2009/01/31(土) 17:40:33
そんなにでかいファイルは普通にGC候補じゃないの?

691 :デフォルトの名無しさん:2009/01/31(土) 17:56:30
Javaの現行の仕様じゃ、RADに対応しきれない。
その点ではC#に分がある。
しかし、C#のポインタはいらないと思うな。
それはC言語でやればいい。

692 :デフォルトの名無しさん:2009/01/31(土) 18:43:29
>>691
>Javaの現行の仕様じゃ、RADに対応しきれない。

どのあたりが?

693 :デフォルトの名無しさん:2009/01/31(土) 19:16:02
ここは釣り掘かよ

694 :デフォルトの名無しさん:2009/02/01(日) 02:01:19
http://www.atmarkit.co.jp/news/200901/29/mono.html

695 :デフォルトの名無しさん:2009/02/01(日) 05:10:27
それでC#狂さんは、どのあたりに不満があるんですか?
C#に不満があるからこのスレに居座ってるんでしょw

696 :デフォルトの名無しさん:2009/02/01(日) 10:29:01
>>692
プロパティがないあたり

697 :デフォルトの名無しさん:2009/02/01(日) 10:47:58
プロパティがないのは致命的だよな。
コンポーネント指向にできない

698 :デフォルトの名無しさん:2009/02/01(日) 12:18:59
>>697
コンポーネント指向(笑)
プロパティが無いのは面倒だけど、致命的というほどではないだろ。

699 :デフォルトの名無しさん:2009/02/01(日) 16:02:59
>>696
RAD用のプロパティ仕様は最初からあっただろ

700 :デフォルトの名無しさん:2009/02/02(月) 11:01:34
http://www.atmarkit.co.jp/fcoding/articles/python3/01/python301a.html

701 :デフォルトの名無しさん:2009/02/02(月) 11:05:04
701

702 :デフォルトの名無しさん:2009/02/03(火) 00:03:34
アクセッサメソッドの為の専用の構文がないだけで、
JavaBeans仕様に乗っ取るなら、IDEが補完するから気にしない。

703 :デフォルトの名無しさん:2009/02/03(火) 04:33:57
配列プロパティがないのはどうかと思ってる

704 :デフォルトの名無しさん:2009/02/03(火) 04:43:43
>>703
インデックス付きプロパティがあるから無問題

705 :デフォルトの名無しさん:2009/02/03(火) 05:40:14
>>704
あったっけ?

706 :デフォルトの名無しさん:2009/02/03(火) 10:25:27
>>700
なにが言いたい?

707 :デフォルトの名無しさん:2009/02/03(火) 10:34:22
Python見習ってJavaも後方互換性捨てろって話では?
本人じゃないから外してるかも知れんけど

708 :デフォルトの名無しさん:2009/02/03(火) 12:36:58
>>705
JavaBeans仕様の「7.2 Indexed properties」に書いてある
ケチ付ける前に仕様に目を通すくらいしろよ

709 :デフォルトの名無しさん:2009/02/03(火) 12:40:15
おまえみたくヒマ人じゃないんで

710 :デフォルトの名無しさん:2009/02/03(火) 14:35:29
>>707
それは無理だな
そんあことしたらJavaが捨てられてしまう

711 :デフォルトの名無しさん:2009/02/03(火) 18:06:29
Pythonのポリシーが同じことの書き方を2とおり用意しない、ということなら、Javaのポリシーは後方互換だからな。

712 :705:2009/02/03(火) 18:07:48
>>708
見てなかった。ありがとー

713 :デフォルトの名無しさん:2009/02/03(火) 21:22:52
Java SE 6 Update12 release.

714 :デフォルトの名無しさん:2009/02/03(火) 21:30:44
java.util.Dateの地獄のようなメソッドリストラ、いい加減に何とかして欲しい。

715 :デフォルトの名無しさん:2009/02/03(火) 22:30:04
>>709
昼間っから2chやってるヒマ人のセリフかよw

716 :デフォルトの名無しさん:2009/02/03(火) 22:38:16
>>714
javax.time の地獄のようなクラス群も何とかして欲しい。

717 :デフォルトの名無しさん:2009/02/03(火) 22:50:34
地獄というほどでもないと思うがDateとCalendarの置き換えにしては大げさすぎだよな。

718 :デフォルトの名無しさん:2009/02/03(火) 22:52:21
javax.timeいらんくね?

719 :デフォルトの名無しさん:2009/02/03(火) 23:23:23
>>707
互換性がないなら、そもそもJavaである必要はないと思うんだけどな。
Scalaでいいじゃん、というか。(ScalaのEclipse Pluginはだめだめだけど)

720 :デフォルトの名無しさん:2009/02/03(火) 23:31:24
次世代 Javaである
Java3 の出番だな。

そのまえに Java 2+とJava turboR も出しておこうか

721 :デフォルトの名無しさん:2009/02/03(火) 23:40:09
自然画モードとPCMを取り入れるんですね。
わかります。

722 :デフォルトの名無しさん:2009/02/04(水) 19:07:26
書き換えられるなら、高速モードで動かせるのか。

723 :デフォルトの名無しさん:2009/02/06(金) 15:45:56
そういやさ、jdk7のビルドは淡々と進んでるけど
jdk6u10の成果ってマージされないじゃない?NimbusとかPluginとかの。

jdk7ではいつ取り込むんだろ?
ちょっと迷走しすぎじゃないかな・・・・jdk7

724 :デフォルトの名無しさん:2009/02/06(金) 17:51:32
nio2とかjsr308とかも独自だし、いつ統合されんだろな?

725 :デフォルトの名無しさん:2009/02/06(金) 18:02:48
jdk7 build46
http://download.java.net/jdk7/binaries/
http://www.java.net/download/jdk7/changes/jdk7-b46.html

typoとかの細かい修正がメイン

726 :デフォルトの名無しさん:2009/02/09(月) 19:05:02
最近聞かなくなったけどクロージャはどうなったの?
jdk1.6の途中でjavafxスクリプト追加みたいな感じにクロージャも追加になるのかな。

727 :デフォルトの名無しさん:2009/02/09(月) 20:23:10
C++もそうなんだけど、次の仕様のリファレンス実装をコーディングしていた
最重要人物がMS系の仕事しちゃってるんですよ。
ピンポイントで狙ってるんだと思う。

728 :デフォルトの名無しさん:2009/02/09(月) 20:32:45
>>726
Devoxxの発表でクロージャ漏れた。>>258あたり

729 :デフォルトの名無しさん:2009/02/09(月) 21:15:35
クロージャ便利なんだけどなぁ
クロージャを使うにはジャバだと少しトリック使わないといけないし、そろそろ導入して欲しい。

730 :デフォルトの名無しさん:2009/02/09(月) 21:28:56
>>728
それって完全に決定事項なの?

731 :デフォルトの名無しさん:2009/02/09(月) 23:06:40
>>730
JCPのページ見てもJava SE 7 Release Contentsみたいな
JSRが見当たらないから、完全に決定事項ってわけじゃなさそうだけど
とりあえず最新の公式発表って感じかなぁ? 望み薄なのは確か。

732 :デフォルトの名無しさん:2009/02/09(月) 23:14:44
だよなぁ。
つまんないなー

733 :デフォルトの名無しさん:2009/02/13(金) 23:05:58
JavaSE 6 update14 early access
http://blogs.sun.com/SDNProgramNews/entry/java_se_6u14_early_access

6u10 の 次は、u14が熱いらしいぜ。
GCに手が入っている、期待しよう。

ってか、7はどうなってんの?

734 :デフォルトの名無しさん:2009/02/14(土) 00:03:23
7は来年だ

735 :デフォルトの名無しさん:2009/02/14(土) 00:20:00
ナ ナンダッテー!!
 Ω ΩΩ

736 :デフォルトの名無しさん:2009/02/14(土) 00:48:40
>>734

2010年とか書いてあるね
ttp://journal.mycom.co.jp/column/jsr/060/index.html

737 :デフォルトの名無しさん:2009/02/15(日) 21:21:23
jdk7 build47
http://download.java.net/jdk7/binaries/
http://www.java.net/download/jdk7/changes/jdk7-b47.html

738 :デフォルトの名無しさん:2009/02/15(日) 22:26:39
7の言語仕様ってもう固まったの?
固まってないのにビルドが進んでも全然使う気になれないんだけど

739 :デフォルトの名無しさん:2009/02/15(日) 22:43:05
お前はここに来る必要すらない

740 :デフォルトの名無しさん:2009/02/15(日) 22:44:16
言語は変わらんでしょ

741 :デフォルトの名無しさん:2009/02/15(日) 23:27:17
>>738
固まってない。

jsr308 とか module は統合されるまで時間かかりそうだし
small language change は具体的に何やるのかも良くわからん。
multi catch と null handling と type inference は入りそうだけど、
string switch とかはどーなんだろ?

742 :デフォルトの名無しさん:2009/02/16(月) 02:16:16
次のリリースはクロージャをキャンセルした代わりにアノテーションだらけになりそうだね。
あとは、nio2とswing frameworkかな。

javafxは使いたけどcpu 2Gが最低必要だからちょっと敷居が高いな。
flashでもそんなにハードリソース必要なのか?
javax.mediaのライブラリに力を入れないで、なんでjavafxのようなメディア操作用API (script language)の方に力を入れるのか良く分からん。

743 :デフォルトの名無しさん:2009/02/16(月) 03:09:43
>>742
>javafxは使いたけどcpu 2Gが最低必要

この情報ってどこに書いてありますか

744 :デフォルトの名無しさん:2009/02/16(月) 04:42:19
javafxダウンロードのsystem requiredのところ。もしかしたらcpu 1.8Gだったかも。


745 :デフォルトの名無しさん:2009/02/16(月) 06:06:52
>>738
Java 7の変化は言語仕様だけじゃないぞ

746 :デフォルトの名無しさん:2009/02/16(月) 08:30:37
>>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

747 :デフォルトの名無しさん:2009/02/16(月) 11:16:47
>>742
swing の変更ってどこみりゃわかる?

748 :デフォルトの名無しさん:2009/02/16(月) 11:19:09
>>746
NetBeans vs Eclipseみたいなもんだな

749 :デフォルトの名無しさん:2009/02/16(月) 11:54:44
JavaFXがCPU2G要るって話じゃないのか。
単に開発環境のNetBeansがCPU2G必要って話か。
NetBeansなら、CPUは1Gでもいいが、メモリは2Gくらいあったほうがいいな。

750 :デフォルトの名無しさん:2009/02/16(月) 11:58:49
javaFX SDKのjavafxcコンパイラで遊ぶだけならしょぼいPCでも大丈夫。
JDKさえ動けばとりあえず可。

751 :デフォルトの名無しさん:2009/02/16(月) 23:47:11
たしかデモであったけど、スクリプトの変更がリアルタイムで確認できる奴は俺の持ってるCPU 1.4Gでは重すぎで全く実用にならない。
だからIDEというよりも、リアルタイム(コードとポトペタとの同期)にパワーがいるんじゃないかと思う。
デモの動きにストレスあったからたぶんjavafxを使うことはないだろうと思う。
これだとネットブック(1G程度)で現場で手早く開発というわけにはいかないなから、javafxはスクリプト感じはしない。

752 :デフォルトの名無しさん:2009/02/17(火) 00:17:57
JavaFXは携帯がメインターゲットやろうな

753 :デフォルトの名無しさん:2009/02/17(火) 00:48:55
swing frameworkだけど、java one の2006/2007年資料とか。java.netかな。
アプレットのinit(); start();みたく、 class Application initialize(); lanch()をオーバライドしていく感じで作られてる。
他にはリソース・バンドル・ファイル(GUI設定ファイル) file.propertiesと連携して、コンパイル時の静的にguiのフィールドを決定していくモデル。
だからjavafxは動的(リアルタイム)にフィールド変更だけど、java (swing)ではアプレットのモデルと同じ要領でアプリをつくっていって、各プロパティはリソースで解決するみたい。


754 :デフォルトの名無しさん:2009/02/17(火) 00:51:09
javafxは携帯向けといわれてるけど、実際は3DとかTVとかコーディックも充実してるからSUNはデスクトップ(というかアプレットに組み込んでブラウジング)の方を狙ってんるんじゃないかな。
たとえばサンプルでも合ったけど時計とかのガジェットをデスクトップに持ってくるのとか。
グーグルも似たものをやってるけど、グーグルはアプリは作れるけど言語や構築のフレームワーク(airとかjavafx)をもってないからあくまでもWeb向けの企業なのかなと思う。

755 :デフォルトの名無しさん:2009/02/17(火) 02:37:30
3Dとかビデオコーデック持ってると携帯向けと言えないとか、
googleはフレームワーク持ってないとか、
何なんですか、一体!

756 :デフォルトの名無しさん:2009/02/17(火) 03:13:26
グーグル(アンドロイド)は携帯向けの組み込み向けみたいなフレームワークで、swing/javafxの視点で見みるとjavafxのようなコンテンツ作成を押し出したものとはあまり関係ない。
そのほかは、日本の3流ライターがいたようなIT情報サイトじゃなくて、ちゃんと英語の情報ソースを読んでよ。
NTT研究所wとかたいそうな肩書きなところも含めて、3流ライターが書く記事は素人のブログとドッコイで本人の夢や理想だらけで嘘・噂で語ってることが多いからね。どこかから金もらって書いてるって聞いたらたちまち信用しなくなるんじゃないの?

757 :デフォルトの名無しさん:2009/02/17(火) 09:21:49
なんだその三流ライターみたいな論調はw

758 :デフォルトの名無しさん:2009/02/17(火) 18:37:58
自分戦略研究所とか言うIT向け情報サイトもあるけど、ただの馬鹿サイトだろ。
R25とか週間アスキーと同じで3流以下w
週間アスキーなんかゴシップに近いけど、信用する奴いるの?w

759 :デフォルトの名無しさん:2009/02/17(火) 20:53:37
何と戦ってるんだお前は

760 :デフォルトの名無しさん:2009/02/17(火) 21:37:50
>>759
お前は誰だ?
住所氏名を書いてみろよ

761 :デフォルトの名無しさん:2009/02/17(火) 21:40:11
>>760
お前は誰だ?
住所氏名を書いてみろよ

762 :デフォルトの名無しさん:2009/02/17(火) 21:46:39
それ、一生やってもつまんないから

763 :デフォルトの名無しさん:2009/02/17(火) 23:55:00
>>761
三流ライター アルゴ君です

764 :デフォルトの名無しさん:2009/02/17(火) 23:59:08
>>754
Pythonは言語じゃありませんか、そうですか。

765 :デフォルトの名無しさん:2009/02/18(水) 00:02:52
>>756 が本人の夢や理想だらけで嘘・噂で語ってるようにしか見えないのは気のせいか

766 :デフォルトの名無しさん:2009/02/18(水) 00:26:52
パイソンを言語だと考えるのはひょっとしたら夢じゃないのか?

767 :デフォルトの名無しさん:2009/02/18(水) 00:30:18
アルゴ!アルゴ!

768 :デフォルトの名無しさん:2009/02/18(水) 14:09:48
リズムにのって!

769 :デフォルトの名無しさん:2009/02/18(水) 15:23:13
JavaFXの存在だけは理解できん
あれはなんのためにあるんだ?
Swingじゃダメなのか?

770 :デフォルトの名無しさん:2009/02/18(水) 15:27:21
宣言的にUI部を書きたいって事らしいんだけど、
買い物だから、あまり親和性がないね。
rhinoもあんまり活躍してないし。この辺りは迷走気味だと思う。

771 :デフォルトの名無しさん:2009/02/18(水) 15:39:08
XMLじゃなくてスクリプト言語にした意味がわからん
どうせデザイナに自動生成させるんだろ
人間が書くものじゃない
まだXMLならツール作りやすいとかメリットはあるだろうけど

772 :デフォルトの名無しさん:2009/02/18(水) 20:24:29
>>769
Swingアプリはつくったことないんですが、WPFやAdobe AIRみたいなリッチアプリは、つくれるでしょうか?

>>771
Adobe Flex, WPFとアプリを作ってみたけど、mxmlやxamlは直に読むには少しうざったい感じがしたです。
JavaFX Scriptは、あえてxmlを選ばなかったみたいだけど、実際コードをみてみたり簡単なアプリ書いてみると、意外と直感的で、これもアリかという気もする。

773 :772:2009/02/18(水) 20:26:07
あ、771氏へのレスになってないけど、デザイナに自動生成する(こともあるだろうけど)、そうとも限らんのではないかと

774 :デフォルトの名無しさん:2009/02/18(水) 20:39:17
>>772
Swingもしらんのに良くこのスレに書き込むなw

775 :772:2009/02/18(水) 21:23:48
>>774
Swingの専門のスレでしたか、それは失礼

776 :デフォルトの名無しさん:2009/02/18(水) 21:49:36
JavaFXの批判とかそういことは、JavaFXを一通り勉強してから言うもんじゃないの?
妄想炸裂したいんなら別に構わないけどw

777 :デフォルトの名無しさん:2009/02/18(水) 23:49:51
>>772
今Swing学習中なんだが、もんのすごいプリミティブ。Webアプリのある意味
ぬるい世界にいたんだが、組み立てればおっけーだけど組み立てることしか
できない世界から、凝ったことしようと思えば大抵のことはできるけど
その分細かいとこまで作り込まないといけない世界に来て呆然としてる:-)

ちなみにSwingアプリの代表例は、NetBeans, JUDE, FreeMindあたり。

あと、Swingについては専門スレがある。
http://pc11.2ch.net/test/read.cgi/tech/1227234261/
スレタイに「低速」と付いてはいるが、最近じゃDirectX/OpenGLでレンダ
リングしていてかなり高速になっているらしい。

778 :デフォルトの名無しさん:2009/02/19(木) 00:32:41
Webアプリのある意味ぬるい世界とは具体的にどういうの?

779 :デフォルトの名無しさん:2009/02/19(木) 01:10:48
>>778
HTML/HTTPによって基本的な仕組みがある程度単純化/パターン化されていて、
比較的少ないコード量で実用的なプログラムを書き易い点と、
規模が大きくなっても基本的な構造自体はあまり変わらない点。
Ajaxとかが入ってくるとややこしくなってくるけど。

780 :772:2009/02/19(木) 02:29:11
>>777
Swingアプリを作るのは、そんなに容易でないという感触(実際、そういうIT記事もみかける)だったので、自分は敬遠していたけ。
でも、NetBeans使えばある程度簡単にSwingアプリ作られそうだし、ちょっと勉強したくなってきた。

一方、JavaFXでアプリ構築の容易さはあがったんじゃないかと思う。
ただ、まだ公開されたばかりで、足りないと思われる部分も沢山あるようには、思う。
(グラフィカルにJFXアプリを構築できるツールがないとか限られたSwingコンポーネントしか使えないとか)

どっちにしても、Swingを批判するつもりは全くなくって、むしろもっとがんばって欲しい。(もちろん、リッチGUIなアプリが構築できるJavaFXも)
NetBeansとかV2Cとか、「意外と」さくさく動いて心地よい。もっと、評価されていいような気がするなぁ。

781 :デフォルトの名無しさん:2009/02/19(木) 02:35:28
で、それが次世代Javaの動向とどういう関係が?

782 :デフォルトの名無しさん:2009/02/19(木) 02:38:50
>>781
スマン、ちょっと話題がそれた

783 :デフォルトの名無しさん:2009/02/19(木) 02:45:01
javafxスレがないからだろ。スレはお前がたてろ。

784 :デフォルトの名無しさん:2009/02/19(木) 07:06:36
>>782
日記に書いてろ

785 :デフォルトの名無しさん:2009/02/19(木) 07:49:26
JavaFXスレは確かに欲しいな 誰かお願い。

786 :デフォルトの名無しさん:2009/02/19(木) 09:28:22
おまえがかけ

787 :デフォルトの名無しさん:2009/02/24(火) 11:57:47
>>785
イラネ

788 :デフォルトの名無しさん:2009/02/24(火) 12:11:21
で、新式のGCは速いのかね?

789 :デフォルトの名無しさん:2009/02/24(火) 12:16:30
>>788
その「速い」って言う定義をまず聞こうか

790 :デフォルトの名無しさん:2009/02/24(火) 17:23:56
「速い」に定義が必要なのか?速いは速いだろ。四次元の世界なら話は別だが。

791 :デフォルトの名無しさん:2009/02/24(火) 17:56:32
まだ参照が残ってるのにGCされちまった。めちゃはやすぎ。

792 :デフォルトの名無しさん:2009/02/24(火) 18:08:26
4次元GCです

793 :デフォルトの名無しさん:2009/02/24(火) 18:18:17
あなたって早いのね

794 :デフォルトの名無しさん:2009/02/24(火) 19:13:07
>>790
じゃあ速いよ

795 :デフォルトの名無しさん:2009/02/24(火) 20:11:27
>>790
レイテンシとスループットがどうたらこうたら

796 :デフォルトの名無しさん:2009/02/25(水) 01:20:21
遅いよりいいだろ

797 :デフォルトの名無しさん:2009/02/25(水) 02:09:28
>>795
GCにレイテンシとスループットは関係ないだろ。恥かかないようにGCの仕組みをちゃんと勉強してから発言したほうがよかったね。

798 :デフォルトの名無しさん:2009/02/25(水) 02:31:58
>>788
それでは、百式のGCの威力を聞こうか

799 :デフォルトの名無しさん:2009/02/25(水) 02:38:49
>>797
似たような概念(最大停止時間と効率)ならあるだろ。それくらい読み替えてやれよ。


800 :デフォルトの名無しさん:2009/02/25(水) 03:27:15
いや、それ以前に普通にGCの性能評価に関する用語でスループットとかレイテンシて
使われるだろ。スループットは、GC全体にかかる時間、レイテンシは1回のGCの停止時間
に関する指標ね。

801 :デフォルトの名無しさん:2009/02/25(水) 10:05:54
>>800
> スループットは、GC全体にかかる時間

おいおいw



802 :デフォルトの名無しさん:2009/02/25(水) 10:26:25
>スループットは、GC全体にかかる時間、レイテンシは1回のGCの停止時間 に関する指標ね。

そうなの?
それならソース出してよ

803 :デフォルトの名無しさん:2009/02/25(水) 11:18:08
>>802
ttp://www.research.ibm.com/ismm04/slides/detlefs.pdf

G1-GCは
 Garbage-First: Low Latency, High Throughput Garbage Collection
だそうだよ。ソースはIBM。

804 :デフォルトの名無しさん:2009/02/25(水) 12:12:35
Throughputってのはこなす量であってかかる時間じゃない。
>>800の語彙力に絶望。

805 :デフォルトの名無しさん:2009/02/25(水) 12:30:58
まあ一連の無駄な流れを作った>>794は真っ先にGCされるべき存在だな。

806 :デフォルトの名無しさん:2009/02/25(水) 12:31:46
すまん、>>794じゃなくて>>797

807 :デフォルトの名無しさん:2009/02/25(水) 12:34:33
>>805-806

これら 2つ のレスは新式のGCが起動して既に再利用されています。

808 :デフォルトの名無しさん:2009/02/25(水) 12:36:45
>>797
似たような概念(最大停止時間と効率)ならあるだろ。それくらい読み替えてやれよ。


809 :デフォルトの名無しさん:2009/02/25(水) 12:41:25
>>805
人のせいにしちゃいかんよ。恥ずかしさを隠し切れずにアンカーをつけ間違えてるしねぇ

810 :デフォルトの名無しさん:2009/02/25(水) 13:07:36
>>804
こなす量ってのは、GC全体にかかる時間に関するよね?

811 :デフォルトの名無しさん:2009/02/25(水) 13:09:28
> スループットは、GC全体にかかる時間、
は間違い。以上。


812 :デフォルトの名無しさん:2009/02/25(水) 13:11:37
いや、それ以前に普通にGCの性能評価に関する用語でスループットとかレイテンシて
使われるだろ。スループットは、GC全体にかかる時間、レイテンシは1回のGCの停止時間
に関する指標ね。

813 :デフォルトの名無しさん:2009/02/25(水) 15:13:45
>>811
ちなみに正解は?

814 :800:2009/02/25(水) 16:04:33
>>804
いや、GCのスループットが上がる=GCの総停止時間(アプリケーション全体を通しての停止時間の和)
が減る、だから間違ってないよ。ぐぐってGC関係の論文やGC研究者での用語の使われ方でも調べてみたら?
あと、スループット=GCの総停止時間(これなら確かに間違いだ)と言ったわけではなく、GCの総停止時間
に関する指標と言ったわけで、その辺勘違いしないでくれ。

815 :800:2009/02/25(水) 16:08:49
補足すると、
>スループットは、GC全体にかかる時間、レイテンシは1回のGCの停止時間
>に関する指標ね。
の「に関する指標ね」はGC全体にかかる時間、1回のGCの停止時間の両方にかかってるってこと。
書き方がまずかったのは認めるが。

816 :800:2009/02/25(水) 16:20:24
ちょっと訂正
>>814

>いや、GCのスループットが上がる=GCの総停止時間(アプリケーション全体を通しての停止時間の和)
>が減る

>いや、GCのスループットが上がる=GCによって消費される時間(アプリケーション全体を通してGCによって
>消費される時間。ライトバリアなどのGCによるオーバーヘッドを含む)が減る
で。GCに付随した処理のオーバーヘッドを失念していた。

817 :デフォルトの名無しさん:2009/02/25(水) 20:21:11
GCを語るスレはここですか?

818 :デフォルトの名無しさん:2009/02/25(水) 20:28:45
というより馬鹿な人が無知を晒すスレのような気もする

819 :デフォルトの名無しさん:2009/02/25(水) 21:18:14
>>818
それであなたはどれぐらい馬鹿なんですか?

820 :デフォルトの名無しさん:2009/02/25(水) 21:25:28
>>797と同じくらいかな

821 :デフォルトの名無しさん:2009/02/25(水) 21:27:14
>>820
レイテンシだもんねぇ

822 :デフォルトの名無しさん:2009/02/25(水) 21:27:16
どうやら俺の出番のようだな。

823 :デフォルトの名無しさん:2009/02/25(水) 22:10:39
このスレが荒れるとき、必ずアルゴ君がかかわってるわけだ。

824 :デフォルトの名無しさん:2009/02/25(水) 23:06:26
盛り上がっているけど次世代の話じゃないね

825 :デフォルトの名無しさん:2009/02/25(水) 23:32:28
jdk7 build48
http://download.java.net/jdk7/binaries/
http://www.java.net/download/jdk7/changes/jdk7-b48.html

AWT関連のバグ取りが多い。

826 :デフォルトの名無しさん:2009/02/26(木) 06:07:10
>>823
アルゴ君乙

827 :デフォルトの名無しさん:2009/02/27(金) 18:01:31
jdk7 build49
http://download.java.net/jdk7/binaries/
http://www.java.net/download/jdk7/changes/jdk7-b49.html

JIT、GC関連のバグ取り

828 :デフォルトの名無しさん:2009/03/03(火) 23:01:08
>>803
GCに対する新しい改善が入ったの??
それって、昔、みたGC Firstのことかな?

そんときみたドキュメントだと積極的にGCを行うことで
実行のつっかかりをなくすというものだったと思う。
で、トータルのGC時間は微妙に延びるというある意味当たり前な話だった。

それはともかく、jdk7のスペックはいつ固まるの?

829 :デフォルトの名無しさん:2009/03/07(土) 14:42:58
jdk7 build50
http://download.java.net/jdk7/binaries/
http://download.java.net/jdk7/changes/jdk7-b50.html

NIO2が統合。

830 :デフォルトの名無しさん:2009/03/14(土) 23:02:11
JavaのGUIといえばSwingだと思うんだけど、
FXのおかげでこれから廃れていく傾向にあるの?
それとも住み分け?

831 :デフォルトの名無しさん:2009/03/14(土) 23:28:35
>>830
仮に住み分けだとすると、どういったところを分けることになる?

832 :デフォルトの名無しさん:2009/03/14(土) 23:36:54
>>831
いや、ぜんぜん分からないんだけどさ、Javaの勉強を始めたわけさ。
したらGUIが弱いって言うじゃない?
でもまあ、Swingの勉強するかと思ってたのね。
そしたらJavaFXが次世代のGUI!みたいな記事をネットでみたから、
Swingの勉強しないで情報少ないけどJavaFXをがんばったほうがいいのか?
と思ってきいてみたのよ。これから勉強するのにいきなり時代遅れじゃちょっと。

833 :デフォルトの名無しさん:2009/03/14(土) 23:44:45
JavaFXはSwingベース

834 :デフォルトの名無しさん:2009/03/14(土) 23:49:35
>>833
あー、JavaFXの簡単な文法でSwingのクラスを呼ぶのか!
Swing頑張る(`・ω・´)

835 :デフォルトの名無しさん:2009/03/15(日) 00:45:25
>>832
自分もAdobeのFlex、MSのWPFをやったあとJavaでGUIをやってみようかと思ったけど、Swingにちょっとしり込み。
うーん、とりあえず両方勉強しておけば間違いないのかなぁ。
自分はJavaFXから勉強してま。

836 :デフォルトの名無しさん:2009/03/21(土) 01:05:03
す。

837 :デフォルトの名無しさん:2009/03/22(日) 23:00:31
jdk7 build51
http://download.java.net/jdk7/binaries/
http://download.java.net/jdk7/changes/jdk7-b51.html

G1GC関連のbugfix等

838 :デフォルトの名無しさん:2009/03/25(水) 20:11:47
jdk7のコントロールパネルが縦にビヨーンって長いのって・・・・俺・・・・・・だけ?

結構前からなんだけど、直る気配がないから俺だけなのかな、って・・・・

839 :デフォルトの名無しさん:2009/04/01(水) 23:35:44
jdk7 build52
http://download.java.net/jdk7/binaries/
http://download.java.net/jdk7/changes/jdk7-b52.html

なんもなし?

840 :デフォルトの名無しさん:2009/04/03(金) 05:40:51
http://journal.mycom.co.jp/news/2009/04/02/030/

841 :デフォルトの名無しさん:2009/04/03(金) 10:47:15
>>840
それは、Sunだけが悪いんじゃなく、疑心暗鬼にさせたMSにも責任あり。
Sunは、Javaの互換性に腐心している。
Harmonyって、OpenJDKと比べて何が違うのかな?

それはそうと、Java7は俺も今のままじゃ要らない。
仕様決めがgdgd過ぎる。船頭多くして船山に登る状態。

842 :デフォルトの名無しさん:2009/04/03(金) 12:24:42
>>841
えーと。

Sun が、JCK へのアクセスを制限してる、って話が主眼だと思うのだが。
JCK へのアクセス制限は、Java の処理系を本気で実装しようとしてる者たちを
この 10 年以上苛立たせてきた問題。

JCK は、むしろ「Java の互換性を保って」実装するためには必須なもの。

JCK へのアクセス制限が、例の MS の「Java に塩を混ぜたれ」戦略と、
どうつながるのかわからんのだが、説明してもらえる?

843 :842:2009/04/03(金) 12:28:18
あ、俺は Sun の商売上のぎりぎりの戦略なんだろうなとは思ってる。
正しいか間違ってるか、なんて、結果が出たあとでもわからんな、とも。

844 :デフォルトの名無しさん:2009/04/03(金) 12:40:11
>>843
んーっと、
>この条項があるために互換試験キットを使ったソースコードに同条項を追加する必要があり、
>この条項はOSSライセンスとは相容れない内容になっているため

って、ちゃんと互換性を保ってますよって制約になってると思うんだ。
JCK通したのが、どの状態のものか作る側に制約を掛けている訳で
JCK通した後、JCK通らないように改変したら作成者側に責任がでる、と。
なもんで、MSとの争いで、こんなことするようになったのかなぁ、と思った。
事情はよくしらんので、MSJVM問題前からこれがあったんだったら、すんません勘違い。

845 :デフォルトの名無しさん:2009/04/03(金) 12:47:52
> JCK通した後、JCK通らないように改変したら作成者側に責任がでる、と。
記事内の「使用分野制限条項」ってのがそうなんか?

846 :デフォルトの名無しさん:2009/04/03(金) 15:26:09
>>842>>844
お前等想像じゃなくてちゃんと理解して書けよ。
'Field of Use' clause (FOU)
はSunが非公開にしているから、詳細なことは分からないが、
基本的なことはいろいろな人が解説している。
>>845
FOUはそういうものではない。「利用領域」を制限しているだけなので。




847 :デフォルトの名無しさん:2009/04/03(金) 16:03:48
ああ、原子力発電所で使うなとか、人命に関わる部分で使うな、とか?
(でも火星では使っていい・・・とか)

848 :デフォルトの名無しさん:2009/04/03(金) 19:15:37
Sunはオープンソースをあまり上手く活用できてないな。
エンドユーザには好感を持って貰えるようになったが、
OSS業界人には反感を買うようになった印象がある。
証券コードをJAVAにしたりとかね。

849 :デフォルトの名無しさん:2009/04/03(金) 20:06:15
法務部の考えがIPを守る方向なんだろうな。

850 :デフォルトの名無しさん:2009/04/03(金) 21:12:35
来週から Sun JDK じゃなく、IBM JDK になるが、何か変わるかな。

851 :デフォルトの名無しさん:2009/04/03(金) 21:25:52
LotusやRationalのようにSunブランドが残る可能性はないだろうか?

852 :デフォルトの名無しさん:2009/04/03(金) 22:07:05
ていうか、IBM て自前で JDK の別実装持ってなかったっけ?
OpenJDK でマージされたんだっけ?

853 :デフォルトの名無しさん:2009/04/03(金) 22:11:16
まだやっとるわい。マージするわけねえ
http://www.ibm.com/developerworks/java/jdk/aix/service.html

854 :デフォルトの名無しさん:2009/04/03(金) 22:13:32
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

855 :デフォルトの名無しさん:2009/04/03(金) 22:21:56
IBMになったとたん、OpenJDKのライセンスがCPLになったりしてw

856 :デフォルトの名無しさん:2009/04/04(土) 01:45:58
>>855
OpenJDKそのものが中止になりそうだな

857 :デフォルトの名無しさん:2009/04/04(土) 02:52:46
もうちょっとマシな事をいえないのかねぇ

858 :デフォルトの名無しさん:2009/04/04(土) 04:38:49
J 冗
D 談
K か!

859 :デフォルトの名無しさん:2009/04/04(土) 05:54:54
つまんねー

860 :デフォルトの名無しさん:2009/04/04(土) 06:12:15
>>851
Sun Bladeみたいな感じで残るんだろうね。
Microsystemsは消えるか。

861 :デフォルトの名無しさん:2009/04/04(土) 07:09:56
jdk7 build53
http://download.java.net/jdk7/binaries/
http://download.java.net/jdk7/changes/jdk7-b53.html

Summary of changes の書式が変わった。
G1GCのバグ取り進行中。

862 :デフォルトの名無しさん:2009/04/04(土) 07:56:27
>>852
少なくともJavaVMはSunとIBMで別実装。
SunとIBMのえろいひとが同じ職場でJDKを作成するとどれだけのものができるか期待している。

863 :デフォルトの名無しさん:2009/04/04(土) 08:04:03
>>862
あのIBMがそんな無駄を放置するかな?
余剰人員として半分がリストラされるだけじゃね?

864 :デフォルトの名無しさん:2009/04/04(土) 11:42:47
>>863
人員はともかく、IBMの特許技術をSunJVMに組み込めるなら期待できそうだな。

865 :デフォルトの名無しさん:2009/04/04(土) 13:51:35
>>863 一時期、異なるVM実装のプロジェクトを商用で3つ、研究用であと2つ抱えてたIBMだからな。

866 :デフォルトの名無しさん:2009/04/04(土) 15:13:52
http://wassr.jp/user/androdizaurus/statuses/4P7PEDXnsV

組み込み用の実装とか、jdk
もう M$ で 作っちゃえそうな mjk
そんな気だるい午後の昼下がりYO

867 :デフォルトの名無しさん:2009/04/04(土) 21:55:59
一番稼いでるJDKはBEAのJDKだろうな

868 :デフォルトの名無しさん:2009/04/04(土) 21:58:44
単体だとそうなのかな
IBM JDKもWASにバンドルされてるからその利益の一部をカウントしたら
引けをとらないと思うが

869 :デフォルトの名無しさん:2009/04/05(日) 01:53:45
SunはOracleに買われた方がよかったんじゃね?

870 :デフォルトの名無しさん:2009/04/05(日) 01:55:46
G1GCはユーザにstop-the-worldを気づかせないくらいにはリアルタイムなGCなのかな?
フルGCを含めない場合の処理性能は、従来型の方が良さそうな気がするが大丈夫かな。

871 :デフォルトの名無しさん:2009/04/05(日) 02:33:09
>>869
Oracleにしてみればハードウェア部門が余計なんじゃない?

872 :デフォルトの名無しさん:2009/04/05(日) 04:42:43
gdgdぶりに嫌気が差して一年ほど追ってなかったけど
まだgdgdやってるみたいね。

873 :デフォルトの名無しさん:2009/04/05(日) 09:35:53
>>871
ハードウェアを持ってフルスタックになったらいいんじゃね?

874 :デフォルトの名無しさん:2009/04/05(日) 10:48:12
日立も自前JREで、GCストップを軽減とか言ってたな

875 :デフォルトの名無しさん:2009/04/05(日) 16:45:03
>>873
ないない。
ソフトウェアに特化してるからこその暴利なんだよ。
>>874
国産と言うだけで、凄く小手先対応っぽい気がする・・・

876 :デフォルトの名無しさん:2009/04/05(日) 16:52:07
自前っつっても基本はライセンス受けて貰ったコードをちょっと変更して
コンパイルしただけでしょ。特に Win で完全に自前な JavaVM って
Netscape に乗ってた Symantec とか MS JVM とか、JDK1.0〜1.1 頃まで
さかのぼらないとないような。

877 :デフォルトの名無しさん:2009/04/05(日) 17:16:29
>>875
ありえん話じゃないだろう。Oracle専用ハードは昔からいくつか話が出てるし。
今ならHPと組んだHP Oracle Database Machine、一昔前はSunと組んだRawIronとか。

Teradataみたいにならないよう気をつけさえすれば。

878 :デフォルトの名無しさん:2009/04/05(日) 17:35:49
>>877
Exadataって名前がTeradataに似てて不吉だなw

879 :デフォルトの名無しさん:2009/04/05(日) 20:48:43
java 7は、とりあえずこのまま出してしまうのか、
プロジェクト刷新してやりなおしなのか。

880 :デフォルトの名無しさん:2009/04/05(日) 21:07:19
7は欠番にして、8で仕切り直しがいいな。
互換性を犠牲にして、新しい言語にしてもいい。

そして、日付はlongで・・・・

881 :デフォルトの名無しさん:2009/04/05(日) 22:56:58
互換性犠牲にして新しい言語なら、Scalaでいいんじゃない?

882 :デフォルトの名無しさん:2009/04/06(月) 08:57:50
>>881
同感。Java言語に機能追加していくくらいならもう別言語でやってくれと思う.
多言語向けにJVMに機能追加していくのはありだと思うが.

883 :デフォルトの名無しさん:2009/04/06(月) 09:32:33
CLI みたいになってくのかなー

884 :デフォルトの名無しさん:2009/04/06(月) 12:23:31
>>882
同感
Java言語で物足りない人はGroovyみたいなのを作ればいい

885 :デフォルトの名無しさん:2009/04/06(月) 16:35:33
いらない人は1.4使いつづければいいじゃん
そもそもこのスレに来る必要すらない


886 :デフォルトの名無しさん:2009/04/06(月) 23:46:01
しかしJavaって5.0からC#の後追いで
ロクな機能ないね。

6.0でC#2.5ぐらいのレベルだから7.0がでてもC#4との差は歴然でしょ
.NET/Mono が言語的には箱庭としては攻守最強だろう。



887 :デフォルトの名無しさん:2009/04/06(月) 23:48:07
> 言語的には箱庭としては攻守最強

888 :デフォルトの名無しさん:2009/04/07(火) 00:18:53
>>885
Java言語自体に機能追加するのがいらないという話でJVMの改善は
まだまだやるべきだしやライブラリやフレームワークの整備が
不要だといってる訳じゃない。そこはちゃんと区別して考えてくれ。

889 :デフォルトの名無しさん:2009/04/07(火) 04:23:28
>>886
言語的には今のJavaより良いのが使いたい人たちは
Scala試してみたり色々やってるよ。Scalaなら言語仕様的にはC#(3.0)よりも
強力と言ってもいいし。

890 :デフォルトの名無しさん:2009/04/07(火) 04:27:09
ちなみに、5.0からC#の後追いってのは部分的にしか正しく無い。
Genericsが入ったのはJavaの方が先だし、Javaのtypesafe enumは
C#のenumよりはるかに強力だし。Genericsの機能そのものに関しては、
variance以外に関してはC#の方が強力だとは思うけども。

891 :デフォルトの名無しさん:2009/04/07(火) 05:52:19
.NET/Mono が言語的には箱庭としては攻守最強だからに決まってんじゅあん。バカかおまえ?w

892 :デフォルトの名無しさん:2009/04/07(火) 06:39:08
おまえがな

893 :デフォルトの名無しさん:2009/04/07(火) 07:57:52
Javaのenumはenumというよりも機能制限クラスって感じで気持ち悪い

894 :デフォルトの名無しさん:2009/04/07(火) 08:04:32
俺は enum が出来るまではよく手作業で同じような定数クラス (private コンストラクタ
+ public static final ないくつかのインスタンス) を作っていたから、switch や
== が保証されて toString(), valueOf() が暗黙的に付いたのはありがたかったよ。

895 :デフォルトの名無しさん:2009/04/07(火) 08:47:12
実際enumに抽象メソッド書いたりしてるような奴いるの?

896 :デフォルトの名無しさん:2009/04/07(火) 08:52:27
書くでしょ。

897 :デフォルトの名無しさん:2009/04/07(火) 08:52:33
いるよん。

898 :デフォルトの名無しさん:2009/04/07(火) 08:56:18
後で誰かが勝手に増やしたりしないからenumなんであって
それならswitchでいい気がするんだけど

899 :デフォルトの名無しさん:2009/04/07(火) 09:08:40
ぬほんごでおk

900 :デフォルトの名無しさん:2009/04/07(火) 09:11:05
>>898
switch自体いらないよな。男ならifでいいだろ

901 :デフォルトの名無しさん:2009/04/07(火) 09:16:31
ifだとfall throughできないからswitchの完全な置き換えにはならん。

902 :デフォルトの名無しさん:2009/04/07(火) 10:04:38
>>898
値を割り振る必要がないからenumだろ。
後で誰かが増やすとか減らすとか、関係ないだろ。

903 :デフォルトの名無しさん:2009/04/07(火) 20:18:08
>>884
GroovyはRubyユーザーにも評判いいね。
JRubyなんてのもあるがGrailsというGroovyベースのRuby on Railsもどきが素晴らしい。

904 :デフォルトの名無しさん:2009/04/08(水) 02:01:44
>>901
switchはsyntax sugarとして欲しいが、fall throughは要らんなぁ。
つか、あれは害悪だ。
caseに条件を複数列挙できればそれで十分。

905 :デフォルトの名無しさん:2009/04/08(水) 08:30:56
caseに条件を複数列挙できないから、fall throughが要るんじゃないのか?

906 :デフォルトの名無しさん:2009/04/08(水) 08:49:25
case 1: case 2: case 3: hoge123(); break; //caseの中身を書かなければフォールスルー可
//case 4: hoge4(); コンパイルエラー
case 4: hoge4() goto case 5; //明示的に行き先を指定すればおk
case 5: break;
C#はこういうとっても意図的な仕様

907 :デフォルトの名無しさん:2009/04/08(水) 08:54:39
警告とSuppressWarnings("fallthrough")で goto case以外はある程度代用可能

908 :デフォルトの名無しさん:2009/04/08(水) 09:19:40
>>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

909 :デフォルトの名無しさん:2009/04/08(水) 12:32:26
>>908
ほんとに高速化すんの?それで。
あと、用途がそれなら、fallthrough不要でいい。

910 :デフォルトの名無しさん:2009/04/08(水) 12:37:21
>>908
それ、fall throughがあったら元のループと違う挙動なんだが・・・・

911 :デフォルトの名無しさん:2009/04/08(水) 12:46:38
つ Duff's device

912 :910:2009/04/08(水) 12:48:58
スマンもう少し書く。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的な使い方が欲しいなら、別の構文があった方がいいと思うんだわ。

913 :デフォルトの名無しさん:2009/04/08(水) 13:04:25
if と while 以外は利便性で導入されてるものだろ。今時うまいこと switch のジャンプ
テーブル使っても炊飯ジャー用のマイコン向けでもなければ意味はない。

914 :デフォルトの名無しさん:2009/04/08(水) 13:59:16
>>912
> 高速化のためだけだったら別の手段がある
たとえば?

その下のやつはダメだろ。
量増えたら読めたもんじゃないし、コード肥大化のせいで低速化する可能性あるし。

915 :デフォルトの名無しさん:2009/04/08(水) 14:07:59
そもそも break がないから挙動違うしな

916 :デフォルトの名無しさん:2009/04/08(水) 14:24:36
>>913
この辺の最適化は低レベルインストラクションを持つ
VMインタプリタでは必須です。
まだまだ論文が書かれているような状況です。


917 :デフォルトの名無しさん:2009/04/08(水) 15:14:26
>>914
その最適化のためなんだから、気にするほどのこたぁない。
増えるのはコードサイズだけでしょ。hotspotが効くまでずれこみがあるだろうが。
それに、こんな細かいチューニングがマイクロベンチならともかく実アプリで効くと思うか?
>>908 がGoogleのバックエンド書いてるとかならスマン。効くと思う。そのスケールの処理なら。

でも、Javaを使っている層全体ではswitchの誤用の害の方が多いと思うなぁ。
大抵の用途では、break;を書かなきゃ駄目で、それを書くことは冗長とも言えるし。

918 :デフォルトの名無しさん:2009/04/08(水) 15:44:39
>>917
例えば >>908 だとJITコンパイラによって hoge() がインライン展開されるが
>>912 だとインライン展開すると展開後のコードがでかすぎてインライン展開を断念する可能性がある。
>>908>>912 は等価とはいえない。

気にするほどの事がないってんなら、そもそも forループでいいわけで。

919 :デフォルトの名無しさん:2009/04/08(水) 15:53:00
>>917
> Javaを使っている層全体ではswitchの誤用の害の方が多い
JavaがC言語ライクなプログラミング言語だって視点でみると
breakなしにするとコード読むときにミスの元になるぞ。

C#もD言語もfallthroughしない場合はbreak書かせるでしょ。

920 :デフォルトの名無しさん:2009/04/08(水) 16:02:48
>>918
俺はforでいいと思うよ。その方がコード短いし。
>>919
やっぱ、switchの挙動を変えるのは問題ありか・・・
んじゃ、fall-through無しのオプションを指定できるようにする・・・とか。
それじゃ間違う連中はその指定の方を忘れるよな・・・・

俺・・・始めにC言語設計した奴の問題だと思うわ・・・
アセンブラからあがってきたらbreakを書くことに疑問はないと思うけど
構造化プログラミングから入った奴とかは、面倒だなって思ってると思う。
そもそも、"switch"って単語が「処理を選ぶ」という意味だと思わせるのがよくないと思う。
Pascalのcase文やVBのSelect文と同じ挙動をするのがあればいいんじゃないか?

921 :デフォルトの名無しさん:2009/04/08(水) 16:15:33
そろそろウザイ

922 :デフォルトの名無しさん:2009/04/08(水) 17:37:53
「Javaがこんな言語だったら」という仮定の話は、そろそろ終わろうぜ。
すでに書かれているコードの挙動が変わるような仕様変更はありえないんだし。

923 :デフォルトの名無しさん:2009/04/08(水) 19:41:36
Genericsが型情報を持たないのは失敗だったな。
T.class.newInstance() とか書けたら幅が広がったろうに。

924 :デフォルトの名無しさん:2009/04/08(水) 21:08:49
1.4のバイトコードと互換、と言った時点で終わってた。

925 :デフォルトの名無しさん:2009/04/09(木) 01:04:58
あれは Collection みたいな汎用コンテナ型クラスを作るためのものだと割り切っている。

926 :デフォルトの名無しさん:2009/04/09(木) 06:09:43
割り切るも何も、多相型のための仕組みとしては十分でしょ。
メタプログラミングのための仕組みとごっちゃにするから話がややこしくなるだけで。

927 :デフォルトの名無しさん:2009/04/09(木) 12:41:40
不十分。だからこそ、Google Collectionsとか出されてしまう訳で。

928 :デフォルトの名無しさん:2009/04/09(木) 12:51:18
ジェネリック型の配列作れないのがめんどい。

929 :デフォルトの名無しさん:2009/04/09(木) 13:06:40
>>927
Google Collections って、genericsが不十分だからできたっつーより
java.util の Collection API が貧弱なのが原因なのでは?

930 :デフォルトの名無しさん:2009/04/09(木) 13:17:52
>>927
よく考えてみろよ。
Genericsでいえば、サンがやっているのはコレクション・フレームワークを作ることじゃなくて言語仕様を定めることだったんじゃないのか?
その仕様に基づいてグーグルはコレクションを作ったわけでいわば「後出しじゃんけん」だし、サンに文句をいうのはお門違いだろうな。

931 :デフォルトの名無しさん:2009/04/09(木) 14:45:15
>>929
もちろんその意味合いもあるけど、>>923が書いているようなのも入ってる。
言語レベルのサポートがないから、あんまりきれいな構文にはならないけど。

>>930
サンはどうか知らないけど、後出しじゃんけんならJCPの方がうまいよ。

932 :デフォルトの名無しさん:2009/04/09(木) 15:04:43
>>931
入ってたっけ? クラス名教えて

933 :926:2009/04/09(木) 15:28:42
だから、「多相型としては」十分と書いたんだがなあ。T.class.newInstance()
がしたいってのはどちらかというとメタプログラミングに関する要求であって、
「型システムに関する拡張としては」Java Genericsは十分な能力を持ってると思うよ。

934 :デフォルトの名無しさん:2009/04/09(木) 15:28:55
>>932
俺の記憶違いだった。すまん。

Google Collectionsのは任意の型のnew(T.class.newInstance)じゃなくて、コレクション限定のやつ。
Map<String, List<String>> mapOfLists = Maps.newHashMap();

ttp://codezine.jp/article/detail/2397?p=2


935 :デフォルトの名無しさん:2009/04/09(木) 15:43:13
>>933
CLR(C#のVM)は型情報を実行時に利用してるし、
Scala見たくJVMを利用する言語は
バイトコードに実行時に型情報がないせいでオーバーヘッドを生じてる。

936 :935:2009/04/09(木) 15:50:53
訂正。

> バイトコードに実行時に型情報がないせいでオーバーヘッドを生じてる。

> バイトコードに型情報がないせいで実行時にオーバーヘッドを生じてる。
です。

何暑くなってんだ俺。冷却期間取るよ。

937 :デフォルトの名無しさん:2009/04/09(木) 16:59:42
>>934
そんなのユーティリティレベルの話じゃないか…
それが実現できるのはJavaのGenericsに(十分とはいえないまでも)
型推論の機構があるからで、それを活用してないjava.utilのCollection APIに
文句言うならともかくGenericsに文句言うのは100年早いな

938 :デフォルトの名無しさん:2009/04/09(木) 18:18:43
そもそもGoogle Collectionで満足なら、
言語仕様にも満足しているはずだ。

939 :デフォルトの名無しさん:2009/04/09(木) 18:22:12
こういうの作ればいいだけの話なんだよな
http://s2container.seasar.org/2.4/s2-tiger/ja/apidocs/org/seasar/framework/util/tiger/CollectionsUtil.html

940 :デフォルトの名無しさん:2009/04/09(木) 18:33:23
サンのCollectionはGenericsより前に使ったものだからグーグルの後出しじゃんけんと比べられる代物じゃないよなあ。
グーグルはすごい会社だって言う三流ITライターの戯言に君はまんまと乗せられちゃってるんじゃないの?

941 :デフォルトの名無しさん:2009/04/09(木) 18:45:01
Javaの機能=必要な機能、みたいな人が多いのに驚いた。
それ以外の人はもう他の言語に移ったのか。

942 :デフォルトの名無しさん:2009/04/09(木) 18:47:58
Java Collection Frameworkは出てきたときから古くさかった
その前からJGLがすでにあったわけだから

943 :926:2009/04/09(木) 19:03:27
>>935,936
それはもちろん知ってるよ。言いたかったのはオーバーヘッドの話ではなく、
型システムの話。もちろん、Java Genericsはerasureで実装されてるせいで
オーバーロードに制限あったりとか、型システムに関係する部分にも一部制限
かかってるけど、その辺はまあ我慢できるレベルだと思ってる。

944 :デフォルトの名無しさん:2009/04/09(木) 19:13:16
一応、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;
}

945 :デフォルトの名無しさん:2009/04/09(木) 19:26:12
JAVA Genericsの実行時型情報は、たしかインスタンスを持ってれば解決できるから、
必要な人は型問い合わせようのインスタンスを持たせるってのがセオリーだった気がした。
>>944みたく型のインスタンスではなくて、直接Classのインスタンスを持たせてもいいけど。
英語の記事読まないで三流ライターの戯言ばかり読んでると、日本独特の馴れ合いに引きずりこまれちゃって出てこれないくなるよ。

946 :デフォルトの名無しさん:2009/04/09(木) 19:48:16
>>945
何言ってるんだ?インスタンスから型引数は取得できないよ
クラスやフィールド型、メソッドの引数型や返値型からは取得できる

947 :デフォルトの名無しさん:2009/04/09(木) 19:54:31
>>944
何の意味がある?こっちの方がマシだろ

Map<String, Integer> map = newHashMap();

public static <K, V> HashMap<K, V> newHashMap() {
 return new HashMap<K, V>();
}

948 :デフォルトの名無しさん:2009/04/09(木) 19:58:46
>>944は型情報を持ったHashMapを作る例だと

949 :デフォルトの名無しさん:2009/04/09(木) 20:04:50
>>948
理解した

public class MyMap<K, V> extends HashMap<K, V> {
 private Class<K> keyType;
 private Class<V> valueType;

ってことか

950 :デフォルトの名無しさん:2009/04/09(木) 20:12:14
細かいところが分かってないね。
ていうかGenericsを語るなら当然知ってないといけないところなんだけどね…

http://codezine.jp/article/detail/2397?p=2
ではファクトリーメソッドをマンセーしてるみたいだけど。

951 :デフォルトの名無しさん:2009/04/09(木) 20:35:46
キャストって意外とコストって高いのか安いのか微妙だな。
マイクロベンチでキャストの有る無しの差を比べてみたが、
10億回キャストしても手元の環境だと300msくらいしか増えなかった。
(試したのはClientVM、ServerVMだと最適化されすぎて0msになったw)

952 :デフォルトの名無しさん:2009/04/09(木) 20:36:20
genericsよりお前らのいってることが分からない
みんな端折りすぎなんだよ

953 :デフォルトの名無しさん:2009/04/09(木) 20:44:42
>>951
お前のコスト安はどこからだよ!
俺、明日からキャスト沢山振りかけて食べることにするわ

954 :デフォルトの名無しさん:2009/04/09(木) 21:07:33
閑話休題。

ごめん、JAMってどうなった?JSR-277は破綻したんだよな?
.jamアーカイブそのものが無くなったの?

955 :デフォルトの名無しさん:2009/04/09(木) 21:21:06
jsr277は死亡、jsr294だけJava7に入る

956 :デフォルトの名無しさん:2009/04/09(木) 22:40:34
JSR294だけでどうやってクラスパスの衝突を避けるの?
JAM(というかMODULE-INFディレクトリ)はJSR277の仕様でしょ?
結局の所、最新のjarを落としてきて後方互換性を盲信するのと何が違うんだろ。

957 :デフォルトの名無しさん:2009/04/09(木) 23:20:43
jsr277がjsr294に取り込まれたんじゃないの?

958 :デフォルトの名無しさん:2009/04/10(金) 06:44:46
>>951
知らないの?VM上ではキャストはコスト高いよ。
特にループ内部にキャストのコードを入れるときは無駄が多くなる。

959 :デフォルトの名無しさん:2009/04/10(金) 07:30:01
IBMとapacheがOSGiに流れてる状況で、JSR277が出てきてもまとまらないよなあ。

960 :デフォルトの名無しさん:2009/04/10(金) 12:19:35
ヒント:IBM=apache

961 :デフォルトの名無しさん:2009/04/10(金) 20:25:31
どうでもいい言語機能よりさっさと native2ascii を捨てろよ。
UTF-8 を標準にしときゃ native2ascii かけた既存のプロパティファイルと互換保てるだろ。

962 :デフォルトの名無しさん:2009/04/10(金) 21:04:39
XMLプロパティか

963 :デフォルトの名無しさん:2009/04/10(金) 21:22:14
てかさ、Propertiesクラスそのものを非推奨にしようよ。
あれ何でHashMapベースなの?Mapをコンポジットしろよ。
出力した時は普通LinkedHashMapかSortedMapの動作を期待するだろ。

964 :デフォルトの名無しさん:2009/04/10(金) 21:37:42
Propertiesはextends Hashtableだが。

965 :デフォルトの名無しさん:2009/04/10(金) 21:40:15
ほぼどうでもいい重箱の隅だと思うのだが。

966 :デフォルトの名無しさん:2009/04/10(金) 21:42:00
どうでもいいネタにふさわしいツッコミだと思うのだが。

967 :デフォルトの名無しさん:2009/04/10(金) 21:43:07
スレ汚ししたいなら他所でどうぞ。

968 :デフォルトの名無しさん:2009/04/10(金) 21:44:01
他所いけってさ>>961

969 :デフォルトの名無しさん:2009/04/10(金) 22:47:20
SEIのXMLを利用できるAPIを総点検中なんだが、
XMLEncoder/Decoderがひっそりと enum に対応してた。
どっかにアナウンスがあったっけ?

970 :デフォルトの名無しさん:2009/04/10(金) 23:24:28
jdk7 build54
http://download.java.net/jdk7/binaries/
http://download.java.net/jdk7/changes/jdk7-b54.html

awt関連のバグ取り。

971 :デフォルトの名無しさん:2009/04/14(火) 11:52:47
大規模なシステムほどJAVAで組まれてると言われるけど、
実際はけっこーCも多いよね。
結局大量の処理をする場合Cの速度が優位になっていく。
事実Cで組まれたシステムが第一線で使われてるケースもかなり多い訳で。
JAVAがそれに対抗しろとは言わないが、汎用性ではJAVA・・でもやっぱシステム組んでもらえるならCがいいという構図は
なかなか変わりそうにないなぁと思った

972 :デフォルトの名無しさん:2009/04/14(火) 15:58:42
ベンチマークだと、速度はともかくメモリ消費量は1桁違うみたいだね
ttp://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=java&lang2=gcc&box=1


973 :デフォルトの名無しさん:2009/04/14(火) 16:30:05
そりゃぁ、年金から年間800億円も融通してもらえるような超巨大企業なら
工数度外視でCで開発したりできるだろね。
とにかくガバガバ金つかえ、納期気にすんな、人月?なにソレ?って漢字で
何年も何年もダラダラダラダラと、去年800億円、ことし800億円、来年も800億円・・・
年金という金のなる木が枯れるまで、骨の髄までしゃぶり尽くすんだろ。
民営化とは名ばかりで、金の流れ道が少し変わっただけ。政府とズブズブやんけ。

974 :デフォルトの名無しさん:2009/04/14(火) 16:47:53
大規模が処理量の大規模ならCなんだろうけど
機能数の大規模や開発者数の大規模の場合に
Cを選ぶとプロジェクトが遅延しまくるんじゃまいか

975 :デフォルトの名無しさん:2009/04/14(火) 16:48:33
大規模で膨大なトランザクション抱えている所はどこも I/O がネックになってるから
C と Java 程度の速度差なんてたいした話ではないな。インフラならともかく、金融系の
膨大かつ毎年改訂の入るような業務ロジックを C で組むなんてアホも良いとこ。
大体、速度を求めるなら普通は開発リスクのないハードの増強に投資する。

976 :デフォルトの名無しさん:2009/04/14(火) 17:11:54
トランザクション量で金融は大規模ではない
ネット証券大手でもTwitterやブログとは何桁も少ない
もちろん信頼性の要求も桁が違うがそもそも金融程度の
トランザクション量ならCを選ぶ必要はない
例外は証券取引所くらいか

977 :デフォルトの名無しさん:2009/04/14(火) 17:32:36
トランザクションと HTTP リクエストの区別の付いていない方が居られるようだが…

978 :デフォルトの名無しさん:2009/04/14(火) 17:43:59
976は当然トランザクションのことを書いている
それが分からないのは視野が狭いのではないか

979 :デフォルトの名無しさん:2009/04/14(火) 17:47:43
元の話(>>971)ではトランザクションの話なんてしてないし
実際Cで書く意味があるかどうかはトランザクションより
HTTPリクエストの量だろうがな

980 :デフォルトの名無しさん:2009/04/14(火) 17:56:46
おまいら C に幻想持ちすぎ。

981 :デフォルトの名無しさん:2009/04/14(火) 18:16:08
それLinusに言ってみたら?

982 :デフォルトの名無しさん:2009/04/14(火) 18:28:05
COBOL化まっしぐら

983 :デフォルトの名無しさん:2009/04/14(火) 18:32:26
WEBアプリ以外はアプリに非ず、って風潮?

984 :デフォルトの名無しさん:2009/04/14(火) 18:41:27
どこが?

985 :デフォルトの名無しさん:2009/04/14(火) 18:53:49
>>979
元の話(>>971)ではトランザクションの話もHTTPの話もしてないし。
ただ「大規模なシステム」としか書いてない。
何の前提も無いときはHTTPの話がデフォルトというわけなのか。

986 :デフォルトの名無しさん:2009/04/14(火) 18:58:08
>>976
DB/ホストへのアクセス量が全然違う。ブログと同じ程度のシステムしか組んだ事ないのかよ。

987 :デフォルトの名無しさん:2009/04/14(火) 19:12:45
C言語と相性の悪い言語って基本的には無いと思う。
処理性能とフットプリントの小ささに信頼のある言語は他に見あたらない。
処理性能だけならいくつかのベンチマークではGNU CよりJavaのが速いから、
これはもう言語というよりコンパイラ屋をどれだけ囲ってるかの差だな。

988 :デフォルトの名無しさん:2009/04/14(火) 19:31:31
Javaのメモリ周りの最適化はやりつくした感じ(スタック割り当てとか)だけど、
Cのほうは、JITの導入が始まってきた(LLVMとか)ところだからなあ。

989 :デフォルトの名無しさん:2009/04/14(火) 19:43:36
>>985
>>979>>977を見て書いたからHTTPが出てる
トランザクションは>>974-975の流れだな


990 :デフォルトの名無しさん:2009/04/14(火) 19:50:33
>>986
君は金融しか経験がないようだな
いくらハイエンドのサーバでもOracle(RACも含む)なんかで集中型の
DBMSで運用できているという事実が金融はトランザクション量が
たいしたことないという事実を語っている
大規模ってのは君が考えてるより二桁三桁多いトランザクションをさばいてるよ

991 :デフォルトの名無しさん:2009/04/14(火) 20:00:52
>>990
いや、単におまいがオープン系の世界しか知らんだけだと思う。

992 :デフォルトの名無しさん:2009/04/14(火) 20:07:01
>>991
大手ネット証券やってますが何か?

993 :デフォルトの名無しさん:2009/04/14(火) 20:08:39
ちょw
基幹系が Oracle で運用できてるってどこのサラ金の事だよw

994 :デフォルトの名無しさん:2009/04/14(火) 20:22:59
バックはメインフレームだけどフロントのDBMSはOracleよ
ネット専業に限らず証券はだいたいそんなもん

995 :デフォルトの名無しさん:2009/04/14(火) 20:29:58
>>992
でかいところだと赤と緑の某都銀にもっと巨大な某生保、損保最大手、某FRB生命なんかで
やってましたが何か (何をかまでは特定されるので言わない)。先日民営化されたバケモノは
何とか足抜けられたが。
というか、どう見てもトランザクション≒HTTPアクセスという認識で語ってるようにしか
見えないわけだが… 今時のブログは PHP を TP モニターで監視でもしてんの?

996 :デフォルトの名無しさん:2009/04/14(火) 20:36:17
やっぱり金融バカかw

997 :デフォルトの名無しさん:2009/04/14(火) 20:42:38
おまえ、やっぱりフロント側の、しかも Web 周りしか開発したことのないだろ。
トランザクションの話でブログ引き合いに出してるような時点で知れてんだよ。

998 :デフォルトの名無しさん:2009/04/14(火) 20:45:51
2

999 :デフォルトの名無しさん:2009/04/14(火) 20:46:47
証券バックもやったし銀行も少しだけやったよ
つか、後ろの方がトランザクション量的にはずっと少ないじゃん
バッチやディレイドオンラインのデータ量は多いけど効率いいから負荷少ないよね
保険はやったことないからどんな感じか興味あるけど次スレに持ち越して欲しくはないw

1000 :デフォルトの名無しさん:2009/04/14(火) 20:47:27
1000ならJava7年内リリース

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

220 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)