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

【Java SE 7】次世代 ..

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

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

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

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

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

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

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

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

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

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

519:デフォルトの名無しさん
09/01/11 23:49:01
>>510
URLﾘﾝｸ(www.javac.info)
これを読んで、あなたが何を言ってるのか理解しました。

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

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

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

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

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

522:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/01/12 10:19:16
それって多重継承の問題が出てくると思うけど名前空間はどうやって解決してるの？

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

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

526:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/01/12 11:04:37
そんなにC＃が好きならC＃でやれよ。
いつのまにか君もMS信者になっちまっちゃってるのかも。

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

529:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/01/12 11:18:55
Javaスレで違う言語の話ばかり延々とされてもな

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

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

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

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

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

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

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

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

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

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

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

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

543:デフォルトの名無しさん
09/01/12 13:06:39
URLﾘﾝｸ(journal.mycom.co.jp)
ここにあるような自動クローズ機能を持つ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:デフォルトの名無しさん
09/01/12 13:06:48
クロージャは導入されるから安心しろ。問題はそれがいつになるかだけ。
それと、専売特許以前に、C＃とJAVAを比較しても全く意味ない。もともとC#（.Net)がJava/JVMのマネでしょｗ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

591:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/01/13 12:02:33
関数ポインタとメソッドポインタは全然違うわけだよ
メソッドポインタを関数ポインタで無理やり書けば

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

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

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

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

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

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

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

599:デフォルトの名無しさん
09/01/13 23:54:12
>>597
URLﾘﾝｸ(www.sanseido.net)

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

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

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

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

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

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

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

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

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

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

はよ対応しろ

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

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

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

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

614:デフォルトの名無しさん
09/01/14 13:43:31
>>609
こういうのか？
URLﾘﾝｸ(www.nikkeibp.co.jp)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

638:デフォルトの名無しさん
09/01/17 22:58:19
URLﾘﾝｸ(www.atmarkit.co.jp)
これはいつJavaに入りますか？

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

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

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

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

642:デフォルトの名無しさん
09/01/18 05:28:59
LINQだけど、ODBMSの標準化界隈では一応こんな話もあるという事で。
URLﾘﾝｸ(www.odbms.org)

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

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

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

645:デフォルトの名無しさん
09/01/20 11:42:31
>>163
JWebPaneﾏﾀﾞｰﾁﾝﾁﾝ

646:デフォルトの名無しさん
09/01/20 11:53:08
JDK7 build43
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)

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

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

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

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

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

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

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

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

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

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

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

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

657:デフォルトの名無しさん
09/01/30 05:02:50
なんで？

658:デフォルトの名無しさん
09/01/30 07:45:42
jdk7 build44
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(www.java.net)

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

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

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

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

663:デフォルトの名無しさん
09/01/30 13:02:09
なんのこと？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

？

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

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

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

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

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

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

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

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

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

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

686:デフォルトの名無しさん
09/01/31 17:11:26
CharacterがNumberを継承してないあたり、
Sunでも当初から「charは数ではない」との認識は
あったんじゃないかな。

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

687:デフォルトの名無しさん
09/01/31 17:21:08
いつまでも配列のインデックスが32bitなのはどうなのよ？
ByteBufferのオフセットも32bitだからメモリマップとファイルでも2GBしか
アクセスできなくね？

688:デフォルトの名無しさん
09/01/31 17:28:13
EJB使うと、C/Sプログラムが好きなフォームで作れるからいいよね。

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

689:デフォルトの名無しさん
09/01/31 17:34:39
そーいえば一時期、開発中の NIO2 で
long 使える java.nio.ByteBuffer が置いてあったけど
いつのまにかに削除されてるなぁ。

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

690:デフォルトの名無しさん
09/01/31 17:40:33
そんなにでかいファイルは普通にGC候補じゃないの？

691:デフォルトの名無しさん
09/01/31 17:56:30
Javaの現行の仕様じゃ、RADに対応しきれない。
その点ではC#に分がある。
しかし、C#のポインタはいらないと思うな。
それはC言語でやればいい。

692:デフォルトの名無しさん
09/01/31 18:43:29
>>691
>Javaの現行の仕様じゃ、RADに対応しきれない。

どのあたりが？

693:デフォルトの名無しさん
09/01/31 19:16:02
ここは釣り掘かよ

694:デフォルトの名無しさん
09/02/01 02:01:19
URLﾘﾝｸ(www.atmarkit.co.jp)

695:デフォルトの名無しさん
09/02/01 05:10:27
それでC#狂さんは、どのあたりに不満があるんですか？
C#に不満があるからこのスレに居座ってるんでしょｗ

696:デフォルトの名無しさん
09/02/01 10:29:01
>>692
プロパティがないあたり

697:デフォルトの名無しさん
09/02/01 10:47:58
プロパティがないのは致命的だよな。
コンポーネント指向にできない

698:デフォルトの名無しさん
09/02/01 12:18:59
>>697
コンポーネント指向(笑)
プロパティが無いのは面倒だけど、致命的というほどではないだろ。

699:デフォルトの名無しさん
09/02/01 16:02:59
>>696
RAD用のプロパティ仕様は最初からあっただろ

700:デフォルトの名無しさん
09/02/02 11:01:34
URLﾘﾝｸ(www.atmarkit.co.jp)

701:デフォルトの名無しさん
09/02/02 11:05:04
７０１

702:デフォルトの名無しさん
09/02/03 00:03:34
アクセッサメソッドの為の専用の構文がないだけで、
JavaBeans仕様に乗っ取るなら、IDEが補完するから気にしない。

703:デフォルトの名無しさん
09/02/03 04:33:57
配列プロパティがないのはどうかと思ってる

704:デフォルトの名無しさん
09/02/03 04:43:43
>>703
インデックス付きプロパティがあるから無問題

705:デフォルトの名無しさん
09/02/03 05:40:14
>>704
あったっけ？

706:デフォルトの名無しさん
09/02/03 10:25:27
>>700
なにが言いたい？

707:デフォルトの名無しさん
09/02/03 10:34:22
Python見習ってJavaも後方互換性捨てろって話では？
本人じゃないから外してるかも知れんけど

708:デフォルトの名無しさん
09/02/03 12:36:58
>>705
JavaBeans仕様の「7.2 Indexed properties」に書いてある
ケチ付ける前に仕様に目を通すくらいしろよ

709:デフォルトの名無しさん
09/02/03 12:40:15
おまえみたくヒマ人じゃないんで

710:デフォルトの名無しさん
09/02/03 14:35:29
>>707
それは無理だな
そんあことしたらJavaが捨てられてしまう

711:デフォルトの名無しさん
09/02/03 18:06:29
Pythonのポリシーが同じことの書き方を2とおり用意しない、ということなら、Javaのポリシーは後方互換だからな。

712:705
09/02/03 18:07:48
>>708
見てなかった。ありがとー

713:デフォルトの名無しさん
09/02/03 21:22:52
Java SE 6 Update12 release.

714:デフォルトの名無しさん
09/02/03 21:30:44
java.util.Dateの地獄のようなメソッドリストラ、いい加減に何とかして欲しい。

715:デフォルトの名無しさん
09/02/03 22:30:04
>>709
昼間っから2chやってるヒマ人のセリフかよw

716:デフォルトの名無しさん
09/02/03 22:38:16
>>714
javax.time の地獄のようなクラス群も何とかして欲しい。

717:デフォルトの名無しさん
09/02/03 22:50:34
地獄というほどでもないと思うがDateとCalendarの置き換えにしては大げさすぎだよな。

718:デフォルトの名無しさん
09/02/03 22:52:21
javax.timeいらんくね？

719:デフォルトの名無しさん
09/02/03 23:23:23
>>707
互換性がないなら、そもそもJavaである必要はないと思うんだけどな。
Scalaでいいじゃん、というか。(ScalaのEclipse Pluginはだめだめだけど)

720:デフォルトの名無しさん
09/02/03 23:31:24
次世代 Javaである
Java3 の出番だな。

そのまえに Java 2+とJava turboR も出しておこうか

721:デフォルトの名無しさん
09/02/03 23:40:09
自然画モードとPCMを取り入れるんですね。
わかります。

722:デフォルトの名無しさん
09/02/04 19:07:26
書き換えられるなら、高速モードで動かせるのか。

723:デフォルトの名無しさん
09/02/06 15:45:56
そういやさ、jdk7のビルドは淡々と進んでるけど
jdk6u10の成果ってマージされないじゃない？NimbusとかPluginとかの。

jdk7ではいつ取り込むんだろ？
ちょっと迷走しすぎじゃないかな・・・・jdk7

724:デフォルトの名無しさん
09/02/06 17:51:32
nio2とかjsr308とかも独自だし、いつ統合されんだろな？

725:デフォルトの名無しさん
09/02/06 18:02:48
jdk7 build46
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(www.java.net)

typoとかの細かい修正がメイン

726:デフォルトの名無しさん
09/02/09 19:05:02
最近聞かなくなったけどクロージャはどうなったの？
jdk1.6の途中でjavafxスクリプト追加みたいな感じにクロージャも追加になるのかな。

727:デフォルトの名無しさん
09/02/09 20:23:10
C++もそうなんだけど、次の仕様のリファレンス実装をコーディングしていた
最重要人物がMS系の仕事しちゃってるんですよ。
ピンポイントで狙ってるんだと思う。

728:デフォルトの名無しさん
09/02/09 20:32:45
>>726
Devoxxの発表でクロージャ漏れた。>>258あたり

729:デフォルトの名無しさん
09/02/09 21:15:35
クロージャ便利なんだけどなぁ
クロージャを使うにはジャバだと少しトリック使わないといけないし、そろそろ導入して欲しい。

730:デフォルトの名無しさん
09/02/09 21:28:56
>>728
それって完全に決定事項なの？

731:デフォルトの名無しさん
09/02/09 23:06:40
>>730
JCPのページ見てもJava SE 7 Release Contentsみたいな
JSRが見当たらないから、完全に決定事項ってわけじゃなさそうだけど
とりあえず最新の公式発表って感じかなぁ？望み薄なのは確か。

732:デフォルトの名無しさん
09/02/09 23:14:44
だよなぁ。
つまんないなー

733:デフォルトの名無しさん
09/02/13 23:05:58
JavaSE 6 update14 early access
URLﾘﾝｸ(blogs.sun.com)

6u10 の次は、u14が熱いらしいぜ。
GCに手が入っている、期待しよう。

ってか、7はどうなってんの？

734:デフォルトの名無しさん
09/02/14 00:03:23
7は来年だ

735:デフォルトの名無しさん
09/02/14 00:20:00
ﾅ　ﾅﾝﾀﾞｯﾃｰ!!
　Ω ΩΩ

736:デフォルトの名無しさん
09/02/14 00:48:40
>>734

2010年とか書いてあるね
URLﾘﾝｸ(journal.mycom.co.jp)

737:デフォルトの名無しさん
09/02/15 21:21:23
jdk7 build47
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(www.java.net)

738:デフォルトの名無しさん
09/02/15 22:26:39
7の言語仕様ってもう固まったの？
固まってないのにビルドが進んでも全然使う気になれないんだけど

739:デフォルトの名無しさん
09/02/15 22:43:05
お前はここに来る必要すらない

740:デフォルトの名無しさん
09/02/15 22:44:16
言語は変わらんでしょ

741:デフォルトの名無しさん
09/02/15 23:27:17
>>738
固まってない。

jsr308 とか module は統合されるまで時間かかりそうだし
small language change は具体的に何やるのかも良くわからん。
multi catch と null handling と type inference は入りそうだけど、
string switch とかはどーなんだろ？

742:デフォルトの名無しさん
09/02/16 02:16:16
次のリリースはクロージャをキャンセルした代わりにアノテーションだらけになりそうだね。
あとは、nio2とswing frameworkかな。

javafxは使いたけどcpu 2Gが最低必要だからちょっと敷居が高いな。
flashでもそんなにハードリソース必要なのか？
javax.mediaのライブラリに力を入れないで、なんでjavafxのようなメディア操作用API (script language)の方に力を入れるのか良く分からん。

743:デフォルトの名無しさん
09/02/16 03:09:43
>>742
>javafxは使いたけどcpu 2Gが最低必要

この情報ってどこに書いてありますか

744:デフォルトの名無しさん
09/02/16 04:42:19
javafxダウンロードのsystem requiredのところ。もしかしたらcpu 1.8Gだったかも。

745:デフォルトの名無しさん
09/02/16 06:06:52
>>738
Java 7の変化は言語仕様だけじゃないぞ

746:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/02/16 11:16:47
>>742
swing の変更ってどこみりゃわかる？

次ページ