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

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

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

1 :デフォルトの名無しさん:2010/06/11(金) 23:14:18
■■前スレッド■■
【Java SE 7】 次世代Javaの動向 8 【dolphin】
http://pc12.2ch.net/test/read.cgi/tech/1239710345/

■■過去スレッド■■
【Java SE 7】 次世代Javaの動向 7 【dolphin】
http://pc12.2ch.net/test/read.cgi/tech/1220531647/
[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/

2 :デフォルトの名無しさん:2010/06/11(金) 23:15:18
■■■関連スレ
★★Java質問・相談スレッド139★★
http://pc12.2ch.net/test/read.cgi/tech/1274617383/
【JMF】Java Media APIs【JOGL】
http://pc12.2ch.net/test/read.cgi/tech/1201346803/
【徹底討論】Java3Dの可能性について考える
http://pc11.2ch.net/test/read.cgi/tech/1033703640/
Eclipse統合M29【Java/C++/Ruby/Python/Perl】
http://pc12.2ch.net/test/read.cgi/tech/1265820185/
NetBeans Part6
http://pc12.2ch.net/test/read.cgi/tech/1273665879/
【Java】Wicket【HTML】
http://pc11.2ch.net/test/read.cgi/tech/1132407308/
Java低速GUI Swing 9
http://pc12.2ch.net/test/read.cgi/tech/1261232019/
Java系スクリプト言語Groovy
http://pc12.2ch.net/test/read.cgi/tech/1080052050/

3 :デフォルトの名無しさん:2010/06/13(日) 19:50:43
jdk7 build97
http://download.java.net/jdk7/binaries/
http://download.java.net/jdk7/changes/jdk7-b97.html

OpenTypeサポートきた?

4 :デフォルトの名無しさん:2010/06/13(日) 23:35:15
ラムダの書式ダサすぎ
C#のを素直にぱくってくればいいのに

5 :デフォルトの名無しさん:2010/06/14(月) 00:43:46
C#乙

6 :デフォルトの名無しさん:2010/06/14(月) 21:00:47
まあ #()(1).() が美しいとは言えんし

7 :デフォルトの名無しさん:2010/06/14(月) 21:43:45
>>4
C#のはどうやるんですか?

8 :デフォルトの名無しさん:2010/06/14(月) 21:48:27
(()=>1)()
#()(1).()
どっちも文字数変わらないから
あんまり違いはないんじゃない?

9 :デフォルトの名無しさん:2010/06/14(月) 22:39:34
そういうのは書式というか記法というけど。
美しいかどうかならrubyのあれが一番かな。クロージャの{=>}もruby記法の影響を受けてたわけだし。

10 :デフォルトの名無しさん:2010/06/14(月) 22:52:20
>>8
型推論による型省略や var があるとだいぶ変わってくる

11 :デフォルトの名無しさん:2010/06/15(火) 16:07:45
Haskellのやつがいい

12 :デフォルトの名無しさん:2010/06/15(火) 21:18:49
出る出る詐欺

13 :デフォルトの名無しさん:2010/06/15(火) 21:35:46
ところでオープン・ソラリスはどーするんだろう。
pc(x86)ではグーグルオーエスなんかよりも期待してたのに。

14 :デフォルトの名無しさん:2010/06/16(水) 00:21:25
Oracleに買われてからjava.sun.comが使いにくい orz


15 :デフォルトの名無しさん:2010/06/16(水) 20:06:17
final 変数しかキャプチャできない匿名クラスの制限を緩めるだけじゃだめなのかな > lambda


16 :デフォルトの名無しさん:2010/06/17(木) 23:40:43
短く簡潔に書けることが重要って誰かが言ってた。
えーとこれか
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?Closure

17 :デフォルトの名無しさん:2010/06/19(土) 11:33:11
今更既存のAPIと互換性のない形で導入されたって現実的には全く使えないよね。
メソッド一つだけのインターフェイスを実装する匿名クラスを生成する
シンタックスシュガーとして実装するくらいしかないんじゃないの。
汚いけどそれ以外の選択肢はないと思う。

18 :デフォルトの名無しさん:2010/06/19(土) 11:40:31
マイクロソフトがあるからJavaなんかどうでもいい

19 :デフォルトの名無しさん:2010/06/19(土) 12:59:25
>>17
実際にシンタックスシュガーとして実装されてるよ
クロージャに限らずJavaの言語仕様に追加された機能はほとんどがそう

20 :デフォルトの名無しさん:2010/06/19(土) 15:15:53
今回の例のラムダの提案はそうじゃないよ
完全にC#のデリゲートと同じような仕組みを新たに導入するというもの

21 :デフォルトの名無しさん:2010/06/19(土) 15:29:10
デリゲート(メソッドポインタ)とラムダは別物じゃね?

22 :デフォルトの名無しさん:2010/06/19(土) 15:39:39
lambda_trans.pdfにはメソッドハンドルで実装すると書いてある
作成時に環境オブジェクトを渡したりしてるから完全にデリゲート

23 :デフォルトの名無しさん:2010/06/19(土) 16:19:29
デリゲートってJavaHouseで高木浩光先生が批判してた奴だよね。
ttp://java-house.jp/ml/archive/j-h-b/019802.html
そんな物どうして今更入れなきゃならないの?



さて、C#のプログラミングに戻るかwwww

24 :デフォルトの名無しさん:2010/06/19(土) 16:28:15
>>22
そういうもんじゃないだろ。
実装がどうなっているかは関係ない。


25 :デフォルトの名無しさん:2010/06/19(土) 16:51:45
JSR292は主にJVM動的型言語用の機能でProject Lambdaのために導入されたわけじゃないと思うが。

26 :デフォルトの名無しさん:2010/06/19(土) 18:18:18
実際にはヘッダのバージョン書き換えただけでJVMに何ら新機能は追加されてない
なんてことしても「クラスファイルの互換性がない」という文句はほとんど聞こえてこないん
だから実は大した問題じゃないんだろ。

27 :デフォルトの名無しさん:2010/06/19(土) 18:53:43
>>24
このコード、例のpdfのラムダの実装コードにそっくりw

28 :デフォルトの名無しさん:2010/06/19(土) 19:07:28
>>24ってそもそもラムダ全否定だよね
むしろシグネチャだけしか考えない分、デリゲートよりも型付けが弱い

29 :デフォルトの名無しさん:2010/06/19(土) 20:00:48
12年も前の腐りきった戯言のリンクなんか張るな

30 :デフォルトの名無しさん:2010/06/19(土) 20:08:24
オブジェクト指向とは何かというとき、それは即class指向だ、と考えさせようとするのは禿げ先生の洗脳だよ

31 :デフォルトの名無しさん:2010/06/19(土) 20:10:30
クラス指向ってなんだ?
C (非C++) のモジュール化みたいにしかクラスを使わない設計?

32 :デフォルトの名無しさん:2010/06/19(土) 20:20:34
いやいや、C++やJavaなど始めにクラスありきなオブジェクト指向のことだろ

33 :デフォルトの名無しさん:2010/06/19(土) 20:33:44
ところでWindows 7 (64bits)でSUN JAVAは動くんですか?
Windows 7でもappletやawtは動くんですか?

34 :デフォルトの名無しさん:2010/06/19(土) 21:10:28
英語wikiて最近デザイン変えたでしょ?
このまえ英語wikiのページにjava appletの動画プレーヤー(普通はflashだけど)が埋めこんであったんだよね。
osが古くてflash10はもうインストできないから、javafxで作ってもあってもいいけどlinuxにはうれしい。
javaプログラマーは口ではいくらでも大きなことを言うけど結局は今まで動画プレーヤーを作れるスキルもなかったのかと思った。
いくらjavaを勉強しても、Webサーバーの設定・設置に強くはなるかもしれないけど、自分でアプリを作れるスキルは身につかないで終わるだろうね。

35 :デフォルトの名無しさん:2010/06/19(土) 22:49:22
>>33
何で動かないと思うの?

36 :デフォルトの名無しさん:2010/06/20(日) 13:08:41
>>23
デリゲートっていう概念が何のことなのかも理解できなくてモゴモゴ言ってるだけだろ
もっとも自分のところのdelegateが本質的にどういうものかも理解してないじゃないの?

37 :デフォルトの名無しさん:2010/06/20(日) 13:31:32
>>23
たしかその高木なんとかって、winny用の不正アクセスのソフト作った人でしょ?
法学の専門家でもないのに独特な法律解釈をするし自分の主義思想と現実(罪刑法定主義)がごっちゃになってるんだろうね。

こういう人はこの業界によくいるでしょ。
官庁つながりがたまたまあったかもしれないけど、ストールマンと同じでなんかの秘密結社の教祖にでもなろうとしてるんじゃないの?

38 :デフォルトの名無しさん:2010/06/20(日) 13:50:28
秘密結社って、誰かと思ったらopenbsdのあの人のことだw
いるんだよね・・・自分が神にでもなったと錯覚しちゃう人ってさ
チームプレイにまったく向いてなくて、理想だけが先走っちゃっていつのまにか周りには誰もいなくなってるのにそれでも突っ走って犯罪まで一歩手前の人っていうか

39 :デフォルトの名無しさん:2010/06/20(日) 14:01:57
媚びるのがいけないというならJavaだってレガシーC脳な人に比較的媚びた設計だよね
C#はRADに媚びてるけどそっちはわりと切り捨ててるよね

40 :デフォルトの名無しさん:2010/06/20(日) 16:30:42
>>37
知らない人を妄想で批判するなよ……

41 :デフォルトの名無しさん:2010/06/21(月) 05:26:32
セキュリティといえば、ソ連スパイのゾルゲ事件(死刑)を思い出すね。
研究員として碓ぐらい部屋でシコシコ開発してるなら、高々原子力技術の流出や造船設計書の産業スパイ程度であまり被害はないんだけど。
しかしゾルゲ事件は政治家でもないのに自分の理想実現のための政治主張をしまくり、それに翻弄された挙げ句日本のここ100年の国益を損ねたね。

42 :デフォルトの名無しさん:2010/06/29(火) 14:11:40
>>40
本人乙

43 :デフォルトの名無しさん:2010/06/30(水) 22:11:08
さすがにもう高木先生は枯れたJavaから手を引いてるでしょ

44 :デフォルトの名無しさん:2010/07/02(金) 23:17:41
高木先生開発アプリのうち最新のNyzillaもJavaで開発されてるじゃん。

45 :デフォルトの名無しさん:2010/07/02(金) 23:20:30
その何とかって先生は、どこかの大学で教えてる何の学科の先生なの?

46 :デフォルトの名無しさん:2010/07/02(金) 23:36:04
ひろみちゅって今も産総研だっけ?

47 :デフォルトの名無しさん:2010/07/02(金) 23:55:35
>>45
おまえ…
ちゃんとトップを走る連中を追えよな…

48 :デフォルトの名無しさん:2010/07/03(土) 00:06:27
産総研発祥でこれは外せないアプリ、有用なアプリってなんかあったの?
内輪だけで盛り上がってたけどクノッピーとかそうだっけ?

49 :デフォルトの名無しさん:2010/07/03(土) 00:17:19
予算は多くつけてもらっているが、結局はポスドクと天下りだけしかいない独立行政法人
税金でやってるわりには国益にもならないし日本のベンチャー産業に有用なわけでもないしそのうち仕分け対象になるんじゃないのか

50 :デフォルトの名無しさん:2010/07/03(土) 09:41:54
産業技術総合研究所
http://ja.wikipedia.org/wiki/%E7%94%A3%E6%A5%AD%E6%8A%80%E8%A1%93%E7%B7%8F%E5%90%88%E7%A0%94%E7%A9%B6%E6%89%80
>陣容は、研究職を中心とする常勤職員約2500名、事務系職員約700名に加え、
>企業・大学・外部研究機関等から約5200人(平成17年度受入延べ数)の
>外来研究者を受け入れている。
>規模が匹敵する理化学研究所(略称は理研。文部科学省所管)とよく比較されるが、
>理研は基礎研究指向でライフサイエンス分野が強く、
>産総研は産業技術開発・工業化研究指向で材料開発研究分野が強い特徴を持つ。

ソフトウェア業界視点だけで産総研は不要と断ずるのはあまりにも近視眼だと思います。

51 :デフォルトの名無しさん:2010/07/03(土) 13:28:44
管轄が同じだから、そこの祖父と事業部はIPAと合併してお役所事務仕事に徹する方向で事業縮小判定になるよ。

52 :デフォルトの名無しさん:2010/07/03(土) 22:33:49
Nyzillaは完全に個人開発だから産総研関係ない

53 :デフォルトの名無しさん:2010/07/05(月) 18:39:10
>>52
本人乙

54 :デフォルトの名無しさん:2010/07/09(金) 12:55:54
産総研、理研、NICT、IPAあたりの主たる役割は、作りすぎたポスドクの雇用維持。


55 :デフォルトの名無しさん:2010/07/09(金) 23:56:31
文部省が博士増産計画(数倍?)主導したのだから、
国内企業にポストが無い状況で、国で出口政策主導するのはしょうがない。

56 :デフォルトの名無しさん:2010/07/10(土) 01:06:57
研究費使って身内同士でciteしまくるようなクソ論文量産するぐらいなら、
時給1000円ぐらいで写経でもしててくれんもんかなと思う。
まー、その研究費に測定機やらのメーカーが群がって、公共投資になるわけだから、
しゃあないといえばしゃあないか。

57 :名無しさん@そうだ選挙に行こう:2010/07/10(土) 12:02:24
> 身内同士でciteしまくる
Webページだったらリンクspam認定だな

58 :名無しさん@そうだ選挙に行こう:2010/07/10(土) 14:46:27
身内なら当然rel="nofollow"つけてるだろ

59 :名無しさん@そうだ選挙に行こう:2010/07/10(土) 22:31:16
rel="nofollow"な論文引用ってどんなんだ

60 :デフォルトの名無しさん:2010/07/12(月) 10:40:26
Javaにおけるラムダ:詳細な分析
http://www.infoq.com/jp/articles/lambdas-java-analysis

61 :デフォルトの名無しさん:2010/07/12(月) 11:37:29
先週lambda-devでいくつか投稿があってさっそく紛糾してる。

State of the Lambda 構文候補が #int(int) から {int->int} に?
http://mail.openjdk.java.net/pipermail/lambda-dev/2010-July/001775.html

Removal of function types
http://mail.openjdk.java.net/pipermail/lambda-dev/2010-July/001777.html

Type inference of parameters
http://mail.openjdk.java.net/pipermail/lambda-dev/2010-July/001778.html

Transparency returnやめてyieldにしようぜ
http://mail.openjdk.java.net/pipermail/lambda-dev/2010-July/001780.html

Primitives in Generics 関数型の代替品として。List<int>はList<Integer>の構文糖、という案。
http://mail.openjdk.java.net/pipermail/lambda-dev/2010-July/001817.html

62 :デフォルトの名無しさん:2010/07/12(月) 12:12:29
どうせMS社員かC#工作員の嫌がらせだろう
サンはMSやC++0xと違って言語仕様は明確な目的を持って決めるからそういう戯言はまったく影響ない
genericsの時と同じでそのような戯言がサンの中の人に届くこともない

63 :デフォルトの名無しさん:2010/07/13(火) 12:59:52
いやいや、もう太陽は沈んじゃったし

64 :デフォルトの名無しさん:2010/07/13(火) 13:10:06
>>62
それ良いことなの?w
確かにJava5なんかユーザーの反発を無視した強引な拡張だけど

65 :デフォルトの名無しさん:2010/07/13(火) 13:37:52
最近のゴスリンはオラクルは人的リソースを蔑ろにしてるとかいう嫌味ばっかりでしょ。
といってもサンは当のゴスリンにすら見捨てられたから、最近はjdkに見切りを付けてmonoで遊んでる。
こういうことがあるからjdkはopenjdkにしといて本当に良かったと思うよ。
旧サンの社員(ゴスリンの部下達)もオープンソースにしてあるからこそ転職しても今までの仕事が続けられるんだし。

66 :デフォルトの名無しさん:2010/07/15(木) 16:39:13
関数の複数の戻り値は追加される?


67 :デフォルトの名無しさん:2010/07/16(金) 09:18:26
タプルか
(int x, int y) = getPoint();
のように戻り値で使うだけならいいけど変数にタプルオブジェクトそのものを代入しようと思うと
$(int, int) point = (x, y);
みたいにまた変な新しい型が必要になるぞ

68 :デフォルトの名無しさん:2010/07/16(金) 10:05:21
タプルに変数への参照渡せたら
int x, y; (x, y) = getPoint();
みたいにできるんだけどな。

69 :デフォルトの名無しさん:2010/07/16(金) 23:49:26
タプルが糞なのは、いったん(>>67に倣って)$(int, int)型に入れてしまうと
変数名(x, y)が失われてしまって可読性が失われること。
だからって$(int x, int y)みたいな長い型名を持ちまわるのはかえって面倒だし、
だからといってそのためにtypedef的なものを導入すると、最初から普通にクラスを作るのと変わらない。
例えばpythonではオブジェクトはメンバ名とそれに対応する値の集合だからタプルがうまく機能する。

70 :69:2010/07/16(金) 23:55:01
すまん最後の行は勘違いだから無視して

71 :デフォルトの名無しさん:2010/07/17(土) 01:46:20
型推論とジェネリック型があればいい感じにタプルが使える

72 :デフォルトの名無しさん:2010/07/17(土) 02:43:35
戻り値用の単純なのだけでいいな
複雑な構文入れるならScalaの土俵でしょ

73 :デフォルトの名無しさん:2010/07/17(土) 06:56:10
あれこれ欲しいならC#で十分

74 :デフォルトの名無しさん:2010/07/17(土) 14:45:03
情報が少なくて可読性が損なわれるのってラムダもそうなんだよな
#int(int)だけ見ても全く意味が分からない
だからC#やDelphiなどでは関数を格納する型を明示的に宣言しないといけないし
CやC++の関数ポインタもtypedefして使うことが多いわけだけど
Javaの中の人に言わせればダサイらしい

75 :デフォルトの名無しさん:2010/07/17(土) 15:16:03
日本語でおか

76 :デフォルトの名無しさん:2010/07/17(土) 15:40:14
弱いtypedefされっと型変換すらなしに勝手に他の型に成り下がるからなぁ……
暗黙の型変換もあってもいいけどデフォルトではキャストか変換用メソッド強要のがいいな。

77 :デフォルトの名無しさん:2010/07/17(土) 15:49:21
>>74
C#はFunc<int int>になったんじゃなかったか?

78 :デフォルトの名無しさん:2010/07/17(土) 16:10:25
それはLINQだけ
純粋に高階関数のアルゴリズム集だからそれに渡す関数にはもともと特に具体的な意味はない

79 :デフォルトの名無しさん:2010/07/17(土) 17:14:52
結局#int(int)みたいな関数型って導入されることになったの?

80 :デフォルトの名無しさん:2010/07/17(土) 18:15:30
gdgdすぎてどっちに転ぶかわからん。

81 :デフォルトの名無しさん:2010/07/18(日) 17:41:29
>>79
syntaxのみ未定。
semanticsもやや改変あるかも。

82 :デフォルトの名無しさん:2010/07/18(日) 17:50:47
>>61にもあるけど関数型なんてやめてSAMクラス(として見做せるクラス)に対するシンタックスシュガーでいいと思う
そんなにラムダを型付けするのが嫌か

83 :デフォルトの名無しさん:2010/07/18(日) 17:59:59
いきなりgenericsのprimitive型対応に飛びつくようなの見せられると
好き嫌い以前のレベルで心配になる。

しかもgenericsのprimitive型対応ってのもかなりやっつけ仕事だしなぁ。
やるんなら互換性削ってもいいからVMレベルで対応して欲しいんだが。

84 :デフォルトの名無しさん:2010/07/18(日) 18:07:20
VMレベルで対応するとなると評判の悪いオートボクシングをVMレベルに持ち込むことになるんだぞ
それに既存のジェネリクス使ったクラスでは値型が入ることが全く想定されてないから
正しく動作しない可能性が高い

85 :デフォルトの名無しさん:2010/07/18(日) 18:12:22
> VMレベルで対応するとなると評判の悪いオートボクシングをVMレベルに持ち込むことになるんだぞ
意味わからん

二行目以降は、既存のジェネリクス使ったクラスはそのままで
プリミティブ対応の場合は新しいキーワードかアノテーションでやればいいだけ。
reified genericsのときもそーゆー話は出てたし。

86 :84:2010/07/18(日) 18:21:40
ああ、プリミティブ対応したい場合は特別に指定するってことね
それなら問題ないけど制限が厳しくて使いづらいものになると思うよ
Objectクラスのメンバを呼ぼうとする場合に問題ということ
hashCodeを取得するための別のクラスとか必要になる

87 :デフォルトの名無しさん:2010/07/18(日) 18:25:52
new Boxing<int>()とか出来るようになったところで何がうれしいのかさっぱりわからん。

88 :デフォルトの名無しさん:2010/07/18(日) 18:30:43
VMレベルでボクシングが不要になればコレクションのパフォーマンスが桁違いに上がる

89 :デフォルトの名無しさん:2010/07/18(日) 18:40:23
そうか?
プリミティブを格納するコレクションなんてそもそもArrayListくらいしか必要なくね?
MapやSetで使ったりしないだろ?
だったらそこら中で実装されてるIntArrayListをjava.utilに入れるだけでええやん

90 :デフォルトの名無しさん:2010/07/18(日) 18:56:18
ArrayListでプリミティブを格納できるのか?

91 :デフォルトの名無しさん:2010/07/18(日) 19:06:24
ジェネリクスでプリミティブ型をサポートするなら最低限Object型であることの保証もなくなるわけだから
ArrayListならCollection<E>すらも実装できないことになるな
既存のコードとの互換性ゼロだね

92 :デフォルトの名無しさん:2010/07/18(日) 19:14:17
>>73

93 :デフォルトの名無しさん:2010/07/18(日) 19:23:02
primitives in genericsするぐらいならfunction typeでいいような気もするが。

どっちもないと
http://gee.cs.oswego.edu/dl/jsr166/dist/extra166ydocs/extra166y/Ops.html
みたいに悲惨な事になる。

94 :デフォルトの名無しさん:2010/07/18(日) 19:32:16
>>86
それだけなら
int toHashCode(int) String toString(int)
みたいなメソッドをどっかに持たすとか
設定できるようにしときゃいいだけなんでは?

95 :デフォルトの名無しさん:2010/07/18(日) 19:38:59
>>87

96 :デフォルトの名無しさん:2010/07/18(日) 19:48:34
>>94
Objectじゃなくなることがどれだけの影響をもたらすか想像できる?
コレクション系のインターフェイスはほぼ全て非互換になるんだぞ
for (Object item : iterable)みたいなこともアウト
これをオートボクシングで回避しようと思ったらやっぱりVMに組み込む必要がある

97 :デフォルトの名無しさん:2010/07/18(日) 19:52:51
つかプリミティブのコレクションなんか誰が何に使うんだっつー話だよ
VMいじってまでの必要性あんのかよ

98 :デフォルトの名無しさん:2010/07/18(日) 19:55:45
まあ.NETのジェネリクスで値型サポートが重視されたのはユーザが定義できるからだもんな
プリミティブ型だけなら我慢しろ

99 :デフォルトの名無しさん:2010/07/18(日) 20:05:45
そこまでjvmにこだわるなら普通はinvokedynamicの方を勉強する

100 :デフォルトの名無しさん:2010/07/18(日) 20:11:10
ジェネリクスの辻褄合わせのために遅延バインディングしてたら本末転倒だろうが

101 :デフォルトの名無しさん:2010/07/18(日) 20:21:39
もうGenericsやめてTemplateにしちゃいなYO

102 :デフォルトの名無しさん:2010/07/18(日) 20:23:59
もしかしてC++みたいな高速とか効率とかいう戯言こそが最上の価値であるって前提で考えてないか?

103 :デフォルトの名無しさん:2010/07/18(日) 20:28:03
でも実際コレクションのボクシングがボトルネックになる場合はあるからな

104 :デフォルトの名無しさん:2010/07/18(日) 20:30:38
>>96
だから非互換でいいって言ってるじゃん。
既存のコレクション変えろとも言ってないし、autoboxingしろとも言ってない。

105 :デフォルトの名無しさん:2010/07/18(日) 20:34:02
それはjava langの仕様の問題じゃなくてプログラミング・テクでしかない。langやjvmなどまったく関係なく、せいぜいUtils.metho(int)あたりのライブラリ・サポートになる。
c/c++のメモリモデルやアルゴからちゃんとプログラミングを勉強してるならfor loopsのそのようなパターンは個数が有限か不定個数なのかでコードが違うけどいつもの典型的なあのパターンを使えば十分。

106 :デフォルトの名無しさん:2010/07/18(日) 20:40:51
>>98
個人的には我慢しろで通すのもアリだとは思うが、
Doug Lea御大が>>93みたいに型一杯書かされるのは嫌だと仰ってな。

107 :デフォルトの名無しさん:2010/07/18(日) 20:43:17
コンパイラレベルでサポートできなくはないけどそれ完全にテンプレートだよ
.NETのように実行時に展開する方式をとるならVMレベルでボクシングをサポートしないとどうやっても無理

108 :デフォルトの名無しさん:2010/07/18(日) 20:49:17
>>78
そもそもlambdaのfunction typeも
http://gee.cs.oswego.edu/dl/jsr166/dist/extra166ydocs/extra166y/Ops.html
みたいな特に意味のない関数型を定義すんのが面倒だから復活したはずだが。

109 :デフォルトの名無しさん:2010/07/18(日) 20:54:24
>>107
http://mail.openjdk.java.net/pipermail/lambda-dev/2010-July/001817.html
読むと、言語レベルでどうにかすると仰ってますが。

どっかに穴がありそうな気がしなくもない

110 :デフォルトの名無しさん:2010/07/18(日) 21:00:22
>>106

>>87

111 :デフォルトの名無しさん:2010/07/18(日) 21:13:23
>>109
それList<int>をList<Integer>として実装するだけらしい
コンパイラが自動的にボクシングを追加しまくる

112 :デフォルトの名無しさん:2010/07/18(日) 21:17:07
List<int>#toArray() とか大変そうだな……
他の言語からはどう見えるんだろ?

113 :デフォルトの名無しさん:2010/07/18(日) 21:24:20
タプルは欲しいとは思うけどこれは構造体とかの議論だから今回のラムダ実装プロジェクトじゃタプルサポートなんて到底間に合わないだろ。
クロージャやるときにタプルや定数について議論を深めてほしいとは思う。
ラムダMLや<int>でうだうだいってるようじゃ、タプルとか定数とかの近代的な言語概念についてついてこれる人はあまりいないだろうけど。

114 :デフォルトの名無しさん:2010/07/18(日) 21:50:42
java 7 でモジュールをサポートするって話だったけどやっぱり止めたの?

115 :デフォルトの名無しさん:2010/07/18(日) 23:04:25
モジュールってパッケージと何が違うの?

116 :デフォルトの名無しさん:2010/07/18(日) 23:09:07
やっぱりOSGiでやるとかやらないとか。

117 :デフォルトの名無しさん:2010/07/18(日) 23:40:22
>>114
JSR294とかJSR277なら見事に轟沈したんじゃなかったか?

118 :デフォルトの名無しさん:2010/07/18(日) 23:46:24
>>111
List<int>のインスタンスをリフレクション経由で操作、
とか考えたらそれだけで済むわけないと思うんだが。
特に配列扱う部分は鬼門。

119 :デフォルトの名無しさん:2010/07/19(月) 13:01:57
>>118
そんなこと<Integer>でも元々できないでしょ
>>109にはイレイジャとして実装するのは変わらないと明記されてる
今更だけどジェネリクス最大の欠陥だ

120 :デフォルトの名無しさん:2010/07/19(月) 13:25:13
>>119
List<Integer> は List<int> じゃないんだから int[] toArray(int[]) できないのは当然だが。
それに erasure 使うにしても、フィールド引数戻り値で使われれば
型情報として List<int> みたいなのは残るからな。

今になって思えば、総称型が失敗だったというより
そもそもプリミティブ型入れちゃったのが欠陥のような気もする。

121 :デフォルトの名無しさん:2010/07/19(月) 13:38:27
呼び出し側で配列もボクシング/アンボクシングしちゃえばいいんだよ
>>109にもそう書いてある
ただし、とっても高コストな処理になるはずだから大問題ね、だそうだ

122 :デフォルトの名無しさん:2010/07/19(月) 14:16:55
>>121
呼び出し側と呼び出されるメソッドだけならそれで解決できるかもしれんが、
メソッド内でT[]を引数か戻り値に使う別のメソッド呼ばれるときはどうやって解決するんだ?

<T> T[] join(T[][] arrays, Class<T> clazz) {
 int size = 0; for (T[] array : arrays) size += array.length;
 T[] retArray = (T[])Array.newInstance(clazz, size);
 size = 0; for (T[] array : arrays) { System.arraycopy(array, 0, retArray, size, array.length); size + = array.length; }
 return retArray;
}

T[] toFlatArray(List<List<T>> l, Class<T> clazz) {
 T[][] arrays = (T[][])Array.newInstance(Array.newInstance(clazz, 0).getClass(), l.size());
 for (int i = 0; i < l.size(); i++) arrays[i] = l.get(i).toArray(Array.newInstance(clazz, l.get(i).size()))
 return join(arrays);
}

123 :デフォルトの名無しさん:2010/07/19(月) 14:26:17
>>122
YAGNI

124 :デフォルトの名無しさん:2010/07/19(月) 14:27:31
>>87

125 :デフォルトの名無しさん:2010/07/19(月) 14:30:02
>>122
> T[] toFlatArray(List<List<T>> l, Class<T> clazz) {
<T> T[] toFlatArray(List<List<T>> l, Class<T> clazz) {

>  return join(arrays);
 return join(arrays, clazz);

だな。というか、多重にメソッド呼び出しせずとも
<T> T[] toArray(List<T> l, Class<T> clazz) {
 T[] array = (T[])Array.newInstance(clazz, l.size());
 for (int i = 0; i < l.size(); i++) array[i] = l.get(i);
 return array;
}
みたいにクラス内で T[] 生成されてもアウトのような。

126 :デフォルトの名無しさん:2010/07/19(月) 14:37:39
T[]に変換しようとした時点でコンパイラが
CompilerUtil.boxIfNecessary(Array.newInstance(clazz, size));
みたいなコードを生成するくらいしかないかな

127 :デフォルトの名無しさん:2010/07/19(月) 16:52:21
既にコンパイルされている既存のライブラリが使い物にならなくなる。

128 :デフォルトの名無しさん:2010/07/19(月) 17:03:04
頭痛が痛い

129 :デフォルトの名無しさん:2010/07/19(月) 17:16:57
C++みたくアルゴリズムが豊富に揃ってるわけでもないのに
既存ライブラリでプリミティブを扱えて得するやつなんて超少数派だろ

130 :デフォルトの名無しさん:2010/07/19(月) 17:26:15
互換性保つために実行時効率犠牲にして boxing/unboxing 使うアプローチにしたのに
互換性破壊されんのはダメダメのような

131 :デフォルトの名無しさん:2010/07/19(月) 18:02:02
>>114

132 :デフォルトの名無しさん:2010/07/19(月) 22:05:56
思い切って現行ジェネリクスを非推奨にして、
追加機能を考慮した新しい何かを導入するというのもある。

133 :デフォルトの名無しさん:2010/07/19(月) 22:43:57
現行の generics を置き換えるようなものとなると一朝一夕にはいかんし
結局 function type のが現実的だと思うけどな。

134 :デフォルトの名無しさん:2010/07/19(月) 22:53:53
より現実的なのはParallelArrayごとラムダを削除する事だな

135 :デフォルトの名無しさん:2010/07/20(火) 10:45:19
>>109
可変長引数の扱いとかも結構酷い事になりそうな予感。

List<int>list = Arrays.asList(new int[0]); //List<int> ができるなら、これが期待される
List<int[]> list = Arrays.asList(new int[0]); //互換性を考えると、こうせざるを得ない。

136 :デフォルトの名無しさん:2010/07/20(火) 11:04:48
もっと早い段階からオートボクシングはVMに組み込んどくべきだった
すべてが手遅れ

137 :デフォルトの名無しさん:2010/07/20(火) 13:48:51
simonpjがboxing/unboxingの最適化の論文書いたのが90年代前半なので…
type erasureを使った言語/ライブラリ設計としてはよく出来ているし。

138 :デフォルトの名無しさん:2010/07/20(火) 18:29:38
ユーザーに実装を意識させる時点でおかしい
テンプレートとして実装する方が将来的な実装の幅が広がってまだマシだった

139 :デフォルトの名無しさん:2010/07/21(水) 20:00:07
>>135
iterableをObjectが実装してくれるだけで使いやすくなるのかなぁ、と
思うんだけど

140 :デフォルトの名無しさん:2010/07/22(木) 09:25:20
どのみちiterableでプリミティブ型は列挙できないじゃん
やっぱりVMレベルでのオートボクシングが必要

141 :デフォルトの名無しさん:2010/07/22(木) 10:20:54
iterableってどっからでてきたんだ?

142 :デフォルトの名無しさん:2010/07/22(木) 10:36:48
>>139
なんでもかんでも Object に突っ込んだら駄目だろ

143 :デフォルトの名無しさん:2010/07/26(月) 13:14:23
Objectってのは、基底クラスで実装してくれたらなってだけで・・・
Listでも配列でも単値でも、どれでもイテレーション出来たら便利って話だけで。。

144 :デフォルトの名無しさん:2010/07/26(月) 16:14:48
opensolarisは開発中止になって解散するそうだね。

Neale Ferguson による動議: OGB は OpenSolaris への理解とオープンな開発
を促進し、 Oracle と共にコミュニティを代表して活動したく思っているが、
それとして、OGB は 2010 年 8 月 16 日までに OpenSolaris の将来および
OpenSolaris コミュニティとの相互作用について話す権限を持った連絡役を
Oracle が 指名することを必要としている。さもなければ、OGB は 8 月 23 日
の会議において Oracle へコミュニティの管理を返還する OGB 憲章の条項を
発動するための行動を講じる。
http://mail.opensolaris.org/pipermail/ug-jposug/2010-July/002181.html

145 :デフォルトの名無しさん:2010/07/26(月) 16:20:31
windowsで起動して日常的に使っているアプリの大半はオープンプロジェクトのソフトなんだし、openglもこなれてきたからwinである必要はないでしょ。
ただし無料ソラリスがなくなって、デスクトップ・クライアントPCがlinux一色になっちゃうのは辛いな。
最近だとPCなんか5万前後で新品が手に入るのに、未だにPCは一人1台だからOSライセンスも各PC必要なんていうビジネスモデルにすがっているんだろう・・・

146 :デフォルトの名無しさん:2010/07/26(月) 21:55:53
>>145
家のPCは全部OpenSolarisなんでしょうね。

147 :デフォルトの名無しさん:2010/07/27(火) 18:52:25
OpenSolaris無くなるの・・・
その前に、Linuxに取りこめるライセンスでオープンソースにしてくれよ・・・
Oracleはbrtfs使ってZFS使わねえんだろ?

jdk7 build102
http://dlc.sun.com.edgesuite.net/jdk7/binaries/index.html
http://www.java.net/download/jdk7/changes/jdk7-b102.html

Hotspot support for modules image ・・・これって、
とうとうモジュールの対応開始ってこと?

148 :デフォルトの名無しさん:2010/07/27(火) 20:39:06
>>147
chengesetの内容見る限り、スタートアップjarの扱いを変えてるだけに見える。

そーいやARMが入ったんじゃなかったか?

149 :デフォルトの名無しさん:2010/08/03(火) 23:11:05
JavaのSAMbdas
http://www.infoq.com/jp/news/2010/08/sambdas-in-java

150 :デフォルトの名無しさん:2010/08/04(水) 09:44:48
今更だなあ
誰がどう考えても最初から>>149以外ありえないと思うけど

151 :デフォルトの名無しさん:2010/08/04(水) 09:47:12
そこには書いてないが、>>109みたいな話も出てるし
たぶんそのまま行くことはないだろうと思うが。

yieldについても非難轟々だったしねぇ。

152 :デフォルトの名無しさん:2010/08/04(水) 10:36:58
>>148
入ったのは AutoCloseable だけじゃね?
下のchangeset待ちっぽい

># Changeset 13354e1abba7
> * 6911256: Project Coin: Support Automatic Resource Management (ARM) blocks in the compiler
> * 6964740: Project Coin: More tests for ARM compiler changes
> * 6965277: Project Coin: Correctness issues in ARM implementation
> * 6967065: add -Xlint warning category for Automatic Resource Management (ARM)

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

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)