次世代Javaの動向　２

このエントリーをはてなブックマークに追加
1 ：デフォルトの名無しさん：

前スレ
【Java】次世代Java・J2SE1.6の動向【Mustang】
http://pc8.2ch.net/test/read.cgi/tech/1081698555/

関連スレ
【JavaFive】C＃からJ2SE5.xへ進化【TigerShot】
http://pc8.2ch.net/test/read.cgi/tech/1094891986/

http://www.itmedia.co.jp/news/articles/0404/07/news018.html


マルチタスク実現へJava言語改良
Sun幹部によると、2005年に一般リリース予定の「J2SE 1.6」には、
Javaバーチャルマシン（JVM）のアプリケーション共有を強化する「分離」機能が備わり、
ローカライズコンピューティング処理実行のための分離が可能になるという。

米Sun Microsystemsは、Javaバーチャルマシン（JVM）内部での
アプリケーションマルチタスク実現に向けてJava言語の改良に取り組んでいる。
カリフォルニア州サンノゼで開催のClusterWorld Conference & Expoで4月6日、同社幹部が明らかにした。

SunのJavaアーキテクト、ムラリ・カウンディンヤ氏によると、
今秋β版が登場し、2005年に一般リリース予定の「J2SE 1.6」には、
JVMのアプリケーション共有を強化する「分離」機能が備わる。
この機能によってローカライズコンピューティング処理実行のための分離が
可能になり、第2のJVMを要求することなくJVM内部でマルチタスクが行えるようになるという。

　またJ2SE 1.6では、Javaプログラム間の高速通信を可能にする
Sockets Direct Protocolのサポートが計画されている。カウンディンヤ氏によると、
J2SEに施された改良は、その後間もなくJ2EEにも組み込まれる予定。
2 ：デフォルトの名無しさん：2006/05/18(木) 01:05:40
トラックバック:http://pc8.2ch.net/test/read.cgi/tech/1094891986/


以下のスレは、埋まったら今度はこのスレを本スレとしませんか？
【JavaFive】C＃からJ2SE5.xへ進化【TigerShot】
http://pc8.2ch.net/test/read.cgi/tech/1094891986/
3 ：デフォルトの名無しさん：2006/05/18(木) 01:10:17
マ板のスレみたいな名前だからなぁ・・・
4 ：デフォルトの名無しさん：2006/05/18(木) 01:15:46
アンチ厨が群がってくると？

マ板とは区別できるだろうと期待したい。
馬鹿には馬鹿しか集まらないが、
知的な議論が交わされれば
オッサン共はこちらを荒らすことは無いだろう。
もしこっちがあれたらム板のC言語やC++スレ、C#スレまで
荒れることになる恐れがあるので。
5 ：デフォルトの名無しさん：2006/05/18(木) 03:23:27
現代から次世代、次々世代まで

Tiger JDK5.0
ttp://java.sun.com/j2se/1.5.0/ja/docs/ja/index.html
言わずもがな、リリース最新バージョン

Mustang JDK6.0
ttp://java.sun.com/javase/6/docs/index.html [beta]
ttps://mustang.dev.java.net/ [weekly binary snapshot]
ttp://java.sun.com/javase/webnotes/6/version-6.html　[Version6 or 1.6?]
おお、JavaOne期間でロゴ変わってる

Dolphin JDK7
ttps://dolphin.dev.java.net/
まだ、できてない、2006年春スタート予定だったはず。

>>1 の話ってちょいと昔のかなぁ、と思いつつ・・・
BercelonaプロジェクトのMVMの話、どうなってんだろ、と思い出した
つ ttp://research.sun.com/projects/barcelona/mvm/
まだまだ研究レベルで、実際はDolphinで載ればいい方かな、と思ってんだけど。
Dolphinは、言語スペックに大幅改修入るみたいだし、なんとか一緒に入るのかな？
実現されればWebサーバ側で、JVMがデーモンのように上がってる、なんて事になったりして・・・
6 ：デフォルトの名無しさん：2006/05/18(木) 19:22:03
Mustang ベータ2が来月。リリースが9月だっけか。。
Dolphinは2008年半ばだそうな。
7 ：デフォルトの名無しさん：2006/05/18(木) 19:41:51
Windows Vistaへの対応が気になるところ。
Windows版だけ、6月無理とか、制限あったりとかしそうな悪寒。
8 ：デフォルトの名無しさん：2006/05/18(木) 20:02:09
Vista発売の方が延びるから問題ない。
9 ：デフォルトの名無しさん：2006/05/18(木) 20:03:17
Vista 対応って、具体的に何を期待してんだろ？
10 ：デフォルトの名無しさん：2006/05/18(木) 20:17:37
XP SP2上と同じように動くこと。
現状、Vista公開β候補版でボロボロなので。
11 ：デフォルトの名無しさん：2006/05/18(木) 22:17:28
ttp://journal.mycom.co.jp/articles/2006/05/18/javaone3/
＞Mustangの次のバージョンのJava SEはDolphin(Java SE 7)である。DolphinではJavaプ
＞ラットフォームがエコシステムへと発展する方向での拡張を目指すという。具体的にど
＞のような拡張が行われるのかは現在議論が重ねられている最中だが、現時点では次
＞のような新機能の追加が発表されている。
＞
＞プロパティのサポート
＞メソッドリファレンスのレポート
＞クロージャのサポート
＞言語レベルでのXMLのサポート
＞JVM上で動作する動的言語のサポート
＞スクリプト言語サポートの拡張
＞モジュール化のサポート
＞Swingアプリケーション開発のためのツールの充実

Dolphinってこんなに変わるのかよ。プロパティ・サポートとかクロージャのサポートって、
かなり大きな変更のように思うが...
12 ：デフォルトの名無しさん：2006/05/18(木) 23:47:51
クロージャってC# 2.0の匿名メソッドみたいなｱﾌｫなものに
なるんだろうな。
ttp://d.hatena.ne.jp/akiramei/20060503/p2

VM自体がクラス前提になっているから、猛烈にクソなものが平気で
出てくる。
13 ：デフォルトの名無しさん：2006/05/19(金) 00:00:07
>>12
なんでいきなり言い切ってるんだろうか....
C#がクソな実装したからってJavaがそうなるとは限らんだろうに。
実際、いままでJavaの実装で、このC#のようなクソな実装ってあったか？

おれはもしJavaで同じことやったら、実行速度上のデメリットがあっても、
ソースコードとの一致を取って、ループの度に匿名インスタンス生成を
選択するんじゃないかと思う。

それがMS一社で決めてるC#と、コミュニティで決めてるJavaの違いじゃ
ないかと。
14 ：デフォルトの名無しさん：2006/05/19(金) 00:27:05
それってruby の yield?
Genericsみたいにもめても、何とかなるんじゃない？
15 ：デフォルトの名無しさん：2006/05/19(金) 01:49:07
>>13
Generics
16 ：デフォルトの名無しさん：2006/05/19(金) 01:53:58
GenericsってJavaのほうが実装早いだろ
17 ：デフォルトの名無しさん：2006/05/19(金) 01:56:46
Genericsはそんなにクソでもないと思うがなあ。
イレイジャのこと言ってるんだけど、妥当な妥協ポイントだと思うよ。
おかげでcommonsとかそのまま使えてるわけで。
18 ：デフォルトの名無しさん：2006/05/19(金) 03:37:39
>>11
この新機能ってJSRで言うとどれなのかリストあるのかね?
19 ：(・∀・)ｷﾀｺﾚ!!：2006/05/19(金) 12:01:51
「あとは方法を検討するだけ」--サンがJavaのオープンソース化を約束
http://japan.cnet.com/news/ent/story/0,2000056022,20114107,00.htm
20 ：デフォルトの名無しさん：2006/05/19(金) 12:19:32
要は不良債権処理でしょ。マクネリもクビ切られるほどSunがヤバイ状況だから。
21 ：デフォルトの名無しさん：2006/05/19(金) 13:21:22
まくにーりーって会長職にいるんだけど・・・？
22 ：デフォルトの名無しさん：2006/05/19(金) 17:31:28
Linuxディストリにも標準バンドルされる、というのは良いことだな。
23 ：デフォルトの名無しさん：2006/05/19(金) 17:34:01
>>19
会場盛り上がったよ

>>21
明日出てくるよ
24 ：デフォルトの名無しさん：2006/05/19(金) 20:21:37
「JavaVMは汎用OS上で動かさない」---JRockitの開発マネージャにJavaVMの今後を聞く

---今，JavaVMにどんな機能が求められているのか
　環境の変化に対応しなければならない。それは「サーバー仮想化」という動きだ。
VMwareやXenなどのHypervisor技術に基づいた仮想化ソフトを利用するケースが増えている。
一つのハードウエア上で多くのアプリケーションを動作させることになるが，
単に動作させるだけでなく，アプリケーション間の干渉がないようにすることが求められている。
そのためにはアプリケーションごとにリソースを制御しなければならない。 　

---リソースの割り当てはOSが担うのではないのか
　その通り。だが汎用OS（WindowsやLinuxなど）では力不足だ。実行時に（プロセスごとの）
優先順位を付けることはできるが，一定量の（メモリー，CPU，ネットワーク帯域などの）
リソースをアプリケーションに確実に割り当てることはできないのが実情だ。状況によっては，
メモリー上のデータがディスクに書き出されてしまうこともある。そうなれば性能は大きく低下する。

---そうした問題をどうすれば解決できるのか
　“汎用OSを利用しない”というアプローチがある。それを当社では進めている。ハード
ウエア上でHypervisor（技術に基づいたソフト）を動作させ，その上にJavaVM専用のOS
「Bare Metal」（開発プロジェクト名），さらにその上でJavaVMを動作させる。そのよう
な動作環境において，JavaVMごとにリソースを確実に割り当てるという方法だ。汎用OSを
利用しないので確実にリソースを割り当てることが可能だ。JavaVMから見るとBare Metal
はOSに見えるが，汎用OSの機能は備えず，一つのJRockitプロセスを動作させるのに必要
な機能のみ提供する。

http://itpro.nikkeibp.co.jp/article/NEWS/20060519/238478/
25 ：デフォルトの名無しさん：2006/05/19(金) 21:08:00
>>24
つまりどうなるの？
VMとOSの間に仮想化ソフトをかますってこと？？
26 ：デフォルトの名無しさん：2006/05/19(金) 22:31:44
JRockitって、いつの間に無償になってたんだ
27 ：デフォルトの名無しさん：2006/05/19(金) 23:05:29
>>12
>>13
なんかあちこちで勘違いされてるっぽいけど、C#2.0の匿名デリゲートの
仕様は、(レキシカル)クロージャとして妥当だよ。レキシカルクロージャは、
(実行時ではなく)生成時の環境をキャプチャするので、>>12のリンク先の
ような挙動は、極めて普通。Schemeのlambda式によるクロージャや、
RubyのProcオブジェクトによるクロージャの挙動と基本的には同じ。
28 ：デフォルトの名無しさん：2006/05/19(金) 23:22:58
あと、C#の匿名デリゲートの振る舞いについては、langsmith MLの197から
始まっている議論が参考になると思う。
29 ：デフォルトの名無しさん：2006/05/19(金) 23:32:53
そもそもレキシカルスコープというもの自体が、プログラマの感覚から
離れててコンピュータの都合に合わせているもののように思う。
30 ：デフォルトの名無しさん：2006/05/19(金) 23:53:35
>>29
そういう考え方ができないとは言わないけど、歴史的に見れば、逆だと思う。
プログラマの都合に合わせるためにできたのが、レキシカルスコープ。
初期のプログラミング言語のほとんどが、グローバルスコープしか無い
のに対して、最近の言語のほとんどがレキシカルスコープを採用している
のも、それを示していると思う。
31 ：デフォルトの名無しさん：2006/05/20(土) 00:00:49
レキシカルスコープだけに歴史・・・いやなんでもない


プロパティサポートとか次世代の話続けて
32 ：デフォルトの名無しさん：2006/05/20(土) 00:16:20
じゃあ、プロパティの話を。プロパティ自体は、そんなに大きな変更ではない
と思うけど、どうやって取り入れるんだろうね。簡単に考え付くのが、Groovy
みたいにx.hoge -> x.getHoge()、x.hoge = y -> x.setHoge(y)とコンパイラが
変換するというもの。これなら言語仕様の変更は最小限で済みそうだし、
Java VMも変更する必要が無い。ただ、プロパティと同名のフィールドが
あった場合にどちらを優先するか、とかいくつか考えることはあるが。
33 ：デフォルトの名無しさん：2006/05/20(土) 00:34:59
>>30
すまん、Perlでいえばlocalとmyを逆に考えて書いてしまった....
レキシカル＝ローカル だよな。

しかし>>12の例で言えば、
delegate { Console.Write ("{0} ", i); };
ってのは、ループカウンタ i の値をクロージャというもんのコンストラクタに渡したような
もんであり、 i という変数を渡したわけじゃないんじゃないか？

i がそのまま参照として渡されたような印象をうけるC#の動作の方に違和感があるん
だけど。
34 ：デフォルトの名無しさん：2006/05/20(土) 00:36:55
またレキシカルの話題をかいちゃったので、プロパティの話も書くね。

おれはGroovyの@Propertyみたいなのを採用するのかな、と思う。
>>32のいうように、x.hogeとかいう部分はあくまでx.getHoge()のままで、
getter/setterの定義を「@Property hoge」みたいな感じで定義できる、
とかシンタックスシュガー的なもんなのかなあ、と。
35 ：デフォルトの名無しさん：2006/05/20(土) 00:40:53
モジュール化の話は詳細が出てたね。
共有ライブラリで、外部に提供する関数名を限定できるみたいに、
どのクラス、どのメソッドをエクスポートするか定義できるようになる
みたい。

パッケージにスーパーパッケージみたいなものを定義できて、そのなかに
複数のパッケージをまとめて、しかも外部から見えるのはこのクラスとこの
クラスね、とかやれるみたいだね。

Perlのモジュールと似たような感じかな？

一番よくわからん項目は「メソッドリファレンス」かなあ。これなんだろ。

おれは>>11に載ってる項目よりも、NIO2がいつになったら出るのかもう、
待ちくたびれるっつうの。はやくJavaからファイルのメタデータにアクセス
できるようにしてくれよ。
36 ：デフォルトの名無しさん：2006/05/20(土) 00:59:44
>>33
> delegate { Console.Write ("{0} ", i); };
> ってのは、ループカウンタ i の値をクロージャというもんのコンストラクタに渡したような
> もんであり、 i という変数を渡したわけじゃないんじゃないか？

レキシカルクロージャと言った場合、一般的には、まさにiという変数
そのものを渡すようなものを指す。もっと知りたい場合は、Schemeや
Rubyなどの、クロージャを持っている他の言語について調べてみると
良いと思う。

ちなみにこのような仕様になっていることによって、どんなメリットがある
かというと、例えば、次のような「制御構造」を抽象化したライブラリを
作れるという点が挙げられる。JavaやCなどの言語では、制御構造は
あくまで組み込みのものだけど、クロージャがある言語では、新しい
制御構造を提供するライブラリを簡単に作ることができる。

int sum = 0;
list.each(delegate(int i){
sum += i;
});
Console.WriteLine(sum);// listの要素の合計を出力
37 ：デフォルトの名無しさん：2006/05/20(土) 01:05:54
getとsetでプロパティがいいと思います
38 ：デフォルトの名無しさん：2006/05/20(土) 01:18:59
>>36
あ、なるほど、sumという外側のローカル変数そのものが渡っているというイメージね。
参考になったよ。逆に言えば、もともとアクセスできるものを引数で渡している>>12の
例が、ちょっと使い方を誤ってるということかな。
39 ：デフォルトの名無しさん：2006/05/20(土) 02:10:42
言語レベルでのXMLのサポートって、
E4Xみたいなもんが乗るのかな？
40 ：デフォルトの名無しさん：2006/05/20(土) 02:24:26
>>39
なんか、文字通りJavaのソースの中にXMLをそのままかけるらしいぞ。
イメージ的には

XML data = <test><dataset><key name="test"><value>test</value></key></dataset></test>

とかそのまま書けるって感じというか。
正直、まだ利点を見いだせない。シンプルなjavaを複雑にしてないだろうか？
41 ：デフォルトの名無しさん：2006/05/20(土) 02:28:51
VB9にも似たのがあった気が。
誰がつかうんだろう
42 ：デフォルトの名無しさん：2006/05/20(土) 02:29:20
Java的には、クロージャって引数の数によって識別されるRunnableが
あって、いままでいろんなものでそれぞれリスナを作ってたところを、
そういう共通的なRunnableを使って実装する、というイメージなのかな、

という気がした。

inputFile.eachLine( closure(String line) { 行の処理 });

ってなことだよね？
43 ：デフォルトの名無しさん：2006/05/20(土) 02:29:39
そんなん入れるならヒアドキュメント入れろ
44 ：デフォルトの名無しさん：2006/05/20(土) 02:31:34
>>40
またパ...
45 ：デフォルトの名無しさん：2006/05/20(土) 02:37:03
まあ

なんたら.execute(
new Runnable() {
public void run() {
ほげほげ
}
});

って長くてうざかったし、そのシンタックスシュガーを提供してくれる
だけでもうれしいかな。

Wicketだとこの手の書き方大量にするんで....
);
46 ：デフォルトの名無しさん：2006/05/20(土) 04:18:37
もうJavaの拡張はいいよーまた覚えることが増えるだけじゃん
こんなの初心者はついていけないぞ。教えきらん。

>>34
俺もそう思う。たんにgetter/setterの定義を書かなくて済むようになるだけで、
x.getXxx() が x.xxx と書ける訳じゃないと思う。そこまで気が利くとは思えん。

>>36
その例は「制御構造」とはいわないのでは？いうのかな？

>>40
はげどう。JSONサポートならほしいけど、XMLサポートはいらね。

>>43
うおー超はげどう。ヒアドキュメントはだれも要求しないのか？
47 ：デフォルトの名無しさん：2006/05/20(土) 04:46:50
>>46
いや、　 x.xxxだったらpublicのフィールドあったときかぶっちゃうじゃない記法ｗｗｗ
48 ：デフォルトの名無しさん：2006/05/20(土) 05:48:38
>>47
publicのフィールドがあればそっちをつかう、なければsetter/getterを使う、というルールでいいんじゃない？
あるいは逆に、setter/getterがあればそれをつかい、なければフィールドを探すか。
どっちにしろ、どうルールを決めるかの問題。
いらないけどね。

それより、配列や文字列の長さをELからも参照できるようになってほしい。
str.getLength()じゃなくてstr.length()だから、ELからはstr.lengthとは参照できない。
関数使わなきゃいけないのなんてかっこわるい。全然オブジェクト指向じゃない。
49 ：デフォルトの名無しさん：2006/05/20(土) 08:55:32
シンタックスシュガーでいいのでは？
だからべつにgetやsetをかくと重複していますというエラーがでればいい
isをどうするかは今でも同じ話だしな

互換性を考えればコレしかないかと

どのみちIDEの機能で意識はしてないけど、プロパティ扱いでまとめてくれると見やすいからね
折りたためるようになってくれればいい

50 ：デフォルトの名無しさん：2006/05/20(土) 09:32:17
>>36
その例は「レキシカル」クロージャの有益な例にはなってないよね。
クロージャの有益な例というだけで。

>>30
それは少し極端かな。両方の理由があった。
効率のいい実装、デバッグしやすい意味など。
51 ：デフォルトの名無しさん：2006/05/20(土) 09:45:30
>>48
そのlengthもプロパティで解決だね。

>>35
メソッドリファレンスは、
単純な(doAction()のみなど)Listenerを設定する時に、
extends 〜Listenerなクラスを定義しなくても、
既存のクラスのメソッドをそのまま指定できるんでしょ、たぶん。

C++でいうところのstd::mem_fun_refじゃないかと。
boost::signalsと一緒に使ったりする。
52 ：デフォルトの名無しさん：2006/05/20(土) 11:16:08
>>40
そいで for (XML d : test.dataset[0].key) { System.out.println(d.key.value); }
とかアクセスできたらまんまE4Xじゃないか。俺的には超OK。
53 ：デフォルトの名無しさん：2006/05/20(土) 11:59:47
>>50
36だけど、例として挙げたプログラムだと、レキシカルクロージャの特徴で
あるキャプチャされた変数が無限の寿命を持つという点を生かしてない
という話かな？確かにその通りではあるんだけど、それを生かしたプログラムは、
Schemeではよく出てくるけど、C#ではオブジェクトがあればほとんどの場合、
代用できてしまうので微妙かなと思う。
54 ：デフォルトの名無しさん：2006/05/20(土) 12:02:43
>>52
その例を見て思ったんだが、もしかして、プロパティの導入目的は、
言語レベルでのXMLのサポートを、より効果的に行うためなのかも。
55 ：デフォルトの名無しさん：2006/05/20(土) 13:00:54
>>53
そう。あとdynamic bindingでも、lexical bindingでも同じ意味。

Schemeのようなクロージャは強力すぎるけど、
C++の式テンプレートくらいの機能は欲しいなあ。

C#の匿名メソッドは、>>12のページにあるように、
引数に与えられた式を使ってクラスを定義するみたいだから、
変数や関数の参照は、名前呼び出し風って事になるのかな。ちょっと使いにくそう。

> オブジェクトがあればほとんどの場合、代用できてしまう

まさに式テンプレートですね。
Javaに式テンプレート入れると、型システムのルールが、
クロージャの引き数のところだけ変わるから無理そうだけれども…
56 ：デフォルトの名無しさん：2006/05/20(土) 15:32:18
>>55
>そう。あとdynamic bindingでも、lexical bindingでも同じ意味。

確かにそうだね。というわけで、dynamic bindingじゃできない例を作ってみた。
クロージャの話でよく出てくる古典的な例なので、またかよって思うかもしれんが、
そこは見逃してくれるとありがたい。Converterってのは、.NET Framework 2.0
で入ったdelegate型で、ある型を受け取って別の型(同じ型でもいいけど)を返す
メソッドを表す型ね。

using System;
class TestLexicalClosure {
/* カウンタを作って返すメソッド */
static Converter<int, int> Counter(int start){
return delegate(int n){ return start += n; };
}
static void Main(string[] args){
Converter<int, int> counter = Counter(0); //カウンタを作る
Console.WriteLine(counter1(1)); // => 1が表示される
Console.WriteLine(counter1(2)); // => 3が表示される
}
}

> 引数に与えられた式を使ってクラスを定義するみたいだから、
> 変数や関数の参照は、名前呼び出し風って事になるのかな。ちょっと使いにくそう。

これは意味がよくわからなかった。もうちょっと詳しく言ってくれるとありがたい。
57 ：デフォルトの名無しさん：2006/05/20(土) 15:34:32
ミスった。counter1って書いてあるところは、counterの間違い。
58 ：デフォルトの名無しさん：2006/05/20(土) 16:49:51
もう、マクロでよくね？
59 ：デフォルトの名無しさん：2006/05/20(土) 17:32:29
>>56
class TestLexicalClosure {
int _start;
/* カウンタを作って返すメソッド */
static Converter<int, int> Counter(int start){
_start = start;
return delegate(int n){ return _start += n; };
}
じゃなくてもいいの?

http://blogs.msdn.com/abhinaba/archive/2005/10/18/482180.aspx
http://ant0x.udap.jp/material/mat_AnonymousMethod.htm
http://www.divakk.co.jp/blog/aoyagi/archive/2005/10/27/7038.aspx

とか読むとめまいしてくるんだけど…

結論としてはC#のanonymous methodと同じものならJavaにはいらない。
60 ：デフォルトの名無しさん：2006/05/20(土) 17:57:00
>>59
55のコードで大丈夫。実行して、ちゃんと動作することも確認した。
あと、59のコードだと、複数のCounter()を複数回呼んで、複数個の
カウンタを作っても、カウンタの値が共有されてしまうので、まずい。
ポイントは、匿名デリゲートから参照されている外側のローカル変数は、
それが宣言されたスコープを抜けても生きているということ。

>とか読むとめまいしてくるんだけど…

>結論としてはC#のanonymous methodと同じものならJavaにはいらない。

俺はむしろC#のanonymous method的な振る舞いじゃないと嫌だなあ。
あと、anonymous method(というかクロージャ)の振る舞いに関して、
どの辺がめまいがすると感じた？
61 ：デフォルトの名無しさん：2006/05/20(土) 18:39:43
あのコードみて問題ないと感じるのがすごいな
なぜそうなるかは実装側の都合という状態
62 ：デフォルトの名無しさん：2006/05/20(土) 18:43:16
一番内側のブロックがクラスに変換されるの? > 匿名メソッド@C#
>>59の二つ目のページ読むとそんな感じなんだが。
>>56では、Counter()が一番内側のブロックだから、
引数は変換されたクラスのメンバ変数になるってこと?
63 ：デフォルトの名無しさん：2006/05/20(土) 20:30:15
>>61

>>59の3番目のリンク先は、仕様書のバグということで問題だと
思うが、1番目と2番目のリンク先の挙動は、本当に問題無いよ。
実装側の都合でそうなっていると勘違いしているようだけど、
レキシカルクロージャになるように匿名delegateを実装したら
そのような実装になったというだけのこと。あと、1番目のリンク先
の人はレキシカルクロージャという概念を勘違いしてて、コメント
欄で突っ込まれまくってる。

>>62
実装としては、一番内側のブロックが…とかいうのではなく、匿名
デリゲートから匿名デリゲートの外側のローカル変数を参照していた
場合、参照されている変数をメンバ変数として持つクラスが生成される
ということ。
64 ：デフォルトの名無しさん：2006/05/20(土) 20:37:29
>>63
いや、なぜそうなるか、は昔からいわれてたけど
それが本当に書く人が理解でき照るかというのとは別だと思う

書いた本人ならまだしも、他人のコードをさらっと斜め読みして
結果を予想できるかという割れると厳しいかも
65 ：デフォルトの名無しさん：2006/05/20(土) 20:45:13
>>64
> それが本当に書く人が理解でき照るかというのとは別だと思う

それは確かにその通りだけど、このスレではなんか、匿名delegateの
セマンティクスが実装の都合だという風に誤解されてるようなので、
それは違うんだと言いたかった。

> 書いた本人ならまだしも、他人のコードをさらっと斜め読みして
> 結果を予想できるかという割れると厳しいかも

レキシカルクロージャという概念に馴染みの無いユーザが驚く可能性は
あるかもしれないけど、よっぽどトリッキーな使い方をしてない限り、
どう動くかというのは、簡単に予想できるんじゃないかなあ。
66 ：デフォルトの名無しさん：2006/05/20(土) 21:19:49
二つ目のページで、
static D[] F() {
D[] result = new D[3];
int x;
for (int i = 0; i < 3; i++) {
int y = i * 2;
x = i * 2;
result[i] = delegate { Console.WriteLine(x + y); };
}
return result;
}
だと、[4 6 8](=[0 2 4]+[4 4 4])なんだろ?
変換結果のILはどうなるんだ?

メソッドb__0()は、xとyをどうやってaccessするんだ?
別のインスタンス内にあるはずだが…(宣言のある場所で閉じ込めるインスタンス生成)
それとも「一番内側の」ブロックで生成するインスタンスに全部含めるのか?
そうすると[8 8 8]か?
67 ：デフォルトの名無しさん：2006/05/20(土) 21:48:53
delegate自体C#の構文はよくないねぇ
68 ：デフォルトの名無しさん：2006/05/20(土) 22:27:16
>>66
ILを含めると長くなるので、その辺は省略して、宣言だけ示すと、大体こんな感じになる。
DisplayClass3のフィールドとして、DisplayClass1のフィールドを持っているので、b__0(匿名
デリゲートのコード本体)からはxとy両方にアクセスできる。

class <>c__DisplayClass1 {
public int x;
}
class <>c__DisplayClass3 {
public DisplayClass1 <>8__locals2;
public int y;
void <F>b__0(){/* 匿名デリゲートの中身が入る */}
}

というわけで、結果は[4 6 8]で正しい
69 ：デフォルトの名無しさん：2006/05/20(土) 22:36:35
苦労じゃなんて使うんかい
70 ：デフォルトの名無しさん：2006/05/21(日) 03:36:44
おればかだから>>12,27,33,36の話がよくわかんなくて、groovyでコード
>>12の参照先とほぼ同じ書いてみてやっと分かった。

def closures = []
for( i in 0..10) {
closures[i] = { println i }
}
for( c in closures) {
c()
}

結果は同じように10がずらっと表示された。
これは、closuresに入っている各クロージャは、クロージャ外側の変数 i に
そのままアクセスできるわけだけど、実際に実行されるc()の段階では、
i は既に10になっちゃってるから、これがずらっと表示されると考えて
やっとしっくりきた。

>>56は
def makeCounter( start) {
return { n -> return start += n }
}
def closure = makeCounter(0)
println( closure(1))
println( closure(2))

ってな感じなんで、つまりクロージャから参照された変数 start は、変数自体がスコープを
越えてもクロージャ内では普通につかえるし、クロージャがある限り存在しつづける、と。
インナークラスがエンクロージングクラスのインスタンス変数にアクセスできるようなもん
だけど、クロージャにはクロージャのスコープがあるので、一度クロージャが使った変数は
クロージャ内で存在し続ける、ということか。
71 ：70：2006/05/21(日) 03:37:53
groovyでコード>>12の参照先とほぼ同じ書いてみて
↓
groovyで>>12の参照先とほぼ同じコード書いてみて
72 ：デフォルトの名無しさん：2006/05/22(月) 23:01:22
んで、結局Dolphinで対応されるのは
どういう機能なわけ。まだ曖昧にも決定してない？クロージャって単語だけが歩いてる？
73 ：デフォルトの名無しさん：2006/05/23(火) 03:13:41
匿名クラスのシンタックスシュガーには間違いなさそうだな。
74 ：デフォルトの名無しさん：2006/05/25(木) 06:26:42
嬉しい誤算発見
JavaでのサブピクセルAAレンダリングはJavaのレンダリング使うからか
リモートデスクトップ経由でも有効だね
ピクセルの構成が一致してないとつらいとは思うが
75 ：デフォルトの名無しさん：2006/05/26(金) 01:39:14
プロパティマンセー

obj.setWidth(obj.getWidth() + 1)) なんて書かなくてもよくなりてぇえええ
76 ：デフォルトの名無しさん：2006/05/26(金) 04:15:52
じゃ、
obs.width = obj.width +1 ;
になるわけか・・・・
なんか、VBのProcedureみたい。(VB4の知識で書いてます悪しからず)
77 ：デフォルトの名無しさん：2006/05/26(金) 06:14:57
>>75,76
ほんとにそうなるの？
おれはgetter/setterの定義を書かなくて済むようになるだけだと思ってた。
ソースきぼん。
78 ：デフォルトの名無しさん：2006/05/26(金) 08:33:46
>>77
むしろそっちがソースｷﾎﾞﾝ。
getter/setter だけなんて、中途半端じゃん。
79 ：デフォルトの名無しさん：2006/05/26(金) 09:09:56
>>78
いや、ソースはない。「プロパティがサポートされる」と聞いて、どうせgetter/setterが自動生成される程度で、getXxx()/setXxx()は使わないといけないのだろうと思った。それだけ。
80 ：デフォルトの名無しさん：2006/05/26(金) 13:25:01
>>79
getter/setterの定義よりも、それらにアクセスするコードを書く回数の方が
圧倒的に多いので、getter/setter自動生成だけだと、新しい言語機構を
導入するメリットが少なすぎる。だから、たぶんアクセスするときの便宜も
図られるんじゃないかなあ。
81 ：デフォルトの名無しさん：2006/05/26(金) 13:54:31
こんなんもいけるんかのう？
obs.width++;
82 ：デフォルトの名無しさん：2006/05/26(金) 15:16:13
>>78
ライトアクセスとリードアクセスを区別して grep できないのはやだなぁ。
83 ：デフォルトの名無しさん：2006/05/26(金) 18:35:27
>>82
呼び出し階層の検索でいけるんじゃないの？ たぶん。
あ、ごめん、これはEclipseの話だな。。。
84 ：デフォルトの名無しさん：2006/05/26(金) 23:12:33
とはいえピリオドでやっちまうとメンバ変数のwidthとgetWidthメソッドとの判断が難しいよな

obs@widthとかobs->widthとかなんか特殊な構文が追加なのかも
getsetかかせるよりはいいけどね
85 ：デフォルトの名無しさん：2006/05/26(金) 23:26:41
>>84
C/C++ で使われてる -> よりは @ に賛成。
Character.isJavaIdentifierStart('@') も false 返すみたいだし、
やろうと思えばできるのかな？

あと、JSR 295 見ると、converter や validator 使って何かやるみたいね？
obs@width = "120"; とかやると勝手に StringToIntegerConverter を
使ったコードを挿入してくれるのかな？ とか妄想してみる。
86 ：デフォルトの名無しさん：2006/05/27(土) 00:14:26
245なんかのProperty Resolver APIが言語に入るんでしょ。
operator.のoverload。
Property Binding API, Method Biding APIなんかも。
87 ：デフォルトの名無しさん：2006/05/27(土) 11:49:33
>>80
Java��にそんな気の利いたことを望んではいけない。
ヒアドキュメントすらない言語だ、「互換性」を楯にして、最小限の使用追加だけですませるだろう。

しかしほんとに後付けの機能がふえるよな。もうぜんぜんシンプルな言語じゃなくなった。
88 ：デフォルトの名無しさん：2006/05/27(土) 11:58:45
プロパティに関しても1.1での後付考えかただし1.0はアルファ品質だったしな
それでもプロパティはEODでは？
用意するほうはIDEがやってくれるけど使うほうが原始的杉

Genericsは開発効率がよくなりバグが大幅に減るすばらしいものだが
落ちこぼれるやつが多数いる

この程度でおちこぼれるのならそいつはこの業種向いてないとは思うのだが
ひとつの判断材料にはなるかも

lockはsynchronizedのように専用構文がないと厳しいような
なんでもそうだが資源解法でfinallyあてにするのは苦しいよな
89 ：デフォルトの名無しさん：2006/05/27(土) 12:01:11
いますでにgetXXX, setXXXの存在を前提として作られているフレームワークが
やまほどあるので、基本的にはシンタックスシュガーになるんだろうな。

obj.prop = xxx とか書くにしても、バイトコード上では setProp(xxx)になってるとか。
90 ：デフォルトの名無しさん：2006/05/27(土) 12:07:39
そりゃそうだろ
91 ：デフォルトの名無しさん：2006/05/27(土) 12:21:18
>>88
俺はC++も好きなタイプなので、
Javaの言語領域で機能増えるのは嬉しい気持ちもある反面、
やりすぎて失敗しないのを祈りたい気持ち。
既に十分複雑だからね。抱えているプログラマ層を考えると。
92 ：デフォルトの名無しさん：2006/05/27(土) 13:03:03
Perlがあんだけ使われてるのみると、記号が増える分には問題なさそうだ。
93 ：デフォルトの名無しさん：2006/05/27(土) 13:36:50
ヒアドキュメントって、国際化対応とかどうするの？
94 ：デフォルトの名無しさん：2006/05/27(土) 17:59:29
それでなくても、ヒアドキュメントなんか、めったに使わないからな。
めったに使わないもののためにコンパイラ作りにくくすることもない。
95 ：デフォルトの名無しさん：2006/05/27(土) 19:15:47
ヒアドキュメントはあかんでしょ
なんでヒアドキュメントかっていうと基本的に書く側の都合じゃない
そこに書きたいっていう。
視認性は悪くなるし文法なんて無茶苦茶。
あれを使いたくなる理由は、簡易テンプレートエンジンとして使えるからだと思うんだけど
テンプレート処理がしたいんだったらIDEとか開発ツールのアシストで
何とかなると思うんですけどね。
ScriptingAPIと同じ扱いでいいんじゃないかと思う。
あれも構造が類推できないスクリプト言語がソースにヒアドキュメント形式で生で埋め込まれてたらと思うとぞっとする・・・
96 ：デフォルトの名無しさん：2006/05/27(土) 19:54:22
>>94
ちょっとまて、ヒアドキュメントごときでなんでコンパイラが作りにくくなるのだ？
あんなの、字句解析部をちょこっといじれば済む機能だぞ。
おまえ、コンパイラの作り方もわかってないだろ。

>>95
ヒアドキュメントで済むことをIDEとか開発ツールのアシストを使わなきゃいけないということに疑問をもたないのか。
HTMLページをまるごと埋め込むのならアホだけど、テストデータとその期待値を埋め込むのなら
ヒアドキュメントはすごい便利なんだけど。

つーか、「そんな機能必要ない」「IDEのサポートがあれば十分」とかいってるやつらって、実際その機能が追加されたら「これはEoDを実現するすばらしい機能だ」とか言い出すんだろ。
Genericsだって、最初は「C++のテンプレートは複雑だから同じような機能はJavaには必要ない」とか揃っていってたくせに、いざ実装されるとみんなGenericsマンセーなんだよな。
プロパティだって、今までgetterとsetterはEclipseが自動生成してくれるから問題ないとか言ってたくせに、それが実装されると「これは便利だ」とか言い出すんだぜ、絶対。
Javaにない機能は「そんなの必要ない」と言い切り、実装されれば「すばらしい進化だ」と手のひらを返す。ほんと学習しねーよな。

>>93
なんで国際化が必要なん？ふつうにStringリテラルと同じ扱いでいいじゃん。
97 ：デフォルトの名無しさん：2006/05/27(土) 20:01:41
ヒアドキュメント作るとして、懸念があるとすれば改行記号の扱いぐらいかな？
98 ：デフォルトの名無しさん：2006/05/27(土) 20:02:14
>>96
だから当時「いらない」と言ってた人たちは恥ずかしくなって黙ってしまって、
今度は別の人が別の機能に「いらない」といってる、くらいの想像力はないのか？
実際まったく同じ人だったらキモイだろう。

ヒアドキュメントはあれば便利だと思う。
一方でコンパイルされたバイトコードの中（つまりはclassファイル）の中に
そのヒアドキュメントの内容が埋め込まれるんだったらダサすぎなのでペケかな。
99 ：デフォルトの名無しさん：2006/05/27(土) 20:04:24
>>96
> 最初は「C++のテンプレートは複雑だから同じような機能はJavaには必要ない」とか
そんな阿呆な事言ってた奴は居るのか？

少なくとも俺は聞いたこと無いぞ。
erasure よりマシな実装方法もあったんじゃないの？ って話なら結構聞いたけど。
100 ：98：2006/05/27(土) 20:07:46
あ、しかしまあ、String document = ""が自動生成されると考えると
さほどヘンでもないか。

しかし一方で、ヒアドキュメントってドキュメント中に変数値を簡単に
埋め込めないとあまり使い道がないと思うんだがどうだろうね。
式言語っぽく${変数名}なんてのを採用すると、式言語パースが必要に
なるかな。
101 ：デフォルトの名無しさん：2006/05/27(土) 20:15:06
Stringで生成されるなら%dとか%sでいいだろ
何のためのフォーマッタだ
102 ：デフォルトの名無しさん：2006/05/27(土) 20:25:12
それだとあとから変数をセットしなくちゃいかんじゃないか。
103 ：デフォルトの名無しさん：2006/05/27(土) 20:43:44
>>102
そういうことなら、ドキュメントの生成とその中の文章の埋め込みまで
やっちゃわないと駄目ね
>>96
そのアホが出てくるからコードのメンテナンス性が落ちちゃうんだよなぁ
でもそれは、コーディング規約でやらないようにさせるっていうのなら
ツール用意して・・・・っていう話と比べてもどっちもどっちだと思うが
他の言語で利用されて便利なヒアドキュメントのいいところだけをＪａｖａらしく取り込んでくれれば
いいとは思う。

特殊なコメント記法を入れて、コメントを識別子つけて参照できるようにするってのはどうかな？
/***
<html><body>
ほげひげは、${age}歳です
*/
あ、名前つけんのどうしよう

それよりは、特殊な改行付き文字列定義をかけた方がいいか・・・・
String document = '''
<html>ほべー
げれげれー
</html>''';
うーん、ターミネータがきめうちなだけのヒアドキュメントになったぞ。
104 ：デフォルトの名無しさん：2006/05/27(土) 23:11:41
>>96
> なんで国際化が必要なん？ふつうにStringリテラルと同じ扱いでいいじゃん。

そりゃそうだよね。
javacのソースの文字コード、
Shift_JISがディフォールトなのそろそろやめてくれないかな…
105 ：デフォルトの名無しさん：2006/05/27(土) 23:13:48
>>104
なにいってるの？
106 ：デフォルトの名無しさん：2006/05/27(土) 23:40:47
javacのソースの文字コードのデフォルトは、プラットフォームのデフォルトと
一致している予感。
107 ：デフォルトの名無しさん：2006/05/27(土) 23:41:29
>>104
LANG=ja_JP.UTF-8
export LANG
108 ：デフォルトの名無しさん：2006/05/27(土) 23:59:04
>>107
どこのJDKよ?
109 ：デフォルトの名無しさん：2006/05/28(日) 00:09:32
馬鹿が涌いてるな。
110 ：デフォルトの名無しさん：2006/05/28(日) 00:13:00
>>99
そうだね。Genericsに関しては、初期の頃からJavaプログラマの間でも、
Javaの欠点として言われていたし、Javaを拡張してGenericsを導入して欲しいという
提案も比較的初期の頃からあった。まあ、最近になってJavaにかぶれた人で、
ひょっとしたらそういう人は居るかもしれんが、ごく少数だろう。
111 ：デフォルトの名無しさん：2006/05/28(日) 00:47:29
オプションつければええやん
仕事でコード書くときは、普通レポジトリ中のロケール合わせて
ビルドオプションにもそれ入れておくでしょ？

まぁあの書き方からして>>106をしてるっぽいんだが・・・・

>>110
複雑でいらねっていわれてたのは、ポインタと演算子のオーバオードだという記憶だねぇ
それが、今度はとうとう . 演算子をオーバロードすることになるわけか・・・
112 ：デフォルトの名無しさん：2006/05/28(日) 01:26:57
Parameterized typeもいらないって言っていたヤツいたけど、総じて馬鹿だった。
113 ：デフォルトの名無しさん：2006/05/28(日) 01:46:46
演算子のオーバーロードまではいかないんじゃない？
Java 5がでたときのインタビューかなんかでも、演算子のオーバーロードは
Javaを複雑にするので入れたくない、とSunの誰かが答えてたはず（ソース見つからず）

プロパティを obj.prop = value で設定できるようになったとしても、それはオーバーロード
とは言わんと思うし（シンタックス・シュガーだよね）

Dolphinでオーバーロードをサポートするとか言う発表があったんだっけ？
114 ：デフォルトの名無しさん：2006/05/28(日) 03:11:55
>>99
Gosling自身が「いらない」と言っていたんだけど。Bill Joyは「parameterized typeがあればどんなにいいだろう」といってたけどな。
つか、ほんとに聞いたことないのか。それはいくらなんでも世界狭すぎだろ。
あれか、恥ずかしい過去はなかったことにしたがってる連中か。
EJBのときとかわんねーな。あれも推進派だった連中が今は「やっぱりEJB2は複雑だったよな、アノテーションマンセー」だもんな。自分たちがどれだけEJBを押し付けてきたのか忘れたらしい。
foreach文もそうだよな。foreach文なんていらね、Iteratorパターン最高といってたヤシばかりだったのにな。
ほんと恥ずかしい過去はなかったことにしたいらしい。
115 ：デフォルトの名無しさん：2006/05/28(日) 03:23:36
foreachは聞いた事ないけど
116 ：デフォルトの名無しさん：2006/05/28(日) 03:48:27
いやいくらなんでもEJB2が複雑じゃないなんて話は聞いたことがない。
EJB2じゃないけど、Strutsだって「あれは壮大なネタだろ」とか言ってたくらいで、全般的に
冗長なフレームワークは嫌われてたように思うが。

genericsでは何度か見たが、一方でMapがタイプセーフでないことに苦しめられたって
意見もあったわけで、バランスは取れてただろ。

Java言語をシンプルなままにしておきたいという希望は俺にもある。一方で、書くのが楽に
なって欲しいという希望もある。一人の中でもせめぎ合いがあるんだから、スレ内でどっちの
意見が出たって不思議には思わんがね。
117 ：デフォルトの名無しさん：2006/05/28(日) 03:56:09
>>96
ヒアドキュメントがあると、文脈自由文法じゃなくなってしまうからJavaCCとかのパーサージェネレータで作りにくくなるよ。
118 ：デフォルトの名無しさん：2006/05/28(日) 05:33:15
>>116
EJB2が複雑という意見はあった。しかし、それは一部の開発者のみ。EJBを推進する連中のほうがずっと多かった（理由は「それが標準だから」だとさ）。
Strutsだって同じだろ。雑誌記事みればわかるじゃん。どれもEJBマンセー、Strutsマンセー。
EJBやStrutsを明確に批判したのはRodやTateなどごく一部。日本じゃ皆無。

>>117
単純なヒアドキュメントは字句解析だけで実現できる。パーサはいじる必要ない。

つうかな、これだけ機能がごちゃごちゃ増えてるのに、ちょっと文法たすだけなのがなんで問題なんだ。
今のJavaはコンパイラ作るのがすごい面倒な言語になったけど、それは機能が増えたせいで構文解析よりあとが大変になったからだろ。
それにくらべたら、構文解析までなんて簡単。ヒアドキュメントの追加ぐらいわけない。
ほかにずっと大きな問題があるのを見ないふりして、「パーサジェネレータで作りにくくなる」なんてささいな問題をとりだすなよ。
119 ：デフォルトの名無しさん：2006/05/28(日) 06:11:10
>>118
少なくとも、ヒアドキュメントは「ずっと大きな問題」じゃないな。
120 ：デフォルトの名無しさん：2006/05/28(日) 06:38:50
>>118
つ ttps://mustang.dev.java.net/
時代は貴方を求めています。言い出しっぺの法則ってことでﾖﾛﾋﾟｸ
121 ：デフォルトの名無しさん：2006/05/28(日) 08:04:10
俺はforeachいらねーわ。
122 ：デフォルトの名無しさん：2006/05/28(日) 09:46:04
>>114
GoslingがGenericsをいらないと言っていたというのは、信じがたいのだが。ソース希望。
Java House MLのアーカイブやその他の場所で引用されていた過去のGoslingの発言を見る限りでは、
Genericsの導入には前向きだったように思える。

あと、世界狭すぎなのは自分の方なのかも、って考えは無いのかね。
123 ：デフォルトの名無しさん：2006/05/28(日) 09:53:24
>>118
Rubyにあるような、式を埋め込めるヒアドキュメントはパーザをいじる必要があるけどな。
実際のところ、ヒアドキュメントはあれば便利だろうし、使うだろうけど、そこまでこだわる
程の機能か？あと、そんなにヒアドキュメントが本当に欲しければ、こんなところで
ぐちぐち言ってるよりも公式に提案した方が良いかと。Genericsやその他の言語拡張だって、
要望が多かったから取り入れられたわけだし、ヒアドキュメントも場合によっては取り入れられる
こともあるかもしれん。
124 ：デフォルトの名無しさん：2006/05/28(日) 10:07:39
Goslingが否定的だったのは、
C++のtemplateの特殊化やC++,CLOSなどのgeneric functionだろ。
operator overloadはかなり初期から批判的。

Bill JoyとGoslingが"暴力沙汰"になりそうになったのは、
Billがgenericsはゆっくり考えることにして、generics抜きでJavaをshippingしようとしたから。
Goslingは、進行はJCP任せだけど、collectionのreliabilityを増すと積極的。
C/C++に対する大きなアドバンテージと考えているから。> reliability

http://www.gotw.ca/publications/c_family_interview.htm

125 ：デフォルトの名無しさん：2006/05/28(日) 10:24:43
>>124
本題からはずれるのだが、C++のgeneric function(=テンプレート関数のことか？)
とCLOSのそれ(=マルチメソッド)は全く意味合いが異なるのでは。前者は静的に
呼び出しが決定され、後者は動的に呼び出しが決定されるので。
126 ：デフォルトの名無しさん：2006/05/28(日) 10:44:44
性的か童的か違うと「全く意味合いが異なる」のか?
「関数テンプレート」が正式名称な。C++03で間違っている部分も修正。
127 ：デフォルトの名無しさん：2006/05/28(日) 10:51:28
>>126
全くというと言いすぎだったかもしれんが、少なくとも意味が異なるのは事実。
Javaのメソッド **オーバーロード** とメソッド **オーバーライド** が異なるのと同じ。
関数テンプレートが正式名称というのは、知らんかった。すまん。
128 ：デフォルトの名無しさん：2006/05/28(日) 10:56:49
>>124は、わざわざ"generic function"って書いているんだから、
クラスに属さない多相型の関数のことを言っているのは自明だよ。
性的なw特殊化はわざわざ別に書いているし。
129 ：デフォルトの名無しさん：2006/05/28(日) 12:10:38
>>128
言いたいことがよくわからないのだが、C++には関数テンプレートとは
違う、"generic function"があって、それは、CLOSのように、実行時に
オブジェクトの型に応じて、動的にディスパッチしてくれるのか？
130 ：デフォルトの名無しさん：2006/05/28(日) 12:49:01
"generic function"をCLOSの意味に制限して、
意味不明って言っても仕方ないじゃないの?

一般名詞としての"generic function"は、C++のWGでも出ているよ。
例えば、http://www.research.att.com/~bs/evol-issues.html
generic programmingで使うparametric polymorphismを持った関数が"generic function"。

知らないのはよっぽどうとい人だと思われ。

131 ：デフォルトの名無しさん：2006/05/28(日) 18:45:57
>>130
いや、"generic function"をCLOSの意味に制限したいわけ
じゃなくて、CLOSのそれとC++のそれは意味が異なる機能なのに、
124が
> C++,CLOSなどのgeneric function
と、C++とCLOSのgeneric functionが同じ機能かのように言っていたので、
つっこんだだけ。
132 ：デフォルトの名無しさん：2006/05/28(日) 22:01:40
>>123
ヒアドキュメントはあくまで例のひとつ。
「そんな機能いらね」といってたくせにそれが実装されると意見を180度変えるJava屋さんが多すぎてうざいというのが主張内容。
JCPに提案しろとかポイントはずれてる。
133 ：デフォルトの名無しさん：2006/05/28(日) 22:29:35
>>131
> C++とCLOSのgeneric functionが同じ機能かのように言っていたので、

FUDかよw
134 ：133：2006/05/28(日) 22:52:36
お口直しに、
http://www.osl.iu.edu/publications/prints/2003/comparing_generic_programming03.pdf

結局propertyは>>86の言うように、JSR245なの?
135 ：デフォルトの名無しさん：2006/05/28(日) 23:22:33
>>133
132だが、いい加減しつこいかもしれんが、どの辺がFUDなんだ？
136 ：デフォルトの名無しさん：2006/05/28(日) 23:25:08
>>135
間違えた。「132だが」は、「131だが」ね。
137 ：デフォルトの名無しさん：2006/05/29(月) 00:35:52
>>132
確かにポイントがずれてたかもしれん。
でも、結局、

> 「そんな機能いらね」といってたくせにそれが実装されると意見を180度変えるJava屋さんが多すぎて

というのは、そんなに居るかなあとしか自分は思えない。あなたの
周りはそういう人ばっかりだったのかもしれんが、全体として
どうだったかというのは、ソースが無い以上、わからんし。
138 ：デフォルトの名無しさん：2006/05/29(月) 08:50:44
えーい、IDが無い板でそういう話題はやめーい。
技術の話でぶつかるならともかく！！！！
139 ：デフォルトの名無しさん：2006/05/29(月) 08:59:23
まあ、ヒアドキュメントは実装されても意見を180度変えるJava屋は少ないだろうな。
いらね。
140 ：デフォルトの名無しさん：2006/05/29(月) 09:10:29
XMLで出来るんだから、プレインテキストはいらんだろ。
141 ：デフォルトの名無しさん：2006/05/29(月) 12:41:52
>>134
JSR 245のexpression languageのところだけ、
つまり JSR-000245 JavaServer Pages 2.1 FR から抜き出された
JavaServer Pages 2.1 Expression Language Specification
だけ入るんじゃないのかな。property関係のところは。

1.6 Operator [] and .

The EL follows ECMAScript in unifying the treatment of the . and [] opeartors.

expr-a.idenfitifer-b is equivalent to expr-a["identifier-b"]; this is, the
indentifier identifier-b is used to construct a literal whose value is
the identififer, and then [] operator is used with that value.

(以下、式を評価する時のルール;略)

java.elのELResolver.getValue()辺りのインターフェースは
どうなるのか知らないが。もともとJSPのproperty用だからさ。

142 ：デフォルトの名無しさん：2006/05/29(月) 16:53:15
>>137
まさに、すぐ下にいるじゃん。>>139,140
今まで幾度となく同じことが繰り返されてきたし、これからもおんなじ。
143 ：デフォルトの名無しさん：2006/05/29(月) 16:58:39
つまり、>>43 がXMLリテラルがあればヒアドキュメントいらね、って言い出すと予言してるわけね。
144 ：デフォルトの名無しさん：2006/05/29(月) 17:34:37
ヒアドキュメントはもう話題としてはいいだろ。つまんねえし。
145 ：デフォルトの名無しさん：2006/05/29(月) 17:49:01
>>142
ヒアドキュメントなど、間違いなく不要。
146 ：デフォルトの名無しさん：2006/05/29(月) 23:48:08
あってもなくてもどうでもいいや。
自分ならヒアドキュメントで書きたくなるような文字列はコードと分離するけど。
147 ：デフォルトの名無しさん：2006/05/30(火) 01:46:32
まあつまりさ、genericsにせよヒアドキュメントにせよ、あれば使うし無ければ
今を受け入れるか、Javaを使わないしかないだろ。

おれはヘタレなのでMapに想定していないオブジェクトをつっこんじゃって、
キャストで落ちるなんてことをよくやってたからGenericsはすごくありがたい
けど、なけりゃないで、無いんだからどうしようもないから受け入れてただけ。
Genericsがないからまともなコードが書けません、なんて仕事では言えない
んだし。
148 ：デフォルトの名無しさん：2006/05/30(火) 02:42:09
いや、ヒアドキュメントは、あっても使う機会がない。
149 ：デフォルトの名無しさん：2006/05/30(火) 05:26:34
Ruby並にいろいろできるなら欲しいな、便利だし
150 ：デフォルトの名無しさん：2006/05/30(火) 06:57:54
スクリプト言語と比較されてもなあ…
ま、俺も>>146と同じでどっちでもいいや。どうせ使わないだけだし。
151 ：デフォルトの名無しさん：2006/05/30(火) 09:27:59
つうか、Ruby並にいろいろやりたいならJRuby使えばいいだけじゃん。
152 ：デフォルトの名無しさん：2006/05/30(火) 09:31:37
時々でいいのでGroovyのことも思い出してあげてください。。。
153 ：デフォルトの名無しさん：2006/05/30(火) 09:32:36
あ、Groovyってヒアドキュメントなかったかも....orz
154 ：デフォルトの名無しさん：2006/05/30(火) 09:34:55
>>147
List<Map<String,Object>>とかだとListとだけかかれるとソース追わないと中身確認できないのはきつい
ドキュメントでしっかり書いてくれるところならいいがListとだけかいているとぶち殺したくなる

もう1.4時代にはもどれんよな
155 ：デフォルトの名無しさん：2006/05/30(火) 09:48:47
>>153
Groovyには、式を埋め込める複数行文字列リテラルがあるよ
こんな感じ

def i = 100
println """
Hello ${i}
"""

これをヒアドキュメントと言っていいかは正直わからんの
だが、機能的には、文字列の終端となる記号を自由に指定
できないことを除いて、ほぼ同等だと思う
156 ：デフォルトの名無しさん：2006/05/30(火) 15:45:10
ヒアドキュメントは*絶対*に入れて欲しくない
こんなもの、保守やデバグを考えるとぞっとする
チームで禁止しても絶対使う奴が出てくるから嫌だ
157 ：デフォルトの名無しさん：2006/05/30(火) 16:54:31
どうせコンパイルして逆コンパイルしたら普通の文字列リテラルになるから問題なし。
158 ：デフォルトの名無しさん：2006/05/30(火) 17:55:57
ヒアドキュメントいれただけで保守やデバッグができなくなる>>156のレベルに乾杯
159 ：デフォルトの名無しさん：2006/05/30(火) 18:06:25
まぁお行儀の悪いプログラムを推奨してるかんじだしあまりいいものではないな
160 ：デフォルトの名無しさん：2006/05/30(火) 20:21:24
コンパイラ機能とあわせて使うと意外と便利かもよ
てかコンパイラ機能ってクラスキャッシュ直ぐ満杯になる欠点とかないの？
161 ：デフォルトの名無しさん：2006/05/30(火) 23:03:08
>>160
そんなことされると、さらにgkbr
162 ：デフォルトの名無しさん：2006/06/02(金) 02:54:34
ヒアドキュメント入れるときの妥協点として
コンパイルオプションでヒアドキュ封じができるようになればちょうどいい感じで導入できないかね？
プロジェクトで使う人もこまんないんじゃない？
163 ：デフォルトの名無しさん：2006/06/02(金) 07:44:25
そういう問題じゃない。
というかそこまでして導入するもんでもない。
164 ：デフォルトの名無しさん：2006/06/02(金) 17:03:39
プロパティは、
言語として加わるのか、
XML対応としてXMLの属性にgetValue/setValueするAPIがJDKに加わるのかどっち?

関連JSRは、
JSR 227: A Standard Data Binding & Data Access Facility for J2EE(TM)
JSR 245: JavaServer(TM) Pages 2.1
JSR 252: JavaServer Faces 1.2
JSR 295: Beans Binding
あたり? Expression Language周辺


165 ：デフォルトの名無しさん：2006/06/03(土) 22:35:13
>>40
なんだからPerlの q!文字列!やPHPの'文字列\n$変数'と'文字列$変数'との
違いを表してるブツみたいだな。
PHP的なものならまだしもPerlのq!文字列!みたいな
混乱するブツになるのは避けてもらいたいところだよな。

ダブルクォーテーションが無いだなんて、
あれ使う前に何か宣言でもするのかな
166 ：デフォルトの名無しさん：2006/06/03(土) 22:37:29
>>46-47
そのまんま@Propertyアノテーションとして使えばいいやんか
167 ：デフォルトの名無しさん：2006/06/03(土) 22:39:21
>>48
C#みたいな表向きは set/getと書くだけでプロパティが使えるが
実際には内部ではプロパティ変数名がたとえばtest のとき実際にはGet_test(), Set_test()
というメソッドが定義されているとコンパイラに解釈されるという奴でどうにかなるんだろう。

ただし、このときGet_test(), Set_test()という名前のメソッドを定義するとC#ではエラーになるが。
168 ：デフォルトの名無しさん：2006/06/04(日) 01:52:45
>>167
そういう暗黙の定義が適用されるのは、
対XMLデータとか、シリアライゼーションとか、
定義をクラスライブラリ側が持っているケースでしょ?

それは既にBeansやServer PagesのELであるよね。
JavaDocのtagもpropertyが増えてる。

Dolphinのは、言語がproperty採用するって事なんじゃないのかな?
要するに、setter/getterはプログラマが記述して、
フィールド参照がsetter/getterに置き換わるヤツ。
169 ：デフォルトの名無しさん：2006/06/04(日) 01:56:45
>>96
遅レスながら激しく同意。ほんとJavaには呆れる。
170 ：デフォルトの名無しさん：2006/06/04(日) 02:11:29
>>165
> >>40
> PHP的なものならまだしもPerlのq!文字列!みたいな
> 混乱するブツになるのは避けてもらいたいところだよな。
例えばの話だが
"<p id=\"hoge\" onmouseover=\"hige('fuga')\" class=\"hage\">";
q{<p id="hoge" onmouseover="hige('fuga')" class="hage">};
どっちが見易いかっつう話だ。
q{}とは違うが正規表現の場合も考えてみ。JavaよりC#の@の方がまだマシだろうに。
171 ：デフォルトの名無しさん：2006/06/04(日) 10:21:22
>>75
そんな書き方するのがいやだったら
インクリメントできるメソッドを定義したほうがいいんじゃないのか？
172 ：デフォルトの名無しさん：2006/06/04(日) 10:24:18
>>96
いっておくがC++のtemplateとJavaのgenericsとはまったく別もんだよ。
比較サイトでも似て非なるものであると書いてある。

よって全然手のひらを返したことにはならんよ
173 ：デフォルトの名無しさん：2006/06/04(日) 10:25:14
>>96
ヒアドキュメントは下手な奴が使うとソースコードを読みにくくするからな。
Perl厨が書いたコードみたいにな。
174 ：デフォルトの名無しさん：2006/06/04(日) 10:27:07
>>172
C++ templateの重要な特性である、コンパイル時プログラミング
ができるという機能をJava genericsは持って無いし、別物と言って
良いだろうね。
175 ：デフォルトの名無しさん：2006/06/04(日) 10:27:51
>>114
だからC++のテンプレートはJavaのGenericsと全く
同じではないと何度言ったら(ry
だからあれほど言ったものを
176 ：デフォルトの名無しさん：2006/06/04(日) 10:28:25
しかも今のJavaにも"foreach"なんてキーワード出て来ないし
177 ：デフォルトの名無しさん：2006/06/04(日) 10:30:19
>>122
>>114はGoslingが「C++Templateの機能すべてはいらない」と
言ったのを勝手に「Genericsはいらない」と誤認しているだけなんだよ。
恥ずかしい奴だから

178 ：デフォルトの名無しさん：2006/06/04(日) 10:32:21
for (型 変数名 : コレクション) 文

いらねーよ、こんなの。
179 ：デフォルトの名無しさん：2006/06/04(日) 10:34:18
>>139
ま、Perlそっくりそのままのヒアドキュメントが実装されたら
あれだな。

XMLのCDATAセクションみたいなのがJavaソースコードに紛れるのかね

だとしたらJavaソースコードがまるっきりXML文書の一部になる？
180 ：デフォルトの名無しさん：2006/06/04(日) 10:38:02
>>178
お前らがforeachが無いんですけど(^^;;とか騒ぐから
181 ：デフォルトの名無しさん：2006/06/04(日) 10:38:10
>>178
便利だよ
182 ：デフォルトの名無しさん：2006/06/04(日) 10:38:44
>>170
そんなことをするんだったら別ファイルに書くか
JSPやカスタムタブライブラリやJSFやApache Struts
やJakarta Velocityを使うがな
183 ：デフォルトの名無しさん：2006/06/04(日) 10:40:42
>>174
もっと決定的な違いがあるよ。
C++厨がJava Genericsではこれができないと
愚痴を零している数々の機能。

多重継承ができないからといってブツブツ文句をいうＣ++厨が
いるようにJava GenericsがC++Templateとはあまりにも
違うことに文句をつけている変な奴がまだまだいるのさ
184 ：デフォルトの名無しさん：2006/06/04(日) 10:48:11
>>182
JSFやApache Strutsはヒアドッキュメントの代替にならない件
185 ：デフォルトの名無しさん：2006/06/04(日) 10:48:59
昔、ほんとにいらないのか、パクリを認めたくないのか
「いらねーよ、こんなの。」と言ってたものが
今までも、そしてこれからも追加されていくわけやね。
186 ：デフォルトの名無しさん：2006/06/04(日) 10:55:38
まあ、ヒアドキュメントが追加されることはないから心配するな。
187 ：デフォルトの名無しさん：2006/06/04(日) 10:55:58
そら便利ならそうなるわな。しないほうが馬鹿と言われる。
188 ：デフォルトの名無しさん：2006/06/04(日) 10:59:16
プロパティに関してはみんな欲しいと言ってたわけだしね。
XMLリテラルはいらねーともいるとも言ってない晴天の霹靂
189 ：デフォルトの名無しさん：2006/06/04(日) 11:00:13
J2EE方面の人の声が大きくなってきているね。
190 ：デフォルトの名無しさん：2006/06/04(日) 11:01:03
>>183
> Java GenericsがC++Templateとはあまりにも違うことに文句をつけている変な奴

ただ、Java Genericsは、Java仮想マシンの互換性を保つために、いろいろと
面倒な仕様になっているので、文句を付けられても仕方無いと思える部分もある。
特にC#のGenericsと比べると、その部分が際立つ。
191 ：デフォルトの名無しさん：2006/06/04(日) 11:01:35
金をだすのはエンタープライズ方面
192 ：デフォルトの名無しさん：2006/06/04(日) 11:05:46
いいかげんジョイスティックPureＪａｖａでさぽーとしてくれねぇかなぁ
デスクトップに目を向けています！なんてよくいえたものだ＞5.0
1.4のほうがクライアントサイドで大幅によくなってたが、5.0ほとんどかわってねーし
6もほとんどかわってねーな

グループレイアウトが標準になるくらいか
193 ：デフォルトの名無しさん：2006/06/04(日) 11:06:46
ところでなんでこの時間だけいきなりレスふえたんだ？
しかも亀が多い
194 ：デフォルトの名無しさん：2006/06/04(日) 12:02:18
>>178
けっこうスッキリするけどね
195 ：デフォルトの名無しさん：2006/06/04(日) 12:03:07
>>193
日曜だけ見る奴とかいるんでね？
196 ：デフォルトの名無しさん：2006/06/04(日) 12:03:54
>>180
foreachはないけどfor(;;)やfor(;)はあるってことで
GenericsはあるけどC++Template相当のものはすべては無いってことで


「否定していた癖にJavaにforeachやGenericsが出た」と主張した奴は
馬鹿って事で

197 ：デフォルトの名無しさん：2006/06/04(日) 12:04:55
>>194
で、処理中にインデックスがいると分かり、for (int i = 0; i <
に書き直したり。これがアホくさい。言語レベルで今何番目か
分かるようにしてほしい。
198 ：デフォルトの名無しさん：2006/06/04(日) 12:05:48
>>184
それでも今Perl臭いヒアドキュメントの必要性は
感じないな。
JSFやStrutsがヒアドキュメント代わりになるというより、
>>170のようなHTMLコードをいちいちJavaコードの中に
埋め込むというくだらないことをしなくて済むという観点から
>>184の主張が現れている。
199 ：デフォルトの名無しさん：2006/06/04(日) 12:08:02
>>185
追加されるっていっても過去の言語にあるものとは
違うモノだから。
enumだってそうだし。
C/C++のenumはJavaのenumとは似て非なるものであって
Genericsが登場したからこそ実現できたものであって
C/C++のenumとくらべたら断然機能的で優れている。
よってC/C++のenumとJavaのenumとはまったく別のものである。
だから、かつてJavaにeumがいらないという発言があったのは
「Javaの新しいenumが要らない」というのではなく
「C/C++で実装されている仕様のenumが要らない」ということだったのだ。


200 ：デフォルトの名無しさん：2006/06/04(日) 12:08:33
>>188
みんなって誰？
あれの需要はそんなにあるとは思えないな
201 ：デフォルトの名無しさん：2006/06/04(日) 12:09:54
>>192
ハードウェア方面にまでPureJavaをサポートするのは
まだまだ先だろ。
JiniやらJava Communication API をどうにかしないと
202 ：デフォルトの名無しさん：2006/06/04(日) 12:10:26
>>195
それはありうる。

>>193 >>195
というか偶然ともいえるだろう。
203 ：デフォルトの名無しさん：2006/06/04(日) 12:11:43
>>197
それはIteratorの意味が無いとちゃうか？
何番目を知りたいかだなんて使い方が間違ってると思うぞ。
アルゴリズムや作りたいものによるが、
コレクションの分割とか考えるといいかと

204 ：デフォルトの名無しさん：2006/06/04(日) 12:17:10
そもそもコレクションの機能にランダムアクセスなんてないだろ
interface RandomAccessとinterface Collectionは別の機能だ
205 ：デフォルトの名無しさん：2006/06/04(日) 12:18:04
>>203
間違ってるか？ というか、拡張 for 使いまくった？
えーと、そうだ、おまい今まで組んだものはループは全部 Iterator か？

例えば、画面に行No出力する場合はどうする？
JSTL とかテンプレート言語が無い場合ね。
206 ：デフォルトの名無しさん：2006/06/04(日) 12:20:21
>>197
俺もインデックスが必要になるのがあとで必要になって書き直したりするよ
でも、イテレータパターンであることを言語的に保証するものだからありでは？
インデックスだと中身まで見ないと流れが把握できない

>>201
キーボードやマウスと同じ一般的な入力インターフェースなんだが
ついでにMSXのようにキーボードもジョイスティック0番とかでつかえるようにしておけば
コードを分ける必要もなくていいのだが

同人ソフトとかでJava製の物がほとんどない原因のひとつでは？
フルスクリーン等は1.4でサポート、じゃヴぁSoundは1.3でサポートされやっと使い物になってきたが
インターフェースがないのではね

1.1時代＋JNIでなんでもできるということはなかったはずだし
JNIも万能ではない（スタックサイズ制限で引っかかる）からね
VM自体のリコンパイルが必要になるし、さすがにそれは現実的ではないだろう
207 ：デフォルトの名無しさん：2006/06/04(日) 12:25:27
> 同人ソフトとかで

を例に示されてもワカラネw
分かるのが普通か？
208 ：デフォルトの名無しさん：2006/06/04(日) 12:26:28
「デスクトップ分野にも力を入れています」は口だけ
209 ：デフォルトの名無しさん：2006/06/04(日) 12:28:51
そんな大した手間じゃないと思うけどな＜パッド・スティック対応
PadListenerみたいな標準インタフェース用意して、メーカー側が対応するSPIをサイトに置いとけばいいじゃん
210 ：デフォルトの名無しさん：2006/06/04(日) 12:33:21
>>203
> 何番目を知りたいかだなんて使い方が間違ってると思うぞ。

それは言い過ぎだろw

けどループ構造は代えずにカウンタ一つ用意すればいいだけだよな。
211 ：デフォルトの名無しさん：2006/06/04(日) 12:34:44
>>209
http://sourceforge.net/projects/javajoystick/ にあるが、
標準でサポートしろって事でしょ。
けどジョイスティックはそもそもインターフェースが統一されているとは言いがたいし…
212 ：デフォルトの名無しさん：2006/06/04(日) 12:38:53
>>210
カウンタを用意するとループのスコープの外に変数を作ることになる。
なんかいや。
213 ：デフォルトの名無しさん：2006/06/04(日) 12:43:47
カウンタ用意したらイテレータパターンの意味ないだろ
何番目か意識することなく取り出すのが目的なんだから

カウンタ使いたければふつうにfor( ; ; )すればいいだけ

>>211
2軸32ボタンまではOSレベルで標準サポートされてるはずだ
214 ：デフォルトの名無しさん：2006/06/04(日) 12:46:49
だから、Iterator パターンでも、必要であれば、カウンタが
とれればいい。freemarker のように。
215 ：デフォルトの名無しさん：2006/06/04(日) 12:50:12
Iteratorのコード書くよりは拡張forの方がはるかに楽な件
Iteratorのコードの場合、カウンターが必要なら拡張for使わなくてもIteratorかカウンタ変数かどちらかがスコープの外に出る件
216 ：デフォルトの名無しさん：2006/06/04(日) 12:54:04
ジョイスティックが「デスクトップがんばる」の範囲に入ってなくてもほとんどの人が困らない件
217 ：デフォルトの名無しさん：2006/06/04(日) 13:01:36
>>215
ここで言ってるIteratorは拡張Forのことだという件
218 ：デフォルトの名無しさん：2006/06/04(日) 13:07:26
>>213
>>204の言っている意味も理解できないのかよ。
219 ：デフォルトの名無しさん：2006/06/04(日) 13:13:25
>>206
> >>201
> キーボードやマウスと同じ一般的な入力インターフェースなんだが
> ついでにMSXのようにキーボードもジョイスティック0番とかでつかえるようにしておけば
> コードを分ける必要もなくていいのだが

Adapterパターンでうまいことラッパークラス作れよw
220 ：デフォルトの名無しさん：2006/06/04(日) 14:12:33
>>216
ほとんど外の人がデスクトップ普及熱の根幹である件
221 ：デフォルトの名無しさん：2006/06/04(日) 14:22:25
>>219
みんなラッパつくってるだろ
それが面倒だということだろ
222 ：デフォルトの名無しさん：2006/06/04(日) 14:24:39
というかJ2SE5.0でデスクトップ改良部分ってなんかあったっけ？
1.4は明らかに今後がんばるんだなぁという光が見えたわけだが
223 ：デフォルトの名無しさん：2006/06/04(日) 14:39:46
ラッパならどこかでダウソできたような気がする
224 ：デフォルトの名無しさん：2006/06/04(日) 14:41:34
5.0は思いつかない。
6はピュアGUIやスクリプトなど一応の発展はある。
225 ：デフォルトの名無しさん：2006/06/04(日) 16:28:04
Google Web Toolkitのような使われ方も次世代Javaか？
226 ：デフォルトの名無しさん：2006/06/04(日) 17:26:49
>>222
みんなOceanに腰を抜かしたはず
あのセンスに。
たぶん、アレで識者は「これは俺が何とかせねば」と奮起したと思われる。

インデックスが必要ということはカウンターが必要であるということで
コレクションを操作するという事とは別の要素が必要になったということ
繰り返し処理と、カウンタを使うという意味を切り分ける意味で
俺は別にカウンタを用意している。

カウンタも０からスタートさせたい場合や、1からスタートさせたい場合など色々。
もし、繰り返し処理で使うなら、拡張機能をさらに入れたい。それで
・カウンタの初期値
・カウンタのステップ
を決めたいのだが、そうなるとforeachタイプforにさらなる
文法拡張が必要になるなぁ。
for( Object i : list : 0 : 2 ){
}
あ、イテレーションのコンテキストにアクセスするのに文法も必要か・・・
コレは一筋縄じゃいかんねぇ
227 ：デフォルトの名無しさん：2006/06/04(日) 18:13:09
>>226
それだよ、それ。そういう拡張が欲しい。
スコープもループ内だしな。
228 ：デフォルトの名無しさん：2006/06/04(日) 18:29:05
>>226
もういっそのこと、Schemeのようなマクロを導入して、
そういう拡張は自分で定義してね、とするとか
まあ実際にはあり得ないだろうけど
229 ：デフォルトの名無しさん：2006/06/04(日) 19:02:34
>>228
そういうのを要求する人はjavaの拡張を待つまでもなく、もうm4とかの
マクロプロセッサを使ってるんじゃないのかね。
230 ：デフォルトの名無しさん：2006/06/04(日) 19:07:58
Java のスレの中では初心者質問スレを除き、このスレが一番伸びている件について。
231 ：デフォルトの名無しさん：2006/06/04(日) 19:12:50
>>226
別に、普通に0ベースか1ベースのインデックスさえ手に入れば、
n + m * indexで、nまたはn+mからスタートしてステップmの
カウンタが手に入るじゃないの。

>>228
この程度ならマクロなんて必要なくて、レキシカルクロージャが
導入されていれば、簡単につくれるんだよねえ。
232 ：デフォルトの名無しさん：2006/06/04(日) 19:38:56
JavaSE6も近いからな

関係ないか
233 ：デフォルトの名無しさん：2006/06/04(日) 19:47:44
中途半端な知識で参加できるからだと思われ
234 ：デフォルトの名無しさん：2006/06/04(日) 20:25:07
>>226
いらねー
くだらねー
235 ：デフォルトの名無しさん：2006/06/04(日) 20:39:03
Jakarta Velocityの変数$velocityCountみたいなのがあれば
いいんでね？
236 ：デフォルトの名無しさん：2006/06/04(日) 21:23:13
いらん
237 ：デフォルトの名無しさん：2006/06/04(日) 21:30:28
普通はいらんね
238 ：デフォルトの名無しさん：2006/06/04(日) 21:53:15
>>231
レキシカルクロージャがあれば、その程度なら簡単にできる
というのはその通りだが、クロージャだけでは簡単にできない
拡張もある。で、諸々の拡張に対する提案全部を取り入れてたら
きりが無いので、マクロを定義する仕組みだけ用意して、あとは
ユーザが勝手にマクロを作ってねとしたらどうか？というのが228
で言いたかったこと。まあ、マクロは濫用される危険性が大きい
機能でもあるので、Javaのような言語に実際に入ることは無いだろうけど。
239 ：デフォルトの名無しさん：2006/06/04(日) 21:53:18
Freemarker の変数 $〜_index みたいなのがあれば
いいんでね？
240 ：デフォルトの名無しさん：2006/06/04(日) 21:56:02
イラネーよ、そんな糞機能
241 ：デフォルトの名無しさん：2006/06/04(日) 22:16:57
ロードまぷ
http://roumen.name/work/Poland06/Roman_Strobl_JavaSE_6_7_Roadmap.pdf
242 ：デフォルトの名無しさん：2006/06/04(日) 22:32:28
SPECJBB2000なんて字樹上にそぐわないベンチ使ってるのが怪しい
2005なんでつかわないのだ

1.2.2でノーマライズとかいてるのもあやしい
1.3.1とかなり違うはずなのだが
243 ：デフォルトの名無しさん：2006/06/04(日) 23:40:00
>>213
>カウンタ用意したらイテレータパターンの意味ないだろ
>何番目か意識することなく取り出すのが目的なんだから
>
>カウンタ使いたければふつうにfor( ; ; )すればいいだけ

これはちがうだろ。Iteratorは、データ構造に依存せずに繰り返しのためのインターフェースを提供することが目的。
Iteratorが考えだされるまでは、ListやArrayやTreeといったデータ構造ごとに、繰り返しの操作が異なっていたし、それが当たり前だった。
それがIteratorによって、どれでも同じインターフェースで繰り返しが行えるようになった。
Iteratorの目的は「繰り返し」の抽象化であり、そのこととカウンタとはぜんぜん別の問題。
ListやTreeに対してはIteratorとカウンタの両方を使うべきであり、for(int i=0; i<count; i++)とかするのはバカ。
244 ：デフォルトの名無しさん：2006/06/04(日) 23:43:40
>>243
カウンタ用変数を外側に用意すれば?
もちろん｛　｝で一段スタック入れてスコープ狭める
245 ：デフォルトの名無しさん：2006/06/04(日) 23:51:24
>>243
Iterator 大好きなんだな。
別にそこまで無理してデザパタ使わなくてもいいよw
246 ：デフォルトの名無しさん：2006/06/05(月) 00:10:39
ArrayListから配列取り出して
//こっちのほうがわかりやすいから
とコメントしてforで回してるソースを見たときは声出してﾜﾛﾀ
247 ：デフォルトの名無しさん：2006/06/05(月) 00:15:45
>>245は馬鹿だね
248 ：デフォルトの名無しさん：2006/06/05(月) 00:21:12
デザパタ厨的には、IndexableIteratorというデコレータを作るのかな。
249 ：デフォルトの名無しさん：2006/06/05(月) 00:35:13
Iterator パターンは内部を意識することなく順次取出しするのが目的であって
何番目とかの処理を意識させるのは必要ないからな

あなたは何番目ですか？がロジックで必要なら自前で用意するだけ

今までのfor構文でイテレータ使ってたのと同じでこれはかわってないだろ
250 ：デフォルトの名無しさん：2006/06/05(月) 00:38:23
>>245
必死だな
251 ：デフォルトの名無しさん：2006/06/05(月) 02:01:46
>245
ﾜﾛｼｭ
252 ：デフォルトの名無しさん：2006/06/05(月) 02:39:44
>>248
似たようなもんがJakarta Commons Collectionsになかったか？
253 ：デフォルトの名無しさん：2006/06/05(月) 02:52:50
Map用のfor文が欲しい
for(String key,String value : map) { 文 }
みたいな
254 ：デフォルトの名無しさん：2006/06/05(月) 03:02:43
Entryでいいじゃん
for(Map.Entry entry : map.entrySet() )
255 ：デフォルトの名無しさん：2006/06/05(月) 09:42:15
Iterator → デザインパターンってヤツは誤解しているぞ。
IteratorはCLUで70年代からある。
256 ：デフォルトの名無しさん：2006/06/05(月) 11:46:58
>>253
MapをIteratorに変換するか

MapとListが一緒になった、Jakarta Commons Collectionsにある
あのクラスを使えば医院ジャマイカ？
257 ：デフォルトの名無しさん：2006/06/05(月) 11:47:34
>>255
GoFの一つにIteratorパターンがあるからね。
デザインパターンとしてのIteratorは後から出たモノだとおもう
258 ：デフォルトの名無しさん：2006/06/05(月) 11:51:11
>>254
それだと、Entryからkeyとvalueを取り出さなきゃいけないじゃん。
253だとその手間が省ける。それが大事。
259 ：デフォルトの名無しさん：2006/06/05(月) 12:04:53
そこまで大事か？
260 ：デフォルトの名無しさん：2006/06/05(月) 12:40:00
>>259
まあ、あれば便利かもしれんが、そこまで重要な機能ではないわな。
foreachに比べると、使う機会も少ないだろうし。
261 ：デフォルトの名無しさん：2006/06/05(月) 19:25:26
つうか、>>253くらいのことは簡単に実装できるんだから、拡張for文を導入するときに
いっしょに導入してくれればよかったんだよ。
そのくらい、ふつうに気がつくだろ。なんで直接Mapが使えないように限定するのかさっぱりわからん。
262 ：デフォルトの名無しさん：2006/06/05(月) 19:40:33
>>261
そんなこと言ってると
あれも入れろこれも入れろで収拾付かなくなるから。
263 ：デフォルトの名無しさん：2006/06/05(月) 19:49:14
Entry回せばいいじゃん、極一部のクラスのためだけにそんな馬鹿な仕様取り入れるかよ
Collectionはデータ構造に関するJavaの主要フレームワークの根元だから特別視されるだけだ
264 ：デフォルトの名無しさん：2006/06/05(月) 20:08:49
try-open-finally-closeも特別扱いしてほしい。
265 ：デフォルトの名無しさん：2006/06/05(月) 20:13:57
try-finallyデストラクタを強制するためにも
openとcloseは例外を投げる設計にしたほうがいいんだよな

>>264
どんな感じの？
266 ：デフォルトの名無しさん：2006/06/05(月) 20:40:25
>>262
そのくせプロパティやらXML直書きやらは導入されるんだ。
そっちのほうが収拾つかんわ。
267 ：デフォルトの名無しさん：2006/06/05(月) 20:44:59
>>266
Map の foreach なんて generics+プロパティ導入で e.key と e.value で済むんだから
わざわざ入れなくてもいいだろ。
268 ：デフォルトの名無しさん：2006/06/05(月) 22:08:03
クロージャが出来るそうだから、

foreach(aMap, クロージャ);

でいいよ。
269 ：デフォルトの名無しさん：2006/06/06(火) 01:47:50
クロージャは導入必至。

オヤジJavaプログラマの「クロージャは苦労じゃ」のネタは既に
あるものとして色々なバリエーションが考えられてるからです。
どんなものでもイイが、上のネタを生かすために簡単なものであっては困る事だけは確かだ。
270 ：デフォルトの名無しさん：2006/06/06(火) 02:25:33
クロージャの正しい概念ってどんなの？
ECMAScriptだとthis参照を遅延生成メソッド内に埋め込むやり方で使ってるよね
でもJavaのthisってコンテキスト参照じゃなくてインスタンス参照でしょ？
271 ：デフォルトの名無しさん：2006/06/06(火) 02:44:45
XMLリテラルがどういう利点があるかわからないんだけど。
272 ：デフォルトの名無しさん：2006/06/06(火) 03:11:42
>>271
構造を持ったデータを簡単に作れることじゃないの？
今までせこせこ、ＬｉｓｔとかＭａｐとか組み合わせてたような奴
273 ：デフォルトの名無しさん：2006/06/06(火) 03:28:52
アノテーションにxmlリテラルが使えると、外部xmlファイルが必要なくなるのは嬉しいか嬉しくないか微妙。
274 ：デフォルトの名無しさん：2006/06/06(火) 08:35:14
>>270
http://foldoc.org/foldoc.cgi?query=closure&action=Search
の1かな。
Javaに実装するなら、new Callable() { ... } あたりを楽に書ける
シンタックスシュガーとして実装がいいんじゃない。
つまり、ローカル変数はfinalなもののみアクセスできる。
>>36 のようなことがやりたければ、
final int[] sum = { 0 }
で切り抜ける。
275 ：デフォルトの名無しさん：2006/06/06(火) 20:11:40
使い勝手が悪そう
276 ：デフォルトの名無しさん：2006/06/07(水) 04:21:46
ヒアドキュメントすら否定するのにXMLリテラルは受け入れるJava厨乙
277 ：デフォルトの名無しさん：2006/06/07(水) 05:45:45
>>276
受け入れてないよ。だからヒアドキュメント否定するんだろ。
278 ：デフォルトの名無しさん：2006/06/07(水) 05:49:46
とか言いながら、いざ実装されるとマンセーするのがいつものパターン。
279 ：デフォルトの名無しさん：2006/06/07(水) 07:45:12
ヒアドキュメントはイラン。

ところで、クロージャーって、単なるシンタックスシュガーじゃなくて、スクリプト言語用のバイトコード拡張を利用する構文じゃないのかな。
280 ：デフォルトの名無しさん：2006/06/07(水) 11:05:11
>>279
それは激しい・・・
ヒアドキュメントと変わらんじゃないですか
スクリプト言語のシンタックスがわからない以上・・・・
281 ：デフォルトの名無しさん：2006/06/07(水) 11:13:26
>>279
それはまず無い。スクリプト言語用のバイトコード拡張(invokedynamicだったか)は、
クロージャの実装に使えるようなものじゃない。クロージャが単なる匿名クラスの
シンタックスシュガーになるんじゃないだろうというのは同意だが、クロージャは、
別にバイトコードを拡張しなくても、既存のコードの互換性を保った形で追加できるはず。
282 ：デフォルトの名無しさん：2006/06/07(水) 11:41:58
invokedynamic(JSR292)は、
そもそも動的メソッド呼び出しだけだから、
Funarg問題を解決してくれるようなもんじゃないしね。
# Hotswappingの方向で進んでいるからslot参照も付くんだろうが。> JSR292

どういう実装するかよりも、どういう仕様になるかの方が…
たぶん、inner anonymous classの参照しているlocal変数、実引数、
例外処理ハンドラ引数がfinalでなければいけないという制約が
closureの場合は外れるかどうか。

Inner anonymous classを使った実装になるのは確実でしょ?
後はsyntax sugerでしょうね。

Closure出来たら、コレクションも新しくしないとねw

283 ：デフォルトの名無しさん：2006/06/07(水) 11:45:10
>>280
三行とも意味がわからん…w

Groovyの文法は既に定義されているし
284 ：デフォルトの名無しさん：2006/06/07(水) 12:21:26
>>282
281だが、
> たぶん、inner anonymous classの参照しているlocal変数、実引数、
> 例外処理ハンドラ引数がfinalでなければいけないという制約が
> closureの場合は外れるかどうか。

外れると思うなあ。じゃなきゃ、セマンティクスとしては
今までとほとんど変わらないんだから、わざわざクロージャ
を追加するなんて言い方はしないでしょ。あと、細かいが
実引数は仮引数の間違いでは？

> Inner anonymous classを使った実装になるのは確実でしょ?
> 後はsyntax sugerでしょうね。

実装としては、Inner anonymous classを使うのに近いものに
なるだろうが、仕様としては単なるInner anonymous classの
シンタックスシュガーになるってことは無いと思う。
285 ：デフォルトの名無しさん：2006/06/07(水) 12:35:22
>>261
なにも考えずに下手に導入するとC#やC++の二の舞となるぞ。
どうしてもそういう機能が欲しければ
C++やC#で実装して貰うように頼むか自分で実装するという手もありだな
286 ：デフォルトの名無しさん：2006/06/07(水) 12:41:34
ああ、実引数の間違いね。

Closureを実装するにあたって、
JVMの仕様を変えるという話は出てきてないから、
ほとんどsyntax sugarみたいなもんなはずだけどね。
というかinner anonymous classがほとんどclosureみたいなもんだし。

finalが外れるとしても、primitive typeの扱いはどうするのか…
287 ：デフォルトの名無しさん：2006/06/07(水) 12:43:31
>>285
つーかクロージャができる今となっては>>268でいいでしょ。
拡張forは黒歴史だ。
288 ：デフォルトの名無しさん：2006/06/07(水) 12:51:02
>>286
JVMの仕様を変えないでも、「本物の」クロージャは実装できるよ。
あと、キャプチャされる変数がprimitive typeかどうかは、クロージャ
実装するにあたっては、特に関係無いはずだけど、何か問題ある？
289 ：デフォルトの名無しさん：2006/06/07(水) 13:10:14
outer classのslotは、
closureに埋め込んだouter class instansの
thisを介して参照すれば書き換え可能だけど、
引数はちょっと面倒じゃない? > primitive

Method内でclosureが使われる時、
first class closureが外に持ち運び出されれて使われる時、
複数のclosureからprimitive typeが参照される時の扱いなど。
まあコンパイラが頑張れない問題ではないけれど。
そういうprimitive typeは、
別のinner anonymous classでwrappingすればいいんだから。
290 ：デフォルトの名無しさん：2006/06/07(水) 13:38:10
ローカル変数も基本型だとスタックフレームにあるから、
オブジェクトでラップしとかないといけないよね。
外に持ち出して複数のクロージャから参照されるかもしれないから。
291 ：デフォルトの名無しさん：2006/06/07(水) 19:17:14
>>289
それは、クロージャからouter classのフィールドを参照しているか
outer scopeのローカル変数を参照するかによる違いであって、
primitive typeかどうかは関係無いのでは？クロージャから
outer scopeのローカル変数を参照可能で、かつ、クロージャから
その変数が変更可能なようにする場合、基本型かどうかに関わらず、
オブジェクトでラップする必要が生じると思うんだが。
292 ：デフォルトの名無しさん：2006/06/07(水) 19:54:33
>>283
あのースクリプト言語ってGroovyだけじゃないんですが・・・
スクリプト言語への対応って言語の定義はされてなくて、APIの定義なんですよ。
おそらくそこを勘違いされていますよね？

今あるスクリプト言語だけじゃなくて将来出てくる言語もこのAPIに沿ってライブラリを
用意すれば使えるっていうフレームワークです。
293 ：デフォルトの名無しさん：2006/06/07(水) 19:57:25
今までずっとコンパイル言語はデリゲート、スクリプトはクロージャって漠然と思ってたけど
もしかしてもっと高尚な概念だったのか？ｗ
294 ：デフォルトの名無しさん：2006/06/07(水) 20:04:53
スコープがどこにあるかで変わるような気もするが
デリゲートっていうのはクロージャーよりもっと大きな範囲を表すことばじゃないか？
295 ：デフォルトの名無しさん：2006/06/07(水) 20:05:00
>>293
別に高尚というほどのものではないが、ある言語がコンパイル言語かスクリプト言語
かどうかと(この区別の仕方も問題大有りだがそれは置いとく)、その言語がクロージャ
を持っているかどうかは全く関係が無いことは確か。あと、デリゲートってたぶんC#の
デリゲートのことを言ってると思うんだが、あれはMS用語であって、C#のあの機能に
対する用語としては全く一般的じゃない。
296 ：デフォルトの名無しさん：2006/06/07(水) 20:09:16
D言語もdelegateだろ？そのうち次世代標準になると思うが
297 ：デフォルトの名無しさん：2006/06/07(水) 20:30:15
>>296
逆に言えばC#,Dしか無いんだと思うが。しかも、時系列からして、D言語で
delegateって呼んでるのは、C#での呼称をまねたんだろう。次世代標準に
なるかは知らないけど、delegateはあまりセンスがいい機能だとは思えん。
298 ：デフォルトの名無しさん：2006/06/07(水) 21:55:27
delegateといえばそんな名のproxyを思い出すのはもうおじちゃん世代なんでしょうか・・・
299 ：デフォルトの名無しさん：2006/06/07(水) 22:47:03
>>291
outer scopeのローカル変数を参照している場合、
クロージャオブジェクトとは別のオブジェクトでさらにラップする必要があるでしょ。
複数のクロージャから共有される場合は必ず。

基本型じゃなければ、実はポインタが指しているわけだから、
複数のクロージャオブジェクトから共有するのは自然にできるけれど。
300 ：デフォルトの名無しさん：2006/06/07(水) 22:49:22
プログラミング言語で、"delegate"を最初に聞いたのは"actor"かな。
301 ：デフォルトの名無しさん：2006/06/07(水) 23:20:27
>>299
> outer scopeのローカル変数を参照している場合、
> クロージャオブジェクトとは別のオブジェクトでさらにラップする必要があるでしょ。
> 複数のクロージャから共有される場合は必ず。

これは特に異論を言ったつもりは無い。というか、クロージャのセマンティクスを
考えれば、至極当然だわな。

> 基本型じゃなければ、実はポインタが指しているわけだから、
> 複数のクロージャオブジェクトから共有するのは自然にできるけれど。

これはおかしい。クロージャから共有しているのは、ローカル変数その
ものであって、変数の値じゃないのだから、ローカル「変数」に対する
変更をクロージャ間で共有するためには、基本型じゃなくても
クロージャオブジェクトとは別のオブジェクトでラップする必要があるはず。
302 ：デフォルトの名無しさん：2006/06/08(木) 00:12:04
「これはおかしい」以降が分かりません。

ヒープに浮いているオブジェクトを共有していれば十分かと。
303 ：デフォルトの名無しさん：2006/06/08(木) 00:38:40
>>302
クロージャによって共有されるのは、参照型変数が指している先の
オブジェクトじゃなくて(もちろんオブジェクトも共有されるけど)、参照型変数
そのものなので、オブジェクトだけが共有されても変数そのものが共有されないと、
クロージャAで参照型変数aの指している先を変更した後(ここで、オブジェクトの
中身を書き換えるのではないことに注意)、別のクロージャBから同じ変数aを
参照したときに、クロージャAによって変更される前のaの参照先を指している、
というようなことになってしまう。
304 ：デフォルトの名無しさん：2006/06/08(木) 06:54:29
>>302

>>32 の
int sum = 0;
list.each(delegate(int i){
sum += i;
});
で、sum が java.lang.Integer、クロージャの中が
sum = new Integer(sum.intValue() + i);
だった場合に、オブジェクト共有じゃだめでしょ。
305 ：デフォルトの名無しさん：2006/06/08(木) 08:13:48
Javaなら「クロージャいらね、無名クラスで十分」でお願いします。
そしてクロージャが実装されたあかつきには「やはりクロージャは便利だ、すばらしい」でお願いします。
306 ：デフォルトの名無しさん：2006/06/08(木) 08:21:39
まぁ、使ってみなきゃわからない便利さってのもあるしな
307 ：デフォルトの名無しさん：2006/06/08(木) 09:15:16
>>305
さすがにクロージャに関しては、無名クラスで十分というのは
あり得ない気がする。特に無名クラスを制御構造の抽象化
(内部イテレータなど)に使うのは、冗長過ぎる。複数のメソッドを持っている
オブジェクトの場合は、無名クラスの方がいい場合もあるとは思うけど。
308 ：デフォルトの名無しさん：2006/06/08(木) 09:16:38
>>305
あいかわらず分析力のないｗｗｗ
309 ：デフォルトの名無しさん：2006/06/08(木) 12:16:34
>>308
別に分析なんてしてないんじゃない？
Java vs ○○系のスレで何度も起きていることを
そのまま書いただけでしょ。
310 ：デフォルトの名無しさん：2006/06/08(木) 13:29:23
は？　意味がわかりませんな
あんたのいってることは
311 ：デフォルトの名無しさん：2006/06/08(木) 14:37:40
分からないならレスしなくていいよ。
もうちょっと勉強してからどうぞ。
312 ：デフォルトの名無しさん：2006/06/08(木) 14:39:51
くだらん煽りだ
313 ：デフォルトの名無しさん：2006/06/08(木) 14:40:54
>>312は>>310宛
314 ：デフォルトの名無しさん：2006/06/09(金) 03:16:58
★ネタは分かりやすく★

>>305 は
Javaユーザが、Generics導入前には「いらね」と言っていたのに
導入されたら「Genericsネ申」と褒め立てるJavaユーザをクロージャにも当てはめ
シニカルな笑いにしたネタ( ´ー｀)y-~~

>>308 は
それをむしろJavaユーザの立場から自嘲的に笑いにしたネタ
もしくは、単に>>305 の諧謔を理解せず笑ったﾉ(´д｀*) レス

>>309 は
それをJavaユーザに対する真っ向非難と受け止めた
瞬間湯沸かしレスヽ(`Д´)ﾉ

>>310
もう喧嘩と聞いちゃ黙っちゃいられない江戸っ子レス
(ﾟ∀ﾟ　)三　三(　ﾟ∀ﾟ)

>>311
それに便乗した野次馬
(　´･∀･`)ﾔﾚﾔﾚｰ

そんな感じですかね。
315 ：デフォルトの名無しさん：2006/06/09(金) 08:43:32
>>314
つまり、TemplateイラネをGenericsイラネにいまだに脳内変換してるバカってことか。
だれもGenerics神とか言ってねぇし。

スマソ、>>314自体が、そういうバカを装ったネタだったか。
316 ：デフォルトの名無しさん：2006/06/09(金) 10:13:17
>>313
いやどうみても>>311宛なんだが
317 ：デフォルトの名無しさん：2006/06/09(金) 10:14:20
>>315
まさにその通りだ。
たまにこのスレにでてくる馬鹿はC#厨とかＣ言語厨とかの
類だろう
318 ：デフォルトの名無しさん：2006/06/09(金) 13:15:36
Javaに要望されていたのはC++のtemplateじゃなくて、たんにparameterized typingじゃないの？
その意味でいえば、templateもgenericsも同じようなもんだけど。

あれか、templateイラネといっていた手前、genericsが導入されて引っ込みがつかないから
「genericsはtemplateとは違う、tempalteはいらないけどgenericsはマンセー」
といっしょうけんめい言ってるだけか。
大事なのは型引数がつかえることであって、コード生成なのかただのキャストなのかは
あんまり関係ないんだけど。
319 ：デフォルトの名無しさん：2006/06/09(金) 13:25:58
>>318
だから、導入したときにgenericsって名前にしたんだろ
320 ：デフォルトの名無しさん：2006/06/09(金) 23:16:20
俺の記憶じゃ、入れる前はどんなものか決まってなくて
C++のtemplate「みたいなの」が入るってことになってて勝手にﾜｲﾜｲやってたと思い
321 ：C++厨：2006/06/09(金) 23:32:26
C++風なのは入れないというのが暗黙の合意だったと思われ

あまり型システムは詳しくないけど、
Modula-3とかOberonの流れを汲むんじゃないの?
多重継承やオペレーターオーバーロードなし。特殊化なんてもちろんない。
322 ：デフォルトの名無しさん：2006/06/09(金) 23:54:27
タイプセーフenumパターンによるenumの実装は俺からしてみれば懸命だったと思うけど
ifよりswitchだみたいな風潮がまだあるのか、余り普及して内容に思える
323 ：デフォルトの名無しさん：2006/06/10(土) 00:05:13
タイプセーフenumの実現も可変長引数の実現も拡張forの実現も
みなGenericsのお陰で可能になったことなんだよ。
Genericsを導入するまでこれら三つを導入するわけにはいかなかった。
324 ：デフォルトの名無しさん：2006/06/10(土) 00:06:11
>>322
どういうこと？
enumはswitchでかけるし
325 ：デフォルトの名無しさん：2006/06/10(土) 03:17:28
次世代Javaスレなのに5.0で導入された機能の話ばっかりでつまらんので、
投下してみる。

JavaにContinuation（継続）機構は必要か？
http://blogs.sun.com/roller/page/gbracha?entry=will_continuations_continue

俺はあんまり良く知らないんだけど、SchemeとかRubyにはContinuationという
機能がある。これは言うなれば、メソッドを呼び出す時に「おまえ、自分の処理
が終わったらこれを呼べよな」とクロージャを渡してしまう感じだろうか。

もちろんクロージャは（ちょっと前に話題に出てたけど）その時のスタック状態
さえも保持してるので（スコープから外れても、クロージャ内ではまだローカル
変数にアクセスできる、とか）、一種のlongjumpとして働くってことですな。
（というか、そこまでしか分からんかった....）

リターン値を見てから処理を決めて....という処理が不要になって、プログラムは
シーケンシャルにどんどん突き進めるという利点と、呼び出し元じゃなくても一気に
復帰できる上に、その時のスタック状態まで復元してしまうという、いわば「スタック
フレームごとあとで使うから保存しちゃえ」という強力な機能なんだってな。

なんだかContinuation-based Web Serverとかいうものもあるらしい。

で、この機能がJVM（JavaじゃなくてJVMだよ）に必要かどうかという議論。
リンク先ブログの人は、「ウェブアプリはAJAXとかで遷移の少ない方向へ移って
いってる過渡期で、移行が完了したらContinuation-based Web Serverの利点は
過渡期の遺物になっちゃう可能性があるし、JVMの大改造が必要だしセキュリティ
モデルに影響を与えるからイラネ」といってる模様。

いろんなサイト見て、Continuationは便利そうだが、正直分かりにくいし使いどころ
が難しい気がするので、俺もｲﾗﾈ、という感じだな。
326 ：デフォルトの名無しさん：2006/06/10(土) 03:43:38
JVMみたいなスタックマシンには継続は辛い。
欲しい新機能は、switchの代替になるようなパターンマッチング。
ラベルにGOTOするんじゃなく、値を返す奴がいい。
int result = match<Integer>(obj) {
　A : execute(); return 0;
　B : return -1;
　default : return 1;
}
って感じの。
327 ：デフォルトの名無しさん：2006/06/10(土) 06:24:44
>>325
細かいところだけど、ちょっとツッコミをば。

> これは言うなれば、メソッドを呼び出す時に「おまえ、自分の処理
> が終わったらこれを呼べよな」とクロージャを渡してしまう感じだろうか。

これは、継続渡しスタイル(Continuation Passing Style)と呼ばれるテクニックで、SchemeとかのContinuation
とは違う。SchemeとかRubyにある継続ってのは、call/ccと呼ばれるもので、1引数の関数を引数としてcall/cc
を呼び出してあげると、その関数を「call/ccの呼び出しが終わった地点に制御を移動するような関数」を
引数として呼び出してくれるという感じ。Javaっぽい文法で書くと、大体下のような感じになる。
このプログラムっぽいものを実行すると、ABCBCと表示される。

Continuation process() {
　Continuation result = null;
　System.out.print("A");
　call_cc(new Function(){
　　public void call(Continuation c){
　　　result = c;
　　}
　});
　System.out.print("B");
　System.out.print("C");
　return result;
}
...
first = true;
Continuation c = process();
if(first){
first = false;
c.jump();
}
System.out.println();
328 ：デフォルトの名無しさん：2006/06/10(土) 10:34:32
その前にproper tail call optimization可能なVMかな。
329 ：デフォルトの名無しさん：2006/06/10(土) 10:57:52
>>324
コンパイラがifに展開するんだとさ
int&switchによる高速さはenum&switchにはない
330 ：デフォルトの名無しさん：2006/06/10(土) 11:15:29
>>329
Enum.ordinal() 使ってint型にして switch するだけなんだけど。

この話も Mustang にも Dolphin にも関係ないね。
331 ：デフォルトの名無しさん：2006/06/10(土) 11:17:43
ん？実装が変わったのか？
332 ：デフォルトの名無しさん：2006/06/10(土) 11:29:36
>>329
>>330
俺もifに展開してると思ってた(というか、記憶が正しければ、
1.5のαかβではほんとにifに展開してたはず)のだが、今の実装は
確かにswitchを使うみたいだね。下のコードをコンパイルして、
逆アセンブルしてみたら、確かにEnum.ordinal()を使ってswitchする
コードに展開されてた。

public class TestEnum {
　enum AnEnum {A, B, C}
　public static void main(String[] args){
　　AnEnum a = AnEnum.A;
　　switch(a){
　　　case A: System.out.println("A"); break;
　　　case B: System.out.println("B"); break;
　　　case C: System.out.println("C"); break;
　　}
　}
}
333 ：デフォルトの名無しさん：2006/06/10(土) 18:15:07
>>332
実際にどう実行されるかは JVM 側のオプションでも変わって来るんじゃなかったっけ?
334 ：デフォルトの名無しさん：2006/06/10(土) 18:43:02
>>323
>タイプセーフenumの実現も可変長引数の実現も拡張forの実現も
>みなGenericsのお陰で可能になったことなんだよ。

なんで？
for (String str: list) {
　...
}
を
for (Iterator $it = list.iterator(); $it.hasNext(); ) {
　String str = (String)$it.next();
　...
}
に展開するだけだと思うんだけど、Generics関係なくね？
335 ：デフォルトの名無しさん：2006/06/10(土) 18:59:16
>>324
おまえはtype safeという意味がわからんのか？
336 ：デフォルトの名無しさん：2006/06/10(土) 18:59:49
>>320
おれの記憶だとparameterised typingが希望されてて、その例としてC++のテンプレートが挙げられていた。
C++のテンプレートそのままが欲しいやつっていたのかな。欲しかったのはあくまで型引数がつかえることじゃない？
でも昔はGenericsとかGeneric Programmingという言葉はあまり浸透してなかったから、
話としては「テンプレートみたいなのが欲しい」という表現がよく使われていた。
つまりC++のテンプレートが欲しいんじゃなくて、型引数が欲しかったということ。
だから
>>172
>いっておくがC++のtemplateとJavaのgenericsとはまったく別もんだよ。
のようなのには、なんというか話がずれてるように思える。
どっちもparameterized typingなんだからおんなじじゃん？実現方法を問題にしてるんじゃないんだよ。
C++のtemplateは否定してJavaのgenericsは肯定してるやつらって。
まあいつものことか。
337 ：デフォルトの名無しさん：2006/06/10(土) 19:12:04
>>336
templateを否定してgenericsを肯定してるやつらは
template固有の話を問題にしているんだから、
>>336と話が合うはずがないよ。

とｵﾓﾀ。
338 ：デフォルトの名無しさん：2006/06/10(土) 19:15:50
>>336
実現方法を問題にしてたんだよ。
339 ：デフォルトの名無しさん：2006/06/10(土) 19:18:29
6.0って構文に関するなんかって変わるっけ？
5.0と7の間にあるバージョンだから、印象が薄すぎて・・・
340 ：デフォルトの名無しさん：2006/06/10(土) 19:23:50
5と7の間だとなぜ薄いのかよく分からない
341 ：デフォルトの名無しさん：2006/06/10(土) 19:33:15
そらおまえ、GenericsだのXMLリテラルだのキモイ仕様てんこもりじゃないか
342 ：デフォルトの名無しさん：2006/06/10(土) 19:37:36
>>335
流れおかしくないか？
343 ：デフォルトの名無しさん：2006/06/10(土) 19:44:29
>>340
5と7は変更が大きいからね。
6はもともと5.1になる予定だったわけだし。
344 ：デフォルトの名無しさん：2006/06/10(土) 19:55:18
5.0は言語仕様の変更は大きいけどAPI的に1.4とくらべてたいした進化はない
せいぜいコンカレントまわりくらい

６は結構大きい変更が多いので楽しみ
中でもSwingの大規模修正はびっくりなくらいでは？
345 ：デフォルトの名無しさん：2006/06/10(土) 19:57:32
あのバタ臭い見た目は何とかして欲しいけどな。
346 ：デフォルトの名無しさん：2006/06/10(土) 20:22:20
デフォルトのLAFはSystemLAFでいいようなきがするな
347 ：デフォルトの名無しさん：2006/06/10(土) 20:22:49
お前はバタ子さんに恨みでもあるのか
348 ：デフォルトの名無しさん：2006/06/10(土) 23:06:59
>>344
Swingの大規模修正ってどんなの？
あんまり詳しくないので純粋に聞いてみる。
最近Swingに興味を持ったもので....
349 ：デフォルトの名無しさん：2006/06/10(土) 23:50:35
>>334,335
foreachに関してはともかくtype safe enumは
Genericsのおかげで「簡単になった」。

タイプセーフの実装は、自分で色々書けば出来たよ。
Effective Javaとか読んでみないか？
350 ：デフォルトの名無しさん：2006/06/10(土) 23:53:57
>>348
えーっと、漏れは>>344じゃなくて何が大きいか何とも言えないが、
個人的に助かってるのは
・GroupLayoutの搭載
・WindowsLAFの改善
・サブピクセルAAレンダリング
あたりかな？中では最適化がかなりゴロゴリありそうだけどよくしらない。
351 ：デフォルトの名無しさん：2006/06/11(日) 00:05:12
>>349
type safe enumを定義するのに、Genericsはほとんど使わないわけだが・・・。
352 ：デフォルトの名無しさん：2006/06/11(日) 00:06:10
enum A{ ONE, TWO, THREE}
のどこでGenericsがいるのだろうか。
353 ：デフォルトの名無しさん：2006/06/11(日) 00:19:01
>>351
>>352
Java 5.0のAPIドキュメント見ればわかるけど、列挙型の基底クラスである
java.lang.Enumの定義自体にGenericsが使われているよ。
354 ：デフォルトの名無しさん：2006/06/11(日) 00:23:07
>>353

Effective Javaのtypesafe enumの実装みたことあるのか?
355 ：デフォルトの名無しさん：2006/06/11(日) 00:37:25
>>350
一番大きいのはAWTスレッドがとまっていてもウインドウが描画されることかと

あとはJava2DでOpenGLパイプラインがLinux系でデフォになるようでクライアント分野も
DirectX使ってるWindowsに速度的に追いつくかなと

ただ、5.0のOpenGLサポート見てると非常に期待が出来ないのだけれども
JOGL使ってるなら大丈夫かな
つーかJOGL標準APIにしてください

>>354
そういうこといってるわけじゃないだろ？たぶん
356 ：デフォルトの名無しさん：2006/06/11(日) 00:49:22
>>354
そりゃもちろん見たことある。というか、何故Effective Javaのtypesafe enumの
話になる？Java 5.0のtypesafe enumがEffective Javaのそれが元になっている
のは知ってるが、全く同じというわけじゃない。
357 ：デフォルトの名無しさん：2006/06/11(日) 01:00:42
>>356
そりゃGenericsがなくてもtypesafe enumが作れるからだろ
GenericsがないとJava 5.0と全く同じものはつくれないけど
typesafe enum自体はつくれる

Genericsのおかげで作れたなんて変だって話でしょ
358 ：デフォルトの名無しさん：2006/06/11(日) 01:18:45
>>357
いや、そりゃtypesafe enum自体はGenericsが無くても作れるけど、
Enum同士のcompareToによる比較などが型安全にできないでしょ？で、>>349は
そういうのを指して

> foreachに関してはともかくtype safe enumは
> Genericsのおかげで「簡単になった」。

と言っていると思ったんだが。あ、もちろん>>323の言っている
ことは変だと思ってるけど、>>351や>>352は>>349に対する言及
だと思ったので。
359 ：デフォルトの名無しさん：2006/06/11(日) 02:07:13
Generics とか enum とか、Tigerで追加された機能の話題はこっちでやったら？

【JavaFive】C＃からJ2SE5.xへ進化【TigerShot】
http://pc8.2ch.net/test/read.cgi/tech/1094891986/
360 ：デフォルトの名無しさん：2006/06/11(日) 02:50:30
いいんじゃないの？ここで。
361 ：デフォルトの名無しさん：2006/06/11(日) 03:31:27
Generics とかは現行世代の機能だから次世代スレでやるのは筋違いでしょ。
362 ：デフォルトの名無しさん：2006/06/11(日) 04:28:00
流れってもんも大切だし、極端に筋違いなわけではないし、そもそもこのスレの「次世代」というのは、Mustangスレの次スレをTigerスレでやろうかという意見があったときに、じゃあ次世代Javaというスレをたててまとめてというのがあったわけだし。
363 ：デフォルトの名無しさん：2006/06/11(日) 04:29:13
それに、enumとかGenericsとかについて意見が食い違うという時点で、次世代ということにしてもいいと思うわけで。
364 ：デフォルトの名無しさん：2006/06/11(日) 08:59:34
>>358
compareTo以外に何かある？
365 ：デフォルトの名無しさん：2006/06/11(日) 13:03:25
なんか一人genericsが嫌いなやつがいるようだな
366 ：デフォルトの名無しさん：2006/06/11(日) 15:11:08
>>325
それはWeakest Post Conditionという奴か？

ならば、Template Method パターンまたはアスペクト指向で
実現できまいか？
367 ：デフォルトの名無しさん：2006/06/11(日) 15:15:06
>>334
展開する前の前処理にGenericsが関与してるに1バイト
368 ：デフォルトの名無しさん：2006/06/11(日) 15:23:10
>>351-352
EnumクラスのJavadocを見ると
Enum<E extends Enum<E>>
使われて無くはない。

Genericsが使われているかいないかで
Javaのenumの仕様がかなり異なってくる。
C/C++のようなtype unsafeなenumにするわけにはいかないから
Genericsを導入するまでenumを導入するわけには
いかなかった理由がよくわかる。

369 ：デフォルトの名無しさん：2006/06/11(日) 15:24:19
>>357
Genericsのお陰で作りやすくなった
以前より比較的正しいenum実装ができるように
なった、とでも言うべきだろう。
370 ：デフォルトの名無しさん：2006/06/11(日) 15:29:58
>>364
equals(), clone(), hashCode(), toString(), valueOf()
371 ：デフォルトの名無しさん：2006/06/11(日) 15:47:30
>>362
そのMustangの話題ですらないわけだが。
372 ：デフォルトの名無しさん：2006/06/11(日) 15:55:01
今後はもうベンチマークに期待できなくなってくるのかな
Swing周りの改良は今後も進むかもしれないけど、業務では変わらない？
JVM統合の流れになっていくのかな
373 ：デフォルトの名無しさん：2006/06/11(日) 16:14:19
>>367
くわしく
374 ：デフォルトの名無しさん：2006/06/11(日) 17:15:01
>>372
業務でSwing使えばいいじゃない
すでに社内システムはWEBアプリは衰退していてリッチクライアントが普及してきているよ

不特定多数ならWEBアプリだけど、開発効率が段違いにわるいので
コスト増が問題になってるという感じ
375 ：デフォルトの名無しさん：2006/06/11(日) 20:23:42
今更であれだけど、Genericsっていいの？
コンテナに間違ったモノ突っ込むなんてバグはもとから経験無いけどなぁ。
376 ：デフォルトの名無しさん：2006/06/11(日) 20:50:16
キャストが要らないからそのままメソッド呼べたり、すっきりするってのが一番の恩恵でしょ。
377 ：デフォルトの名無しさん：2006/06/11(日) 20:58:09
自分だけで作ってるとあまり恩恵はないね
他人の作ったコード呼ぶ部分でListとだけ書かれてると困るので助かる

JavaDocとか整備されてないライブラリとかで泣きながらソースよんで苦労することが減った・・・
List<Map<Key,Value>>とか業務系だと頻繁に使うしね

大規模開発こそ結合部のドキュメント系が必要なのに整備されている率が低い傾向にあるのはどういうことだろう
ウォーターフォールの出来上がってくる設計書類にそんなものがまったくないという

少人数でライトウェイトな開発していればまずインターフェース作りましょうとかドキュメントは
大事なところだけ書いてあとはJavaDocにガンガン記述していきましょうとかそういうのが多いな

とりあえず何も考えなくてもよくなるEnumはかなり恩恵があるのは確かだが
378 ：デフォルトの名無しさん：2006/06/11(日) 21:09:27
>>370
valueOf はそうだけど、他は関係ないような気がするよ。
379 ：デフォルトの名無しさん：2006/06/11(日) 21:13:13
>>377
そのList<Map>構造の部分、今度はXMLになるかもね
また構造わかんねｗｗｗｗ
380 ：デフォルトの名無しさん：2006/06/11(日) 21:16:08
>>375
例えばMapでキーや値の型を仕様変更した場合に、
根っこの一箇所変えれば
コンパイルエラーがどこを直せばいいか教えてくれるのが楽。
ってのもある。
381 ：デフォルトの名無しさん：2006/06/11(日) 21:18:59
>>372
JVM統合って何？
382 ：デフォルトの名無しさん：2006/06/11(日) 21:23:26
-serverオプションが消えるとか
383 ：デフォルトの名無しさん：2006/06/11(日) 21:36:46
>>375
間違ってダウンキャストしなくて済むし
いちいちドキュメントにこの型にはこれ以外入れるなとか
書かなくて済む。
384 ：デフォルトの名無しさん：2006/06/11(日) 21:38:12
>>378
Enumの中に入れ子になっているオブジェクトの型が一致しなかったら
あれなのでequals()とか、hashCode()も重要
385 ：デフォルトの名無しさん：2006/06/11(日) 23:04:03
業務系のソフトウェアでは、Mapの中にMapが入っていて、しかもそのMapの要素は
Listが３つ、なんてざらにある。

で、そのListに何が入っているのかはドキュメント化されてないし、うっかりしてると
Mapを入れるべきところにListを入れてしまったり....と、orzになる機会は山ほどある。

genericsについていろいろ言われているようだけど、Collectionフレームワークの型
安全性を高めるという点について「ｲﾗﾈ」と言ってたﾔﾂを俺はしらないな。

Goslingﾀﾝもそこをとても重視していたみたいだよ。ソースが見つからないがそんな
こと言ってた。
386 ：デフォルトの名無しさん：2006/06/11(日) 23:19:53
genericsいらないって言っていた馬鹿は探せばいるだろ。
どんな馬鹿でもいるもんだから。
そんな馬鹿が手のひらを返してgenerics便利だと言ったところで一体なんだというのだ?
387 ：デフォルトの名無しさん：2006/06/11(日) 23:21:55
しかし今頃この話題が出てきたということは6が出そうなこの時期に
やっと5.0つかった開発がスタートしはじめているということだろうか
388 ：デフォルトの名無しさん：2006/06/11(日) 23:24:02
>>386

何でもない

いや、それがこの話の結論のはずなんだが
それで納得できない暴れたい盛りのやんちゃ坊主がたくさんいてな・・・

前向きでない議論は無駄。
現行Genericsの不備点を挙げて、こうなればいいのに・・・とかいう話ならまだ広がるんだが・・・
389 ：デフォルトの名無しさん：2006/06/11(日) 23:31:53
>>387
そろそろドカティもJava5に入り始めるんじゃない？
390 ：デフォルトの名無しさん：2006/06/12(月) 00:03:01
>>389
・)ﾉｼ
1.3で開発してるドカティが来ましたよ
こんな太古のアプリ改造するくらいなら新規で作れよそもそも設計からして腐ってんだからさぁとか言いながらコード書いてますよ
5で書きたいよぅ>>377が言ってる問題にぶちあたりまくりで元からバグバグなコードいじる度にビクビクしなきゃならんのは嫌だ
391 ：デフォルトの名無しさん：2006/06/12(月) 00:18:57
>>390
そういうなおいらは去年ようやく1.1から1.4へのUpgradeに成功した
2年ほど前に出した見積がようやく日の目を見たって所だ
392 ：デフォルトの名無しさん：2006/06/12(月) 00:26:07
保守的な奴らが居るとうんざりするときあるな
1.4.2で作ってるんだが、_??の部分までぴったり合わせるよう指定が来る
いやいや、それってバグフィクスのバージョンだろと突っ込みたくでも突っこめない
仮にバグっててもそれのお陰でうまく動いてるのを当てにするんだろうな
393 ：デフォルトの名無しさん：2006/06/12(月) 00:27:19
>>391
なんか生き残れるのか心配になるようなローペースさだな。
394 ：デフォルトの名無しさん：2006/06/12(月) 00:50:10
>>389
J2SE5.0使ったシステム2つうけてるけど、ついていける人とついていけない人がやはり現れますな

勉強し理解する人は5.0すごくよくなってるといい、勉強しないで分からないというだけの人は
なんでこんなバージョンにしたの?といってくる

知的労働者なんだからまったくついていけないようだったら首を切るのを勧めたほうがいいだろうね
そういうのはだいたいCOBOLメンテしてきてVBやってる人に多いかと思えばそんなことはなく
COBOLもしってCもやれてJavaもきっちりしってる人も割と多い
言語の得て不得手をしっかりと理解できているかどうかはが大事

逆にJavaやCでずっとWEBアプリ業務でやってきましたという人種でもかなり危険なやつらが多い
1メソッド数百行をスコープ範囲狭めることなく平気で書くのが特徴だから分かりやすいといえばそうなのだが
395 ：デフォルトの名無しさん：2006/06/12(月) 01:34:52
>>392
涙が出るほど共感を覚えるが、スレ違いではあるまいか
396 ：デフォルトの名無しさん：2006/06/12(月) 01:46:24
雑談スレだし、いいんでないの？
397 ：デフォルトの名無しさん：2006/06/12(月) 02:19:45
いったいいつから雑談スレに.....orz
398 ：デフォルトの名無しさん：2006/06/12(月) 03:55:55
_XXを気にするなんて、まともな所なら常識だろ。
_XX変えたらテストやり直し。保守的とかじゃなくてブロの常識。
399 ：デフォルトの名無しさん：2006/06/12(月) 04:23:10
まともなところとかまともじゃないところとかは関係ないと思うな。
常識かどうかも。

そこまでの信頼性が求められるかどうかだと思われ。
信頼性もとめるなら、まだJava2SE5.0は使えないんじゃないかな。
400 ：デフォルトの名無しさん：2006/06/12(月) 04:32:56
ただ、障害が出たときのサポートと、サポート期間考えると最新使わないわけにもいかない
5年単位の利用期間に対して、それ以前にSUNのサポートが切れるJVM使うのもできないし・・・
1.4.1のGCのバグで散々な目にあったよ・・・orz

しかし、Tigerはそろそろ使えるようになってると思うんだが・・・
Mustangが出るってのに2世代前しか信頼できないって状況はないんじゃない？
というか、信頼性なんて自分たちで確かめるもんだし。
401 ：デフォルトの名無しさん：2006/06/12(月) 05:56:32
ハイエンドのサポートはSunだけじゃないからな。
自分達で確かめれる程度の信頼性なら、自分達で確かめればいいと思う。
402 ：デフォルトの名無しさん：2006/06/12(月) 06:13:52
使う範囲で信頼できれば十分だからね。
403 ：デフォルトの名無しさん：2006/06/12(月) 10:58:35
>>398
それにかかるコストを誰が払っていると思っているんだ。
誰も払わなければやるだけ無駄でSunに踊らされているだけだろ。
ちょっとバージョンアップしたくらいでまたそのバージョンに
遭わせて無駄に過剰テストして無駄に管理を厳しくするのは
コストの無駄。テストの自動化もできない奴がそういうことをしたがる。
404 ：デフォルトの名無しさん：2006/06/12(月) 11:09:35
自分の常識が世の中全体の常識と思ってるヤツがいるな。
405 ：デフォルトの名無しさん：2006/06/12(月) 11:24:21
>>403
問題が出てからの対処で良いならその考え方もあるが
何でか知らないが開発会社に全てのコストを押し付ける顧客が多すぎるよな
やって欲しいならそれに見合う金を払えってんだ
406 ：デフォルトの名無しさん：2006/06/12(月) 12:30:30
>>403
おまいは、安かろう(品質)悪かろうのシステムしか経験がないのかも知らんが、
それを一般化するなよ。>>399の言う通り、どこまで品質が求められるかどうかがポイント。
自分の基準で過剰テストだの無駄だの、安物PGにしか見えないからあまり言わない方がいいよ。
だいたい、テスト自動化となんの関係があるんだか…。
407 ：デフォルトの名無しさん：2006/06/12(月) 13:19:56
>>406
ひとこと言わせて貰うと、お前は考え方が古い。
20年くらい前のCOBOLerが大好きながむしゃら管理手法で
やっている。

Java5でないとうごかない製品ももうすでにかなり出ている。
すでにJava5は実績としてはかなりのものだ。
408 ：デフォルトの名無しさん：2006/06/12(月) 13:39:06
もはや Generics の話題ですらないな。
説教したい/されたいならマ板でどーぞ。
409 ：デフォルトの名無しさん：2006/06/12(月) 13:45:06
おれはJavaSE5が使えんとは書いてないが…。
運用トラブルリスクはそっちのけで安価・短期が最優先という考え方もアリだろう。
だが、システムの必要品質を確保するのに、古いも新しいもない。全然理屈になってないよ。
そんな事言ってると、底辺PGとバレるから気を付けた方がいいぞ。

というか、テスト自動化されてんなら、テストやり直しに何でファビョってんの？
410 ：デフォルトの名無しさん：2006/06/12(月) 15:26:14
商用アプリサーバのＳＥ５のサポートって
最近じゃない？
やっとベンダにとって、サポートコストがぺイするレベルに枯れてきたって事か。
411 ：デフォルトの名無しさん：2006/06/12(月) 15:34:32
どっちがファビョってるんだか。

たまにJavaすれにVBあがりのドトネト厨が
割り込んで来ることがあるけどそれ系の厨かなw
412 ：デフォルトの名無しさん：2006/06/12(月) 15:36:07
>>410
商用じゃなきゃ信用できない
なんていったらLinuxがアップデートされるたびに
過剰テストにものすごく無駄に時間をかける羽目になるんだが。
Java5の枝番号が変わっただけでその都度細かいテストするのも
まさに効率悪い。
413 ：デフォルトの名無しさん：2006/06/12(月) 16:19:10
全員スレタイ見直してくれ・・・頼む・・・orz
414 ：デフォルトの名無しさん：2006/06/12(月) 17:28:41
まあ、この手の素人PGが次世代Javaのバグ出しをしてくれて、
堅いシステムにも使える様にしてくれる、と言うことで。
415 ：デフォルトの名無しさん：2006/06/12(月) 18:04:05
素人PGがまともにBugParade登録出来るとも思えないけど。

Genericsの現実的な使いどころって、
コンテナ（ぽい）オブジェクトの中身の明示以外どんなのがある？
416 ：デフォルトの名無しさん：2006/06/12(月) 20:10:02
>>412
おまえ、ハイエンドの品質の厳しさわかってる？
417 ：デフォルトの名無しさん：2006/06/12(月) 20:10:44
>>413
次世代Java厨の動向
418 ：デフォルトの名無しさん：2006/06/12(月) 20:15:15
>>415
type safe enumだろ (以下ループ
419 ：デフォルトの名無しさん：2006/06/12(月) 20:38:31
>>415
Observer/Observableを型安全に使えるようにするとか。
残念ながらJava5のそれは、Generics対応になってないが。
あとは、コンテナと無関係ではないが、型に依存しないアルゴリズム
のライブラリ化とか。C++のtemplateみたいに、今までできなかったことが
できるわけじゃないので、今まで型安全にできなかったこと(Object型で代用して
いたこと)を型安全に行えるようにする、というのが主な使い道じゃないかなあ。
420 ：デフォルトの名無しさん：2006/06/12(月) 21:30:17
仮定のない品質など議論する意味はない。

>>419
俺もそう思う。
Objectを突っ込みまくっていた部分を見直して
綺麗なロジックが書きやすくなるという部分かな、と。

アスペクトとまでは行かないけれど、ロジックだけを切り出して
実装できるのも、何という機能というわけじゃないけど面白い。
言ってみれば、Map,ListなどGenericsの恩恵を直に受けたライブラリは
そのMap,Listという振る舞いを型に依存しないで実装できたいい例だったということだから。
421 ：デフォルトの名無しさん：2006/06/12(月) 23:09:20
で、ながれを戻そうとしてもなぜ現世代Javaの動向に戻るんだ？

次世代はどうした。
422 ：デフォルトの名無しさん：2006/06/12(月) 23:39:48
んじゃ次世代らいく・・・

お馬さんのJava2Dレンダリングどーなってるの？
Windows版はデフォはDirectXのまま？
あいかわらずほとんどの描画がアクセラレーションきかないの？
423 ：デフォルトの名無しさん：2006/06/13(火) 02:31:28
>>421
次世代Javaプログラマの動向
424 ：デフォルトの名無しさん：2006/06/13(火) 10:33:25
そもそもJavaプログラマの定義なんて曖昧。
煽ってる奴やJavaが嫌いな奴はJavaプログラマ＝Javaしかできないプログラマと
脳内変換して話を進めたがるから話が当然噛み合わないわけだし。
実際に、Javaの仕事をするときにJavaしか知らないでは、まったく
仕事ができないものだが。
425 ：デフォルトの名無しさん：2006/06/13(火) 10:35:03
>>424
実際にJavaしか知らないって奴がいっぱい居るじゃん
まあそういう奴はJavaすら知らないって事が多いけど
426 ：デフォルトの名無しさん：2006/06/13(火) 11:04:30
だから

Javaしか知らない奴
という表現は論理的に矛盾していると
427 ：デフォルトの名無しさん：2006/06/13(火) 12:17:24
続きはマ板で。
本当に底辺野郎じゃなければ
もっと融通が利いているはず。
428 ：デフォルトの名無しさん：2006/06/14(水) 00:10:18
なんだが、Genericsを否定したい奴がいちゃもんつけてるようにしか見えないな。
彼の主張は「C++Templateはいらないと言ってい他奴がGenericsは欲しいと言いだした」
ということらしいがな。
彼の脳内ではC++Template == Generics
でないと気が済まないようだ。


429 ：デフォルトの名無しさん：2006/06/14(水) 00:34:43
もうGenericsは入ったんだから便利に使おうぜ。
それよか、久々にMustang案内入れるか・・・

Mustang b87
ttp://download.java.net/jdk6/binaries/
ttp://www.java.net/download/jdk6/changes/mustang-b87.html

changeを見ると壊れてんのかな？と思うが新しいフィーチャーはない。

Java SE 6.0 Release 1 Developer Preview 3
ttp://connect.apple.com/

Appleも追従してDeveloperPreviewを出してきている
こちらはb82ベース
NewFeatureは
* Applet support (plug-in)
* Java Web Start
* Java SE 6 Java Preferences utility
PowerPCのJITはまだらしい。
430 ：デフォルトの名無しさん：2006/06/14(水) 01:12:23
>>429
> PowerPCのJITはまだらしい。

というかMacはもう…
431 ：デフォルトの名無しさん：2006/06/14(水) 10:30:43
えーと、CocoaにはJavaAPIの新規追加はもうない、って話かしら?
432 ：デフォルトの名無しさん：2006/06/14(水) 11:04:34
PowerPC終了でしょう？
433 ：デフォルトの名無しさん：2006/06/14(水) 12:31:07
>>428
どうしてもtemplate!=genericsにしたいようだが
parameterized typeという点ではどっちも同じ
仕組みが違うのはあたりまえ
434 ：デフォルトの名無しさん：2006/06/14(水) 12:37:43
Javaから見たらgenerics≒templateで良いじゃないか
435 ：デフォルトの名無しさん：2006/06/14(水) 13:04:04
>>433
いや、違いすぎるだろ。
C++ templateはかなり独特だから。
436 ：デフォルトの名無しさん：2006/06/14(水) 13:32:58
>>428 >>433 >>435
3人ともtemplate!=genericsと言ってるのに論争になるのﾜﾛｽ
437 ：デフォルトの名無しさん：2006/06/14(水) 13:49:42
ところで、>>1のマルチタスクの実現ってのはどうなったんだ？
既に実装済み？
438 ：デフォルトの名無しさん：2006/06/14(水) 14:26:33
>>436
template<genericsとtemplate>genericsとtemplate>>>genericsじゃ論争になるだろ
439 ：デフォルトの名無しさん：2006/06/14(水) 14:38:50
template<genericとtemplate> generics
と区切ってしまい、何のことかわからんくなってた。
440 ：デフォルトの名無しさん：2006/06/14(水) 15:55:59
それぞれどういう意図で発言しているかがつかみずらいが、
もし、templateとgenericsが実現の仕組みが**多少**違うくらい
で、同じようなものだと思っている人がいるとしたら、もうちょっと
(C++の)templateのことを勉強した方がいいと思った。実際、
templateとgenericsはある程度までは同じ目的で使えるが、
かなり違うセマンティクスを持っている。優劣をここで述べる
つもりは無いが、それだけは確かだ。
441 ：デフォルトの名無しさん：2006/06/14(水) 16:19:17
>>439
おまえまだgenericsに慣れてないな。
「genericsとtemplate」を扱えるtemplate<?>型のgenericsという変数を宣言しているのだよ。
442 ：デフォルトの名無しさん：2006/06/14(水) 17:00:18
お前ら、頼みがある。Genericsに関しては既に実装された機能だから、他のところでやってくれないか。
せっかく新ネタ持ってきてくれてる人がいるのに、いつまでも粘着しないでおくれ。
443 ：デフォルトの名無しさん：2006/06/14(水) 17:06:45
>>442
劣勢だな。
流れだし、いいんでねぇの？
444 ：デフォルトの名無しさん：2006/06/14(水) 17:22:21
>>443
マ板的なネタで盛り上がるぐらいなら閑散としてたほうがマシ。
445 ：デフォルトの名無しさん：2006/06/14(水) 17:39:26
そうかなぁ
446 ：デフォルトの名無しさん：2006/06/14(水) 18:25:45
>>438
templateクラスがgenericsとtemplate型をパラメータに持って

と思ったらなんだその文法わ
447 ：デフォルトの名無しさん：2006/06/14(水) 18:48:06
6のSwingはWindowsOSにも恩恵はありますか？
448 ：デフォルトの名無しさん：2006/06/14(水) 19:31:09
恩恵ってなんですか
449 ：デフォルトの名無しさん：2006/06/14(水) 19:36:55
トレイが使えるようになる。
Desktop#browse, mail, edit, open, printなどができた。
450 ：デフォルトの名無しさん：2006/06/14(水) 19:40:37
レンダリングに関しては別にって感じですか。
まあそれらの機能だけでも十分かもしれませんね。
451 ：デフォルトの名無しさん：2006/06/14(水) 20:06:43
>>449
全部 AWT の機能だけど。
452 ：デフォルトの名無しさん：2006/06/14(水) 21:00:43
Genericsとかの話用にスレ立てた。
何かすっきりしないと思ったんだよね。

現世代Javaの動向 1
http://pc8.2ch.net/test/read.cgi/tech/1150286189/

【JavaFive】C＃からJ2SE5.xへ進化【TigerShot】
http://pc8.2ch.net/test/read.cgi/tech/1094891986/
はどうすんだって話はあるけど、ま、Mustangリリース後は、
ここがDolphinの話題になって、現世代にMustangが含まれる、でいいかと思って
453 ：デフォルトの名無しさん：2006/06/14(水) 21:13:48
>>447
フォントのAAがヒントに従ってかかるようになった。
5のswing.aatext=trueのように、UI Gothicにまでかかることはなく、tahomaなんかには
なにもしなくてもAAがかかる。
454 ：デフォルトの名無しさん：2006/06/14(水) 21:24:23
(　ﾟдﾟ)､AAだと!
455 ：デフォルトの名無しさん：2006/06/14(水) 21:28:53
>>453
ビットマップ情報使えるサイズの場合はアンチエイリアスかからないだけなんでは？
456 ：デフォルトの名無しさん：2006/06/14(水) 23:31:36
個人的にはAAはどうでもいいかな。
browseとトレイはありがたいね
457 ：デフォルトの名無しさん：2006/06/15(木) 11:50:22
>>452
スレ違いを文句いいながら、板違いのスレ建てるわけか。
458 ：デフォルトの名無しさん：2006/06/15(木) 14:13:46
無駄に重複してるだけに見えるがな
459 ：デフォルトの名無しさん：2006/06/15(木) 23:07:20
一時的なスレ違いのために、永続的な重複スレを建てるヤツ
460 ：デフォルトの名無しさん：2006/06/16(金) 10:08:20
たいてい重複スレのほうが長生きするんだよね。レスがないから。
461 ：デフォルトの名無しさん：2006/06/17(土) 00:01:52
Mustang beta2
ttp://java.sun.com/developer/technicalArticles/J2SE/Desktop/mustang/beta2.html

Top 10 Things You Need to Know
1. Web Services
簡単にWebService書けるようになってな、アノテーションで簡単やねん
2. Scripting
PythonとかRubyとか使えるし、みんな使えよ
3. Database
JDKにApacheDerby入るで。@Query(sql="select * from user")とかのアノテーションでSQL埋め込めるし。
4. More Desktop APIs
沢山デスクトップ用改良入ったから期待しとけよ。
JTableとかソートとかフィルタとかできんねよ、すごいやろ？
5. Monitoring and Management
何も考えんでもモニタとかできるようになったで。
Jhatっちゅうヒープ分析ツールも入れといたさかいにあんじょう使うてや。
6. Compiler Access
JSPとかPHP作る人には便利になったやろうなぁ。うごいとる時にコードの
コンパイル動的してJavaCodeにできるんや。
7. Pluggable Annotations
アノテーション自分で付けれるようになってみんなニコニコだお（　＾ω＾）
8. Desktop Deployment
GUI綺麗に簡単になったで。まぁそれはそのゴニョゴニョや。
9. Security
XML署名とか入ったり、セキュリティの管理簡単になったの。
10. The -ilities: Quality, Compatibility, Stability
まぁ、なんや、みんな、これまで通りよろしゅうな
462 ：デフォルトの名無しさん：2006/06/17(土) 00:28:51
VMで動いてるんだからVMwareみたいにSuspend/Resumeできればいいのに
463 ：デフォルトの名無しさん：2006/06/17(土) 07:03:58
>JDKにApacheDerby入るで。
うわぁマジで？俺も使ってるけど標準はやりすぎだろ…
HSQLのが速いし組み込む目的ならこっち
464 ：デフォルトの名無しさん：2006/06/17(土) 07:20:30
HSQLDBは、通らないSQLが多いからなぁ。
まあ、IBMの政治力の勝利ってことでしょう。
DB2互換だし。
465 ：デフォルトの名無しさん：2006/06/17(土) 07:22:48
Apache Derbyじゃなくて「Java DB」が組み込まれるということになってるけどね。
NetBeans5.5のメニューが「Derby DB」から「Java DB」に変わったときから気になってた。
466 ：デフォルトの名無しさん：2006/06/17(土) 07:25:44
DerbyといえどSQL92に完全準拠してるわけではないよな
JVMのベンダー互換が崩れるきっかけになりそうでやだな
JDOQLだかに準拠させる規格でもあるのかな
467 ：デフォルトの名無しさん：2006/06/17(土) 08:09:14
JDOはもう死んでるでしょ。
それを言うならJPQL(旧EJB-QL)かな。
IBMの意図はわかるけど、Sunの意図がわからない。
468 ：デフォルトの名無しさん：2006/06/17(土) 10:05:42
PersistenceAPIのためだろ
469 ：デフォルトの名無しさん：2006/06/17(土) 10:44:55
OJB＆Derbyで標準化して、実際使うときはHibernate＆HSQLにするということだね
470 ：デフォルトの名無しさん：2006/06/17(土) 10:51:17
HSQLDBはスタンドアロン用だからな
まったくターゲットが違うしJDBCドライバサポートが1.0レベルだったようなきが
HSQLDBの後継のやつはシンプルさが失われてるらしいのがちと心配

スタンドアロンアプリで付属DBとしてならHSQLDBのほうが楽かと
Windowsの業務系スタンドアロンパッケージのほとんどがMSDE使ってるのと同じような感じで
あちらは将来MSSQL鯖にかえるのが目的にもなってるが
471 ：デフォルトの名無しさん：2006/06/17(土) 13:38:37
Mustang b88
ttp://download.java.net/jdk6/binaries/
ttp://www.java.net/download/jdk6/changes/mustang-b88.html

MSVC 2005 Expressでのビルドエラーが解消されている。
只でビルド環境そろえられるって素晴らしい。

日本語ドキュメントのレビューがしたい方はこちら
ttps://jdk-api-ja.dev.java.net/ja/index.html
472 ：デフォルトの名無しさん：2006/06/18(日) 12:58:55
>>471
俺は、
> 6382711JComboBox incorrectly rendered with alternate WinXP theme
がうれしい。
473 ：デフォルトの名無しさん：2006/06/18(日) 20:27:38
>>461
> 1. Web Services
> 簡単にWebService書けるようになってな、アノテーションで簡単やねん
Java EE絡みのものがなぜかJava SEでできると？

> 3. Database
> JDKにApacheDerby入るで。@Query(sql="select * from user")とかのアノテーションでSQL埋め込めるし。
これは凄い。なんでHSQLDBじゃなかったんだろう。
機能性の高さからかな？ 採用されたのは背後でIBMの関与でもあったのかな？
Appletからメモリ上にテーブルを作成してクエリ呼び出すようなことできるのかな？

> 9. Security
> XML署名とか入ったり、セキュリティの管理簡単になったの。

簡単になるのか。Javaのポリシーファイルはなんだかイマイチだったのか
嬉しいかも。
署名がXMLってどういうこと？ genkeyで作るものはバイナリでは？
ポリシーファイルがXMLになるだけ？
474 ：デフォルトの名無しさん：2006/06/18(日) 20:28:51
>>466
> DerbyといえどSQL92に完全準拠してるわけではないよな
> JVMのベンダー互換が崩れるきっかけになりそうでやだな
そのうちSQL92互換になってゆくのではないかと。
SQL99互換になればいいんだけどねえ
475 ：デフォルトの名無しさん：2006/06/18(日) 20:43:02
Mustangｇが出たとき、
HSQLDBを搭載しているJBossはどのような動きを
示すのか？

HSQLDBをJBossから外してゆくのかな？
476 ：デフォルトの名無しさん：2006/06/18(日) 20:46:49
BEAは面白くないだろうなJava6シリーズは。
477 ：デフォルトの名無しさん：2006/06/18(日) 21:04:14
>>473
XML署名ってRFC3075のことでしょ。
http://www.w3.org/Signature/
http://www.ietf.org/rfc/rfc3075.txt

この辺り、XMLで統一的に扱えるように。
http://www.w3.org/2000/09/xmldsig#X509Data
http://www.w3.org/2000/09/xmldsig#PGPData
http://www.w3.org/2000/09/xmldsig#SPKIData
http://www.w3.org/2000/09/xmldsig#MgmtData
478 ：デフォルトの名無しさん：2006/06/19(月) 00:58:30
>>473
SEでWEBサービスが、というのはクライアントの話だろ？
JDBCやRMI、クライアントのソケットと同じでは？
479 ：デフォルトの名無しさん：2006/06/20(火) 12:55:00
XMLパージングとJavaオブジェクトマッピングを、
アノテーションを使って簡単に。ってことみたいだな。

今時クライアントサイドでも色々やりたいしな。
480 ：デフォルトの名無しさん：2006/07/02(日) 18:41:14
Bata2 に ApacheDerby って入ってるの？
インストールしてみたけど、
どこにあってどう使うのかがわからん。
481 ：デフォルトの名無しさん：2006/07/02(日) 19:42:57
>>480
さぁ？アレ適当に訳したから。
原文は、
final Mustang development kit(JDKだね) will(だからまだかも) co-bundle....
ってなってるからまだ入ってないかもよ。
482 ：デフォルトの名無しさん：2006/07/02(日) 20:00:33
http://www.javalobby.org/java/forums/t74408.html
β２ってb84だったような・・・
483 ：デフォルトの名無しさん：2006/07/02(日) 22:15:01
http://journal.mycom.co.jp/news/2006/06/22/102.html
の辺りの記事では
Beta2 に入ってるっぽく書いてあるんだけど、

ttp://www.in-vitro.jp/blog/index.cgi/Mustang/20060620_01.html
のように
%JAVA_HOME%/db
には入ってなかった
484 ：デフォルトの名無しさん：2006/07/03(月) 01:10:44
せっかくweekly buildされてんだから、β２にこだわらず、最新build使うってのがいーんじゃない？
485 ：デフォルトの名無しさん：2006/07/03(月) 02:50:44
b90 のインストールに失敗するんだよね
「変換するときにエラーが発生しました。
指定された変換のパスが有効であることを確認してください」とかいわれる。

jdk-6-rc-bin-b90-windows-i586-30_jun_2006.exe って奴を
3回落としてきてるんだけど、3回とも同じメッセージが出て駄目だった。

b89 だったらインストールできるんだけど。
486 ：デフォルトの名無しさん：2006/07/03(月) 03:10:10
>>485
漏れも出る。
インストーラのアイコンも変わってるし、
何か派手な事またしてんのかなーっと思って、b89入れ直しました
487 ：デフォルトの名無しさん：2006/07/04(火) 09:31:22
b90でRhino削除されてないか？
488 ：デフォルトの名無しさん：2006/07/04(火) 20:51:34
時給１０００円でＪａｖａ教えてくださるかたを募集します
場所　所沢（池袋・高田馬場から直通）
よろしくおねがいします
ｉ−ｗａｎｔ−ｔｏ−ｓｔｕｄｙ−ｊａｖａ＠ｈｏｔｍａｉｌ．ｃｏ．ｊｐ
489 ：デフォルトの名無しさん：2006/07/05(水) 02:20:38
コンビニのバイトより安いですが、よろしくお願いします。
490 ：デフォルトの名無しさん：2006/07/05(水) 02:42:38
この時給って事は、その分、生徒が夏帆みたいな子なんだよな？

491 ：デフォルトの名無しさん：2006/07/07(金) 20:39:21
https://jdk-api-ja.dev.java.net/ja/mustang.html で
APIドキュメントの翻訳進行中
492 ：デフォルトの名無しさん：2006/07/12(水) 00:26:45
b90でコケて(?)以来、snapshotがとまったな。
493 ：デフォルトの名無しさん：2006/07/12(水) 02:29:38
>>492
いや、forumではannualだからビルドねーよ、とのこと
SUNWは７月から会計年度始まるからな
494 ：デフォルトの名無しさん：2006/07/12(水) 03:01:13
>>492
> There won't be a promoted build on July 6th because of 4th-of-July holidays. [July 3, 2006]
495 ：デフォルトの名無しさん：2006/07/12(水) 08:41:36
>>490
所沢に行くとチーマーに拉致監禁されて
出会い系サイト作らされてｒｙ
496 ：デフォルトの名無しさん：2006/07/12(水) 09:46:35
>>488-489
なんだその安すぎる時給は。なめとんのかｺﾞﾙｧ！

時給5000円以上じゃないと絶対に引き受けない。

497 ：デフォルトの名無しさん：2006/07/12(水) 10:12:48
>>496
毎回手作りケーキと紅茶が付くとしても？
498 ：デフォルトの名無しさん：2006/07/12(水) 10:14:23
>>497
だれの手作りかによる
まずは写真とプロフィール（略
499 ：デフォルトの名無しさん：2006/07/12(水) 10:37:40
>>497
割に合わんな。毎日同じもん食っても飽きる。
毎日中華丼やキムチ食わされたらさすがにキレる。

そんな子供だましなことに乗せられる騙される奴は餓鬼や新人や新卒くらい。
そんな給料で結婚子育て生活ができるとでも思っているのか！！！！！！！！！！！！
二人の子どもを大学院に行かせる金も用意できないだろがゴルァ！
授業料がいくらかかると思っているのか貴様！

ケーキが100円、紅茶が150円だとして、時給1000円
だとしても、
一日8時間勤務だとしたら、日給8250円相当にしかならない。
500 ：デフォルトの名無しさん：2006/07/12(水) 17:52:25
>>499より>>498に賛同する。
人間、夢を持てよ。
501 ：デフォルトの名無しさん：2006/07/12(水) 17:59:56
>>499
ケーキが欲しいんじゃない、人はケーキの向こう側に夢を見るんだよ
502 ：デフォルトの名無しさん：2006/07/12(水) 18:18:09
>>499
> ケーキが100円
「手作り」ということを忘れている。Priceless
503 ：デフォルトの名無しさん：2006/07/12(水) 18:27:45
そうか・・・・
>>499　 は今が幸せなんだな・・・・
手作りケーキがタダのケーキとして扱える位に・・・ちくしょう・・・orz
こんな小さな幸せでも拾いたいのは不幸せということか・・・
504 ：デフォルトの名無しさん：2006/07/12(水) 18:35:16
小さなことを幸せに感じることができるのは幸せなことだと思うぞ。
505 ：デフォルトの名無しさん：2006/07/15(土) 11:51:22
うーん、jdk-6-rc-bin-b91-windows-i586-13_jul_2006.exe もインストール失敗する。

いろいろ弄って、
C:\Documents and Settings\username\Application Data\Sun\Java\jdk1.6.0\jdk1.6.0.msi
を使うと英語版のインストーラが起動して、インストールできるっぽい。
っても、無理やり動かしてるからちゃんとインストールできてるかちょっと不安だけど。

ちなみに、エラーメッセージ出た直後に OK 押してインストーラ終了させちゃうと、
ファイルが揃ってない事があった。そのまま OK 押さずに放置して
〜\Application Data\Sun\Java\jdk1.6.0 に 12個 52M のファイルが
出来るのを待つのがコツっぽい。12個 52Mってのは b91 の場合ね。他は知らん。

b91 とか b90 とか普通に exe でインストールできてる人いるんだろうか？
506 ：デフォルトの名無しさん：2006/07/15(土) 23:11:22
>>500-502
相手が男だったら夢も潰れるよ。

それだったら高い給料から
差し引いて自分の金でケーキを買って食べるよ。
ついでに彼女にケーキをプレゼントする。

ケーキもらって喜ぶのは男より
女の子のほうだからな。

男はケーキより金のほうがいいに決まってる。
ケーキの上や中に不味いものや嫌いなものや
むさ苦しい男の手垢によって付着した黄色ブドウ球菌が
入っていたらそれだけで嫌な気分になるどころか
食中毒を起こして治療費負担が増大するからな。

それだったら自分でケーキを買った方がマシ。

>>497はせいぜい女を騙して働かせるんだな。
507 ：デフォルトの名無しさん：2006/07/15(土) 23:12:17
>>504
線香花火のように長続きしない幸せだ。
そんなことで幸せを感じるのは貧乏人や女だけ。
馬鹿な経営者に洗脳されて長時間労働させられて
幻覚を見ているだけだ。
508 ：デフォルトの名無しさん：2006/07/15(土) 23:44:57
幸せを感じる力は一種の才能
埋もれるほどの財を得ても他人を呪い明日の裏切りに怯える悲惨な人生もある
509 ：デフォルトの名無しさん：2006/07/16(日) 00:40:55
>>499=>>506は人格障害気味だな。
結婚子育てとか言ってるけど、無縁じゃないの？
510 ：デフォルトの名無しさん：2006/07/16(日) 12:28:52
>>508
カーネギーやナポレオンヒルやロックフェラーはそんなに悲惨かね。
堀江被告みたいなバカじゃあるまいし。
511 ：デフォルトの名無しさん：2006/07/16(日) 12:29:40
>>509
うーむ、そうやって人を見た目で判断しちゃ逝けないなー
512 ：デフォルトの名無しさん：2006/07/16(日) 14:13:59
>>506
何かいやな事があったんだな・・・強く生きていこうぜ・・・

で、俺もb90,b91のインストール状況は気になる。
b90で、
Eliminate installshield dependency for JDK offline msi installer
って言ってる変更が気になるんだよな・・・
513 ：デフォルトの名無しさん：2006/07/16(日) 18:44:24
会社で給与交渉や重労働のことで
都合が悪くなると昇給する代わりに
飯を奢って食わせてどうにか凌ぐ社長って奴じゃね？

半年に一回5000円の飯奢って貰うんだったら
昇給として月収5万アップして貰って自分の金で
伊勢海老なりフランス料理なり食った方がましってことだろう。
514 ：デフォルトの名無しさん：2006/07/17(月) 11:45:34
Rhinoの質問していいでしょうか。
JDK6にむけてRhinoの勉強をしているんですが、int値がかってにdouble値になって困ってます。
具体的には、int値をもつ変数に対して演算をすると、int + int => double になります。

import org.mozilla.javascript.*;
public class RhinoTest {
　public static void main(String[] args) {
　　Context context = Context.enter();
　　Scriptable scope = context.initStandardObjects();
　　String code = "var x = 3;¥n"
　　　　　　　　+ "var y = 3 + 2;¥n"
　　　　　　　　+ "var z = x + 2;¥n"; // int + int が double になる
　　context.evaluateString(scope, code, "(filename)", 1, null);
　　String[] varnames = { "x", "y", "z" };
　　for (int i = 0; i < varnames.length; i++) {
　　　String var = varnames[i];
　　　Object value = scope.get(var, scope);
　　　String cname = value.getClass().getName();
　　　System.out.println(var + ": class=" + cname + ", value=" + value);
　　}
　}
}

実行結果：
x: class=java.lang.Integer, value=3
y: class=java.lang.Integer, value=5
z: class=java.lang.Double, value=5.0 # ← doubleになってる

どなたか、解決方法を教えていただけないでしょうか。よろしくお願いします。
515 ：デフォルトの名無しさん：2006/07/17(月) 11:51:56
ECMAScriptの数値型って浮動小数点型しかないから、
むしろxとyがint型なのがおかしい気がする……
516 ：デフォルトの名無しさん：2006/07/17(月) 16:38:11
>>515
ありがとうございます。
>ECMAScriptの数値型って浮動小数点型しかないから、
そうなんですか。初めて知りました。
それだとすごく困りました。どうしよう。
517 ：デフォルトの名無しさん：2006/07/17(月) 17:25:42
Excelも浮動小数点しかないから誤差だしまくりだし
イコールでの数値判定は危険
だが、Excelは使われてる


もちろんそれが困る用途もあるが
要は用途による割り切りかたかと
518 ：デフォルトの名無しさん：2006/07/17(月) 20:15:34
>>517
誤差がどうとかではなくて、型が勝手に変わってしまうのを問題にしています。
JavaScriptを設定ファイルがわりに使おうと思ってたんですけど、型が勝手に変わるとなんぎします。
x = 1;
y = x + x;
で y が double になってしまうなんて。
for (i = 0; i < n; i++) {
　...
}
で i がdoubleだなんて。
どうしたものやら。
519 ：デフォルトの名無しさん：2006/07/17(月) 20:55:17
時給１０００円でＪａｖａ教えてくださるかたを募集します
場所　所沢（池袋・高田馬場から直通）
よろしくおねがいします
ｉ−ｗａｎｔ−ｔｏ−ｓｔｕｄｙ−ｊａｖａ＠ｈｏｔｍａｉｌ．ｃｏ．ｊｐ
教える対象は超初心者です。

専門学校などでJavaを勉強されていて夏休みだけ教えたいという方も歓迎です
520 ：デフォルトの名無しさん：2006/07/17(月) 21:12:37
==使わない限りDoubleでさほど問題ないのでは？
521 ：デフォルトの名無しさん：2006/07/17(月) 21:36:03
＞JDK6にむけてRhinoの勉強をしているんですが

なんかRhinoがJava6から脱落したみたいなレスがどっかにあったような…。
522 ：デフォルトの名無しさん：2006/07/17(月) 21:40:01
>>519
夏帆クラスの女の子の手作りケーキは付くのか付かないのか、
それが問題だと（ry
523 ：デフォルトの名無しさん：2006/07/17(月) 21:45:18
>>521
>>487 ただし、b90ｲﾝｽｺに失敗するので試せてない
524 ：デフォルトの名無しさん：2006/07/17(月) 22:04:31
b91 だと Rhino あるよ。rt.jar の中っぽいけど。
525 ：デフォルトの名無しさん：2006/07/17(月) 22:41:51
>>520
JavaScript側で設定した変数の値を、Java側にとってこようとしています。
そのため、JavaScript側でintを設定したつもりなのに、Java側に渡るとDoubleになっているのは困る訳です。
526 ：デフォルトの名無しさん：2006/07/17(月) 22:54:10
scriptでは常にDouble
精度速度保障のために値が変更されなければintのまま扱ってるだけだろうな
定数だけという感じで

だからJavaではDoubleをすべてvalueofで拾うのが正しそうだが
527 ：デフォルトの名無しさん：2006/07/18(火) 18:12:28
>>525
ウチで試したら、代入したときからDoubleみたい。
というか、何か呼び出し方が違うなぁ・・・・Binding使ってるから変換されてる？
この挙動から推察すると、JavaとのインターフェースではDoubleになるのが仕様なのでは？

/*ソースはインデントの為、半角→全角変換しています*/
package script;
import javax.script.*;
public class TypeTest {
　public static void main(String[] args) {
　　try {
　　　ScriptEngine se = new ScriptEngineManager().getEngineByName("js");
　　　Bindings bdg = se.createBindings();
　　　bdg.put("x", null);
　　　se.setBindings(bdg, ScriptContext.ENGINE_SCOPE);
　　　Object res;
　　　res = se.eval("var x = 1;");
　　　System.out.println("JS Binding:"
　　　　　+ bdg.get("x").getClass().getName() + ":"
　　　　　+ bdg.get("x"));
　　} catch (ScriptException e) {
　　　e.printStackTrace();
　　}
　}
}

結果：
JS Binding:java.lang.Double:1.0
528 ：デフォルトの名無しさん：2006/07/21(金) 17:58:47
b90以降インストール出来ない件は
やはりバグでした。b94でfix予定。
ttp://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6446356

回避策は、
jdk*.exe /lang=1033
としてインストーラを起動。
英語版として起動させるという手段らしいです。
529 ：デフォルトの名無しさん：2006/07/22(土) 23:13:33
Java5のGenericsなクラス、Genericsによって
型指定されたクラス(たとえばList<String>とか)を
クラス図で記述できるUMLモデリングツールがほしい。

Jude3.0では対応していなかった。

530 ：デフォルトの名無しさん：2006/07/23(日) 12:58:22
Judeはいまだに5.0未対応か
1.4系のSystemLAFはぜんぜん似てないからちとな
531 ：デフォルトの名無しさん：2006/08/08(火) 09:03:43
>>528
b94の変更点一覧によると、インストーラの不具合は予定通り修正されたようだな。
532 ：デフォルトの名無しさん：2006/08/09(水) 02:17:11
>>531
いっぺん、アンインストールのときにエラーがでるかもしれんけど
気にせず２回目実行すれば大丈夫だな
533 ：デフォルトの名無しさん：2006/08/09(水) 19:38:40
そーいや、7月に Dolphin プロジェクト始まるとか言ってなかったっけ？
534 ：デフォルトの名無しさん：2006/08/16(水) 16:38:37
>>533
チェックしたら7/21にビルド始まってた
ttp://download.java.net/jdk7/binaries/
ビルドサイクルは、まだ確立されてなさげだけど
535 ：デフォルトの名無しさん：2006/08/16(水) 16:47:24
>>534
追記：
ベースになってるのがb90-b93らしいので
>>528 の回避策を使わないとインストールできませんので。
536 ：デフォルトの名無しさん：2006/08/20(日) 17:29:10
Javaは引数の参照渡しができない
とんでもない駄作
537 ：デフォルトの名無しさん：2006/08/20(日) 17:35:07
536は引数の参照渡しができないとスワップもできない駄プログラマ
538 ：デフォルトの名無しさん：2006/08/20(日) 17:49:09
Javaは参照の値渡しをしているだけだ。
参照そのものは渡せない。だからライブラリが作りやすいのに。
539 ：デフォルトの名無しさん：2006/08/20(日) 19:12:00
> 536
問題なし。

void hoge(int[] a){
　a[0]=a[0] * 2;
}

void main(){
　int[] lap = {2}
　hoge(lap);
　int v = lap[0];
　System.out.println(v);
}
540 ：デフォルトの名無しさん：2006/08/21(月) 14:08:50
C言語風だな。
541 ：デフォルトの名無しさん：2006/08/21(月) 14:59:40
>>539
Arrayでラップか、でもその場合つづりはwrapじゃないか？
542 ：デフォルトの名無しさん：2006/08/21(月) 15:06:53
>>522
STARDUST OFFICIAL SITE
http://www.stardust.co.jp/file/profile/kaho.html

こんな子がでたらそりゃどきどきするわな。
ただし時給1000円だと、こんなかわいい女の子と仲良くなった途端
仕事辞めちゃうもんだなw
543 ：デフォルトの名無しさん：2006/08/21(月) 18:51:32
>>542
こんなかわいい女の子がプログラミングに興味持つのだろうか？
周りを見回すと、数少ない女はみんな…ｒｙ
誰かかわいい女の子がいる職場知ってる？
544 ：デフォルトの名無しさん：2006/08/21(月) 19:04:01
可愛いってのはそれだけで才能だからな。それを活かせるのは
プログラムするところじゃないだろう。本人が好きなら分らんけど、
そうなる可能性は奇跡のように小さいだろうね。
545 ：デフォルトの名無しさん：2006/08/21(月) 22:03:24
peter ahe のブログみてたら クロージャの文法っぽいpdf が落ちてた。
http://blogs.sun.com/roller/resources/ahe/closures.pdf

クロージャ変換というのが提案されてて、
java.lang.Runnable みたいに 1つしかメソッドを持たない interface と
同じシグニチャを持つ クロージャは変換可能になるみたい。
（void() 型のクロージャは Runnable にも変換できるらしい？）

ただこれ、java.uril.concurrent.Executor executor = ...;
execurot.execute( (){ System.out.println("test"); } ); は
コンパイラが暗黙に Runnable の匿名クラス作ればOKっぽいけど

例えば Runnable と似たようなインターフェイス
interface MyInterface{ void method(); } があったときに
void() closure = (){ System.out.println("test");
Runnable r = closure;
MyInterface m = closure;
とかされた時どーすんのかな？ とか思った。

あと、null が正式に型に昇格する事も検討されてるらしい。
null.class とかできるようになるとか？
546 ：デフォルトの名無しさん：2006/08/21(月) 22:30:15
nullがクラスになったらどういう事が出来るようになるの？
547 ：デフォルトの名無しさん：2006/08/21(月) 22:47:37
reflection とか型推論とか通常は値を返さない関数のように動くクロージャに必要って書いてあるけど、
よくわからん。
548 ：デフォルトの名無しさん：2006/08/21(月) 23:04:29
あ、判った。匿名クロージャは引数型は必要だけど戻り値型を書かなくていいらしい。
で匿名クロージャで return 文を書かずに、その匿名クロージャが中途完了する場合
（必ず例外投げる場合とか？）は戻り値型が null になるって事らしい。
正常完了する場合とか、引数無しの return がある場合は戻り値型 が void になるって書いてあった。
549 ：デフォルトの名無しさん：2006/08/21(月) 23:08:15
それって、戻り値が「必ず」nullになるんなら、nullじゃなくてvoidにしたらなんで駄目なんだろうか。
550 ：デフォルトの名無しさん：2006/08/21(月) 23:14:42
戻り値が必ず null になる場合に void にしたら拙いじゃん。

Object closure() ってのがあって、
そのつもりで (){ return null; } って匿名クロージャ書いて
戻り値型を void にされたら適わん。
551 ：デフォルトの名無しさん：2006/08/21(月) 23:16:05
あれ？
nullが型になるってことは、そういう場合は
Null closure()
って書かないといけないってことなのかと思ったんだけど。
552 ：デフォルトの名無しさん：2006/08/21(月) 23:20:07
よーするに、中途完了する匿名クロージャは、
値を返すクロージャと型の互換性が無いと拙いって事では無いかと。

値を返すメソッドを持った interface を書いて、
実際には必ず例外投げる匿名クラスを作りたいとする。
匿名クラスの場合は戻り値型があるから良いけど、
匿名クロージャは明示的に戻り値型を書けないっぽいので。
戻り値型を null にしておけば、どんな戻り値型のクロージャとも
互換性ができるのでは無いかと思う。たぶん。

仮にそーだとすると、null は void の上位クラスって感じになるのかな？
553 ：デフォルトの名無しさん：2006/08/21(月) 23:25:47
void の上位クラスっつーか、null は void と Object の上位クラスって感じか……
554 ：デフォルトの名無しさん：2006/08/21(月) 23:38:53
>>545には、そんな難しい事書いてない。
値nullが存在する限り、値nullには型が必要ってだけ。

closureの文法では陽に書く場合があるので、これを機会に導入。
もともと型推論的には必要だったもの。
555 ：デフォルトの名無しさん：2006/08/22(火) 03:54:04
>>553
その辺はSubtypingのところに書いてあるな。
> A function type T is a subtype of function type U iff all of the following hold:
> ・Either
> 　・The return type of T is either the same as the return type of U or
> 　・Both return types are reference types and the return type of T is a subtype of the return type of
U, or
> 　・the return type of U is void.
（以下、引数型や例外に関しての条件が続く）

以下の条件の全てをみたすなら関数型Tは関数型Uの下位型である。
・以下の何れか
　・Tの戻り型がUの戻り型と同じ
　・二つの戻り型が共に参照型であり、Tの戻り型がUの戻り型の下位型である
　・Uの戻り型がvoidである
（以下、引数型や例外に関しての条件が続く）
556 ：デフォルトの名無しさん：2006/08/22(火) 04:20:12
Referencing names from the enclosing scope のところ見ると、
匿名クラスの時みたいに final 付けろって書いてあるね。
557 ：デフォルトの名無しさん：2006/08/22(火) 12:30:17
>>556
逆、逆。
匿名クラスのように、finalを*付けなくていい*と書いてある

テキトーに訳してみると

>> We do not propose a rule that requires referenced variables be final,
>> as is currently required for anonymous class instances.

現在、匿名クラスのインスタンスに対して要求されているような、参照される
変数がfinalでなければならないという制約は提案しない

>> The constraint on anonymous class instances is also relaxed to allow
>> them to reference any local variable in scope.

また、匿名クラスに対する制約も緩和され、スコープ内のどんなローカル変数も
参照できるようになる
558 ：デフォルトの名無しさん：2006/08/22(火) 12:35:56
>>545

> 例えば Runnable と似たようなインターフェイス
> interface MyInterface{ void method(); } があったときに
> void() closure = (){ System.out.println("test");
> Runnable r = closure;
> MyInterface m = closure;
> とかされた時どーすんのかな？ とか思った。

closureをラップするクラスをそれぞれの代入に対して、自動生成すればいいんでない？
　Runnable r = new Runnable_closure_bridge(closure);
　MyInterface m = new MyInterface_closure_bridge(closure);
みたいな感じで
559 ：デフォルトの名無しさん：2006/08/22(火) 19:35:52
>>557
あ、本当だ。嘘ついてすまん。

このスレの >>12 とかでも話題になってる変数の扱いとか、
どーなるんだろね？ 後は VM に変更なしで実装できるんか？とか。
560 ：デフォルトの名無しさん：2006/08/22(火) 21:36:40
>>559

基本的には、ほとんどの機能はVMに変更なしで、コンパイラのみで
実装できると思う(ただし、クラスファイルフォーマットの変更は必要か？)
ただ、クロージャの中からそれを囲む関数をreturnする機能
(Non-local transferの部分)はVM変更なしでやるのはつらそう
簡単に実装するには、例外を使えばいいだろうけど、それだと性能出ないだろうし
561 ：デフォルトの名無しさん：2006/08/22(火) 21:38:12
>>560
自己レス
> クロージャの中からそれを囲む関数をreturnする機能
クロージャの中からそれを囲む関数の外側へreturnする機能、の間違いだ
562 ：デフォルトの名無しさん：2006/08/22(火) 22:11:08
Non-local transferは、p.5-6に記述がある。
その中でも>>560が心配しているケースはUnmatchedNonlocalTranser例外になる。
563 ：デフォルトの名無しさん：2006/08/23(水) 17:50:22
http://journal.mycom.co.jp/articles/2006/08/23/java7closuer/
Javaにクロージャだって。
564 ：デフォルトの名無しさん：2006/08/23(水) 17:57:58
上を見てみろ
565 ：デフォルトの名無しさん：2006/08/23(水) 18:05:27
('A`)
566 ：デフォルトの名無しさん：2006/08/23(水) 18:49:28
苦労じゃ
567 ：デフォルトの名無しさん：2006/08/23(水) 19:07:55
くだらん
568 ：デフォルトの名無しさん：2006/08/23(水) 19:49:51
で、結局このクロージャ内からローカル変数は参照できるの？
それとも引数渡し？
569 ：デフォルトの名無しさん：2006/08/23(水) 22:18:36
馬も出てないのになぜjdk7の仕様を気にするのか・・
570 ：569：2006/08/23(水) 22:23:10
あ、ごめんここ次世代スレだった
スレ間違った
571 ：デフォルトの名無しさん：2006/08/23(水) 22:29:11
ん？なんでスレ違い？Java6はもうすぐ出るしここでもいいような・・・
572 ：デフォルトの名無しさん：2006/08/24(木) 00:48:51
Java6は、メンテナンスリリース色が高いからな。
今後も、偶数バージョンは小変更、奇数バージョンは大変更という感じになるみたい
573 ：デフォルトの名無しさん：2006/08/24(木) 01:01:50
だが、あいかわらず5.0update8でエンバグとかやらかしてるからなんとも・・・

Java2DのOpenGLがWin環境でもちゃんと動作するようになってるかが見もの
574 ：デフォルトの名無しさん：2006/08/24(木) 17:32:21
Java7でクロージャの導入か。
いまいちクロージャって理解できていないのだが、

「外側のメソッドのローカル変数にfinal がついていなくてもアクセス可能な匿名クラス」

が仮に認められたら、これはクロージャ？
575 ：デフォルトの名無しさん：2006/08/24(木) 20:48:36
>>574
ちょっと違うとおもう。

それよりもマルチスレッド下でローカル変数束縛するとスタック上の実体をコピーで解決するつもりだったらアウトだし
ローカル環境を生かしておくとGCでメモリ断片化激しくなりそうとか厭な考えがよぎっちゃうんだけど、どういう風にするつもりなんだろう？

HotSpotがSelf由来だと考えればなにか考慮されているのだろうけど、関連論文とか乗っかっている書き込みとか見かけた人いる？
576 ：デフォルトの名無しさん：2006/08/24(木) 21:00:11
スコープを変数化するのがクロージャって感じかな。
ECMAScript触ってると特にそう思う。
577 ：デフォルトの名無しさん：2006/08/24(木) 21:03:03
クロージャからのローカル変数のアクセスは暗黙的に排他すんじゃないの？
それよりスレッドにクロージャを渡すような使い方は俺はしたくねーな
578 ：デフォルトの名無しさん：2006/08/24(木) 21:19:25
スタックを保存してヒープにもってくとかそんな感じ？よーわからんなぁ。
スクリプトだとthisの扱いがいつでもmixinって感じで使いにくいから
クロージャ使わないとデリゲートにならないんだよな
579 ：デフォルトの名無しさん：2006/08/24(木) 21:52:28
文書読んでみたが、並行性については特に何もやる気ないみたいだね
必要なら今まで同様プログラマが対処しろって感じ
580 ：デフォルトの名無しさん：2006/08/24(木) 22:47:06
Java in the BoxさんとこにJava 6では
「Server VM と Client VM の動的な変更」がサポートされるとあるんだけど
これってSwingとかで文字列置換メソッドは
Server VMでJITコンパイルできるとかそんなん？
581 ：デフォルトの名無しさん：2006/08/24(木) 23:46:44
クロージャはifやforの{}が引数と戻り値持った感じだと思う

>>577
Rubyやってると割と普通な気がするんだが、どの辺がいやなの？
582 ：デフォルトの名無しさん：2006/08/25(金) 00:13:18
匿名クラスでコンストラクタ定義できればそれだけでいいんだけどな。
583 ：デフォルトの名無しさん：2006/08/25(金) 00:23:38
そんなことより、Genericsの仕様、
さらなる変化は無いのか？

パラメタライズドクラスを作るのが大変なんだが。
タイプセーフなため、配列と違って、List<Integer>はList<Number>のサブクラスにはできんし。
<>の中にさらに<>を入れ子に書いてとクラス設計が難しい。
パラメタライズされたクラスの継承でのパラメータの扱いといい、
慣れるのが大変。




584 ：デフォルトの名無しさん：2006/08/25(金) 01:32:15
解ってないんだけど、ローカル変数ってもともとスレッド毎でしょ？
マルチスレッドで、何の問題があるの？
スコープ抜けたときにスタックからヒープにコピーすればいいだけじゃん？
585 ：デフォルトの名無しさん：2006/08/25(金) 03:48:23
クロージャってC++にも追加されるんでしょ？
流行ってるね
586 ：デフォルトの名無しさん：2006/08/25(金) 06:38:13
>>584
そのスレッドで、Runnableなオブジェクトを作って
クロージャを引き渡したらどうなると思う？
そういうこと。

また、今のListener系のような使い方をした場合、
マルチスレッドになるのは目に見えてる。
ただ、先の文書ではそこらへんは保証しないみたい。
主張を読むと、そういう場合は、今まで通り匿名クラスを使うか、
Javaで既に用意されてる並行性の仕組みを使えってこと。
なぜなら、そんなのを必要としない大多数の開発者には
パフォーマンスが落ちるだけで有り難迷惑だから。
587 ：デフォルトの名無しさん：2006/08/25(金) 06:47:06
>>583
つワイルドカード

　List<Integer> ints = new ArrayList<Integer>();
　...
　List<? extends Number> nums = ints; //OK
588 ：デフォルトの名無しさん：2006/08/25(金) 10:19:17
>>587
List<T extends Number> nums = ints;
はだめなのか
589 ：デフォルトの名無しさん：2006/08/25(金) 10:25:11
>>588

public <T> void aMethod() {
List<T extends Number> nums;
//
}
とかならTが型パラメータと分かるので可能だが、そうでなく唐突に
Tが出ても未定義シンボルになる。
590 ：デフォルトの名無しさん：2006/08/25(金) 10:26:20
と思ったら出来なかったorz
591 ：デフォルトの名無しさん：2006/08/25(金) 10:45:45
>>582
いや、普通にできるが。
592 ：デフォルトの名無しさん：2006/08/25(金) 21:40:02
インスタンスイニシャライザではダメなんですたぶん
593 ：デフォルトの名無しさん：2006/08/25(金) 21:52:34
>>589
うーむ。Tの定義ってメソッドの頭かクラス宣言の後だったんだね。
継承使うとき、どうりで変だと思った

class A<T> implements SuperA {}
という表記はうまくいっても
class A implements SuperA<T> {}
はうまくいかず未定義といわれる。

当然、
class A implements SuperA<T extends Number> {
は怒られる

class A implements SuperA<?> {

も怒られる。
594 ：デフォルトの名無しさん：2006/08/25(金) 23:08:22
変なのはおまいの頭だと思うよ…
595 ：デフォルトの名無しさん：2006/08/25(金) 23:21:55
いきなりむかつくこといいやがったなおめえ。

確かにgenericsにはまだまだ慣れていないが、

情報が少なすぎていつもGenericsで悪戦苦闘して
こっちは大変なんだよ。

しかし、Genericsでパラメタライズされたクラスを
作ってる奴は少ないんだな。

2chでも稀なほうか。

C++Templateとは似てるようで違うためか、
使いこなせない奴も多いもんだな。
596 ：デフォルトの名無しさん：2006/08/25(金) 23:34:05
>>595
情報とか言う以前に仕様書を読めよ。
あと
class A implements SuperA<T> {}
なんか A を使うときにどうやって T が型パラメタか
普通のクラスか見分けるんだよ。少なくとも
class A<T> implements SuperA<T> {}
とやらないとパラメタ指定できないだろ。
597 ：しろうと：2006/08/25(金) 23:59:55
ちょっと質問なんですが、クロージャが実現できると、何がウレシイのでしょうか？

実行時評価するわけじゃなくて匿名インナークラスのSyntaxSugar＋α程度のもの
でしかないのなら、別にどっちでもいいんじゃねえのとおもうんだが。

ここのところ、大々的に言語仕様かえるといっといて、結局やってることは
プリコンパイラにどっちでもいいだろという機能を追加してる程度のケース
が多いようなのだけど、どういう圧力からそういう結論になるのでしょうか。

後方互換を保つために妙な妥協して、あるべき論と掛け離れた中途半端な仕様
を差し込むくらいなら、何もしないほうがいいと思うのは私だけデスカ？

598 ：しろうと：2006/08/26(土) 00:09:24
>>595
別に無理に使わなくても、ちょっと頑張れば同じことができてたから
じゃないの。

おいらの場合、コードがコンパイラ依存になるのが嫌なので、当分セ
コセコデリゲートクラスとか自作して頑張ってくつもりです。
599 ：デフォルトの名無しさん：2006/08/26(土) 00:15:01
関数型のメリットは多いよ
・delegateの実装が楽（クロージャ）
・スクリプトフレームワークの拡張がしやすくなる
・継承では補いきれない差分プログラミングが可能（保守性向上）
600 ：デフォルトの名無しさん：2006/08/26(土) 00:17:08
>>597
> どういう圧力からそういう結論になるのでしょうか

VMにでかい機能を追加すると遅くなるだろ。
しかしGenericsの仕様はいくらなんでもあれだが。
601 ：デフォルトの名無しさん：2006/08/26(土) 00:20:42
>>598
Javaは私企業のプロダクトだから結局C#対抗な訳よ
マイクロソフトに負けたくないっていうSunの言語ｵﾀの意地とｵﾅﾆｰ
602 ：デフォルトの名無しさん：2006/08/26(土) 00:22:15
.classみたいな感じで.methodってできるようになったら良くない？
ってとっくに議論され、破棄されたんだろうが。。。

いまでもリフレクションでできるけど面倒なんだよね。
メソッドにアノテーションつけた時に参照するのも
obj.getClass().getMethod("method1").getAnnotation(anno);
とかだぜ。タイプセーフの意味がない。
これが
method1.method.getAnnotation(anno);
となりすっきり。。。
603 ：しろうと：2006/08/26(土) 00:24:17
>>601
Javaもめでたくオプソになるらしいし、そのうちC#コンパイラとか
出るんでねえのかなとか思う毎日。…って、APIのサポートがむずいかな。
604 ：デフォルトの名無しさん：2006/08/26(土) 00:26:39
ECMA標準のC#なら余裕だろ
SUNもJava VMを.NET化させるつもりだし
605 ：デフォルトの名無しさん：2006/08/26(土) 00:29:14
Sunっていつも後手後手だよね
606 ：デフォルトの名無しさん：2006/08/26(土) 00:30:09
夏休みもそろそろ終わりなのになぁ。。。
607 ：デフォルトの名無しさん：2006/08/26(土) 00:32:42
>>605　？？？

夏だな
608 ：デフォルトの名無しさん：2006/08/26(土) 00:36:37
もうJavaもおわりだなと感じる今日この頃
609 ：デフォルトの名無しさん：2006/08/26(土) 00:37:49
JavaOneの聴講者数は年々増加の一途なのだが
610 ：デフォルトの名無しさん：2006/08/26(土) 00:38:56
>>608
そう思われる様になってからが華
611 ：デフォルトの名無しさん：2006/08/26(土) 00:40:26
>>609
それに比例して、馬鹿がますます増えてきたな。
612 ：デフォルトの名無しさん：2006/08/26(土) 00:41:08
Java人口の増加と先進性は反比例
613 ：デフォルトの名無しさん：2006/08/26(土) 00:42:48
>>602
Hoge.classがClass.forName("Hoge")の言語糖衣だと知った時はショックでした。
614 ：デフォルトの名無しさん：2006/08/26(土) 00:47:55
>>597の感想はもっともだよな
後方互換を気にしながらC#の後追いしてるくらいなら
新たな言語環境を提案してくれないかな
もっともSunにもIBMにも無理そうだな
615 ：デフォルトの名無しさん：2006/08/26(土) 00:49:30
>>613
ちがくないか？
Class<Hoge> c = Hoge.class;
と
Class<?> c = Class.forName("Hoge");
でしょ？オレが間違って覚えてるのか。。。？
616 ：デフォルトの名無しさん：2006/08/26(土) 00:49:58
> 新たな言語環境を提案してくれないかな
100%ぽしゃるから。今の時代はライブラリ＞言語仕様
617 ：デフォルトの名無しさん：2006/08/26(土) 00:58:11
>>615
日本語は間違って覚えてるね。
618 ：デフォルトの名無しさん：2006/08/26(土) 01:00:31
>>615
でそのGenericsも糖衣な訳だが
619 ：デフォルトの名無しさん：2006/08/26(土) 01:02:44
Javaの欠点はGUIライブラリの貧弱さ
620 ：デフォルトの名無しさん：2006/08/26(土) 01:04:00
>>619
Swingの実装感は.NETのライブラリとたいして変わらんと思うが。

問題は性能なのか？
621 ：デフォルトの名無しさん：2006/08/26(土) 01:06:06
>>618
そういえばそうか
でも.classリテラルはforName()とは使用場面が異なると思うんだが
それでも糖衣っていうのか。
622 ：デフォルトの名無しさん：2006/08/26(土) 01:08:42
>>621
Hoge.classはコンパイラ通すとClass.forName("Hoge")に
コンパイルされるってこったよ。
623 ：デフォルトの名無しさん：2006/08/26(土) 01:11:59
>>620
クライアントアプリを作るにはまだまだ
たとえるならXToolkitレベル
標準のFontChooserとかGridControllerとかなんで出てこないんだろ
624 ：デフォルトの名無しさん：2006/08/26(土) 01:13:48
>>623
目指すはVBなわけですな…かくてまた馬鹿が増えるのかorz
625 ：デフォルトの名無しさん：2006/08/26(土) 01:15:39
バッドノウハウとグッドラッパーの話だなこりゃ
626 ：デフォルトの名無しさん：2006/08/26(土) 01:19:50
目指すはVBてか、GUIはある程度統一されるべきな訳よ
GnomeやKDEのようにね
あるアプリで選択した色やフォントは、別なアプリでも使いたい
そのためにはJavaももうVMだけじゃなくて
バックグランドで常駐するサービスレイヤーが必要だと思うのね
627 ：デフォルトの名無しさん：2006/08/26(土) 01:21:54
>>626
>バックグランドで常駐するサービスレイヤー
Java6ってそれじゃなかったっけ。
628 ：デフォルトの名無しさん：2006/08/26(土) 01:22:08
>>622
syntax sugar ではあるが Class.forName("Hoge") にコンパイルされるわけではない。

>>623
Swing って SWT/JFace の対応で言う SWT の方 (基本機能) であって
高機能なコンポーネントは自作するorどっかからライブラリを探してくるor買う
もんだと思うんだが。
629 ：デフォルトの名無しさん：2006/08/26(土) 01:22:19
ブラウザがAPIいっぱつでデフォルトをぽんって出すから
そのうちメーラーとかコンパネとかフォントダイアログとか
そういうのもネイティブで出るんじゃないか
630 ：デフォルトの名無しさん：2006/08/26(土) 01:22:22
>>622
しつこいようだが、なんでジェネリックスだけ違うのかわからん。
Class<Hoge> c = Class.forName("Hoge");
がコンパイルしないのは何故？.classだとokなのに。
eraserとかってやつ関係かな？
631 ：デフォルトの名無しさん：2006/08/26(土) 01:26:57
>>623
それだといつまでたっても統一環境ができない
アプリは自作でいいが、サービス層はもっと充実させるべき
632 ：デフォルトの名無しさん：2006/08/26(土) 01:29:16
>>630
そういう場合こんな感じじゃなかったっけ
Class<Hoge> c = Class.<Hoge>forName("Hoge");
633 ：デフォルトの名無しさん：2006/08/26(土) 01:31:05
>>629
ブラウザが基盤だという発想には違和感感じっぱなしの私。
あれは明らかにアプリでしょうに…
634 ：デフォルトの名無しさん：2006/08/26(土) 01:33:30
>>632
よくわかんないけど
forName使う意味なくない？
forNameはコンパイル時にはclassが見えない時につかうんじゃね？
Hogeが手元に無い時とかさ。
635 ：デフォルトの名無しさん：2006/08/26(土) 01:37:21
>>634
そこは一応名前と実際のクラスは別もんということで、、、
クラスローダによってはほんとに別にできると思うけど
636 ：このネタ書いた人：2006/08/26(土) 01:48:59
正直どうでもいいんだけど

Class hoge = Hoge.class

を含むクラスをSunJDKのjavacでコンパイルして、javap -c してみると、

invokestatic Method java/lang/Class.forName:(Ljava/lang/String;)Ljava/lang/Class;

になるわけなんだが、俺なんか勘違いしてる？
637 ：デフォルトの名無しさん：2006/08/26(土) 02:03:04
まあGUIについてはJavaは約20年遅れてる
ってことでおやすみ
638 ：デフォルトの名無しさん：2006/08/26(土) 02:06:03
>>636
バージョンは？
確かにどーでもよいが。
639 ：デフォルトの名無しさん：2006/08/26(土) 02:08:48
>>638
手元のJDKは1.4.2_10。5.0は持ってないのでどうなるかシラン。
640 ：デフォルトの名無しさん：2006/08/26(土) 02:12:02
>>639
1.4までは.classは.forNameと同等
1.5からは扱いが変わったってことかな？
なんでかえる必要があったのか、というのは考えない事にします。
641 ：デフォルトの名無しさん：2006/08/26(土) 02:35:30
どうでもいいことだが、
1.5 からはクラスリテラルではクラスが初期化されない。
642 ：デフォルトの名無しさん：2006/08/26(土) 03:13:55
>>599
自分も、スクリプトフレームワーク側からの要請が
結構でかいんじゃないかと思う。
.NETなIronPythonは結構速いみたいだし、JythonとRhinoも速くなって欲しいな。
643 ：デフォルトの名無しさん：2006/08/26(土) 03:19:24
>>601
というけど、C#のようにはならんと思う。
C#とくらべかなりTypesafeだと思われ。

それだけにGenericsではパラメタライズされたクラスを
実装するのが難しいが。そのかわりタイプセーフが保証されるので
パラメタライズドクラスを便利に、かつ安心して使うことができる。

マイクロソフトに負けたくないってのとはちょっと違う。
っていうかJavaはもうSun私企業のプロダクトじゃなくなってるよ
Java Community ProcessによってだれでもJavaの変更について参加できる。
実際に変更するかどうかはゴスリングあたりが決めるが。
それも、JavaがC++の二の舞にならないようにするためさ。
644 ：デフォルトの名無しさん：2006/08/26(土) 03:20:37
>>604
> ECMA標準のC#なら余裕だろ
> SUNもJava VMを.NET化させるつもりだし

それは初耳。ソースはどこにある？
.NET化というのは.NETと共用するの間違いではないかと予想する。
645 ：デフォルトの名無しさん：2006/08/26(土) 03:21:39
>>614
？　ゴスリングが新しい言語を作りたいとかいってなかったけか？
646 ：デフォルトの名無しさん：2006/08/26(土) 03:23:52
>>611
JavaOne聴講者に馬鹿が増えたと？
去年JavaOneTokyo2005に行ったときはそうでもなかったが。

綺麗な設備に恵まれた東京国際フォーラムを全部貸し切って、
金のかかったイベントだなって気がしたけど。
647 ：デフォルトの名無しさん：2006/08/26(土) 03:24:08
>>612
夏っぽい発言だね
648 ：デフォルトの名無しさん：2006/08/26(土) 03:25:30
>>620
>>619は古い時代のSwingのことを言ってるだけかもしれないよ。
649 ：デフォルトの名無しさん：2006/08/26(土) 03:27:08
>>624
ちょっと違うな。
Java Studio CreatorがVB屋向けっていうけど
あれはなんだか、Dreamweaverに似てる。
デザイナにJavaを憶えさせたいという無謀な考えがSunに
あったのだろうか。

それでもCreatorの完成度は高いけどね。
しかしメモリ食うしかなり重たい・・・
650 ：デフォルトの名無しさん：2006/08/26(土) 06:47:46
なんか開発環境と実行環境がごっちゃになってる香具師がいるようだが？
651 ：デフォルトの名無しさん：2006/08/26(土) 06:49:35
>>648
では聞くけど新しい時代のSwingって何？
652 ：デフォルトの名無しさん：2006/08/26(土) 11:25:56
>>651
Java5とかJava6のSwingじゃね？
もしかしたらJava1.4.2かも知れんが。
少なくともJava1.2やJava1.3のSwingでないことは確か。
653 ：デフォルトの名無しさん：2006/08/26(土) 12:53:54
Java SE 6 は、SwingにもJOGLの3Dレンダリングが使えるようになるんだろ。
654 ：デフォルトの名無しさん：2006/08/26(土) 13:48:54
>>653
それっていいの？
何がどう変わるのさ
655 ：デフォルトの名無しさん：2006/08/26(土) 13:55:21
今までは3Dを使う場合はAWTにする必要があった。
そのためSwingで使う場合AWTで作られたリソースをバイト配列にして再構築していた。
あとLinuxとかならSwingは高速化するんと違うかな
656 ：デフォルトの名無しさん：2006/08/26(土) 22:39:37
>>650
にしても、VBなんて開発環境と言語がわんせっとになった言語だよな
657 ：デフォルトの名無しさん：2006/08/26(土) 22:41:07
>>651
タスクトレイが追加されたりタブのスクロールや移動ができて
かつSWTよりも高速になった時代のSwingだよ。
C++で作られたGUIと比べてもパフォーマンスのほうは大差なくなってきたって事だね
658 ：デフォルトの名無しさん：2006/08/27(日) 02:14:20
>>614
別に後追いばかりってわけじゃないぞ
プリミティブ型のboxing/unboxing、拡張for文、アノテーションあたりは後追い感が強いが
Genericsの仕様はC#のGenericsの仕様が決定するだいぶ前から検討されてたし、
今回の関数型およびクロージャの仕様はC#のデリゲートに比べるとかなり良い仕様に
なっていると思う
659 ：デフォルトの名無しさん：2006/08/27(日) 02:17:15
Java 7のはっちゃけぶりを見るとJVMを残してJavaを捨てる気まんまんだな
660 ：デフォルトの名無しさん：2006/08/27(日) 12:41:57
>>658
後追いといっても、C#とは仕様が異なる感じだな。
アノテーションもboxingも。

後追いのようになってしまったのは、
Java Community ProcessでC#のことをよく知ってる人が
Javaにもこういう機能つけてくれよって提案したからじゃないかな。
661 ：デフォルトの名無しさん：2006/08/27(日) 12:42:38
>>659
Javaの何をすてるんかな。

JVMがどう進化するのか楽しみではあるが
662 ：デフォルトの名無しさん：2006/08/27(日) 13:45:50
>>661
Javaの構文だけを整理したものが残ると思う
663 ：デフォルトの名無しさん：2006/08/27(日) 14:43:35
>>662
何がいいたいのかよくわからないが、
構文を整理したものって一体どういうものを想像している？

気になるので挙げてみておくれ
664 ：デフォルトの名無しさん：2006/08/27(日) 14:57:22
getter, setterとか、addListenerのデリゲート化とか。
あとはjava.ioとjava.nioの関係みたいに
互換性のために統合を避けた部分も整理して欲しいし
StackとかPropertiesみたいに設計に失敗した部分も直す。
Javaの資産はD言語みたいに別言語構文を解釈する制御を入れればいい。
665 ：デフォルトの名無しさん：2006/08/27(日) 16:54:38
それより何より、配列まわりの型の腐りっぷりをさっさとどうにかして欲しい。
666 ：デフォルトの名無しさん：2006/08/27(日) 17:01:18
>>664
> getter, setterとか、addListenerのデリゲート化とか。

たまにJavaスレに紛れ込むドトネト厨だかVB厨かよ。
getter,setterはどうでもいい。その程度ならdelegate化もどうでもいい。
どうせクロージャが追加されるならなおさらどうでもいい。

> あとはjava.ioとjava.nioの関係みたいに
> 互換性のために統合を避けた部分も整理して欲しいし

認識が甘い。そんなとこを統合してどうする。
それとも、整理する必要がどこにあるのか具体的に説明できるか？

> StackとかPropertiesみたいに設計に失敗した部分も直す。
初心者Java質問スレ見てた奴だな？
どう見直すというのか。放置か@Depricatedでいいだろ。


> Javaの資産はD言語みたいに別言語構文を解釈する制御を入れればいい。
Java6ではスクリプト言語を解釈するAPIがあるぞ。
667 ：デフォルトの名無しさん：2006/08/27(日) 17:02:20
>>665
それも、Collectionがあれはどうでもいい。
多次元ジャグ配列なんて滅多に使わないし。
無闇に使う奴は設計能力センスが甘いやつだね。


668 ：デフォルトの名無しさん：2006/08/27(日) 17:07:32
>>666
> getter,setterはどうでもいい。その程度ならdelegate化もどうでもいい。
おまえの主観だろ？多言語出身者は口をそろえて汚い仕様という

> それとも、整理する必要がどこにあるのか具体的に説明できるか？
現状でBufferを使いこなせる技術者は極端に少ない。
ファイルマップすら知らない奴ばっか。

> どう見直すというのか。放置か@Depricatedでいいだろ。
depricatedなクラスがシステムローダにロードされる時点でおかしい

> Java6ではスクリプト言語を解釈するAPIがあるぞ。
根本的な部分でアイタタタ
669 ：デフォルトの名無しさん：2006/08/27(日) 17:11:29
>>668
> 現状でBufferを使いこなせる技術者は極端に少ない。
他は言語環境の改善要求っぽいのに、これは完全な愚痴だな。
670 ：デフォルトの名無しさん：2006/08/27(日) 17:12:55
あちこちでdeprecated のスペル間違えているやつがいるな。
同一人物か
671 ：デフォルトの名無しさん：2006/08/27(日) 17:15:20
>>669
コンセプト違いの重複した機能があちこちにある時点で要改善だろ
672 ：デフォルトの名無しさん：2006/08/27(日) 17:15:54
>>668
> >>666
> > getter,setterはどうでもいい。その程度ならdelegate化もどうでもいい。
> おまえの主観だろ？多言語出身者は口をそろえて汚い仕様という
他言語出身者って、どうせC#やVB, Delphi言語出身者かドトネト厨である
おめえの主観だろw 綺麗な仕様とやらはC#やDelphiのget/set程度の仕様かw
あの程度で綺麗なら、演算子オーバーローディングやunsafeでソースコードが汚くなるのを
どうにかしようとは思わないのか。

> > それとも、整理する必要がどこにあるのか具体的に説明できるか？
> 現状でBufferを使いこなせる技術者は極端に少ない。
> ファイルマップすら知らない奴ばっか。

Bufferはまた別の話だろ。Bufferを使いこなせる奴が少ないのと
配列の型がどうだこうだと一体どう関係があるのか。
Bufferが何のためにあるのかわかって言ってるのか？

> > どう見直すというのか。放置か@Depricatedでいいだろ。
> depricatedなクラスがシステムローダにロードされる時点でおかしい

なにがどうおかしく、どう不具合が出るのか説明できるか？

> > Java6ではスクリプト言語を解釈するAPIがあるぞ。
> 根本的な部分でアイタタタ

お前が痛い。
673 ：デフォルトの名無しさん：2006/08/27(日) 17:16:29
>>670
レス元コピって使っただけだ。単語をひらで書けないのは確かだがｗ
674 ：デフォルトの名無しさん：2006/08/27(日) 17:16:37
>>671
> >>669
> コンセプト違いの重複した機能があちこちにある
たとえばどのあたりが？
675 ：デフォルトの名無しさん：2006/08/27(日) 17:17:58
>>672
お前が.NET中心でしかものを考えられないことは良く分かった。
そのほかの点についてもお前が無知なだけ。調べろ。
676 ：デフォルトの名無しさん：2006/08/27(日) 17:24:23
desktopアプリではflash player >>> JREなのになんでJREはあんなに巨大でなければいけないのか
Java DEとか駄目？1Mくらいのサイズ希望
677 ：デフォルトの名無しさん：2006/08/27(日) 17:29:46
flash って desktopアプリ？ webアプリじゃなくて？
678 ：デフォルトの名無しさん：2006/08/27(日) 17:38:38
>>675
でた厨房にありがちな最後の負け惜しみ逃げ台詞
679 ：デフォルトの名無しさん：2006/08/27(日) 17:40:36
>>678そのものがそれなんだけどなｗ
680 ：デフォルトの名無しさん：2006/08/27(日) 17:43:12
はいはいドトネト厨乙
681 ：デフォルトの名無しさん：2006/08/27(日) 17:44:34
説明の説明の説明を求められなきゃ分からん位の素人にJavaを擁護されてもな
682 ：デフォルトの名無しさん：2006/08/27(日) 17:50:48
意味が分からんよそこ
683 ：デフォルトの名無しさん：2006/08/27(日) 19:26:02
>>677
ブラウザーなくても動くし、おおよそのことはできると思うんだけど。
描画は早いし、ビデオやオーディオも強い
ソケットも使えるから、やろうと思えばDBにも直接接続できなくもない。

Java3dみたいのはないが。。。まだ。
684 ：デフォルトの名無しさん：2006/08/27(日) 21:46:29
自分の理解が足りないことを棚に上げて.NET厨扱いかよｗ
685 ：デフォルトの名無しさん：2006/08/27(日) 22:00:09
どどんとねっとじゃんぬねっと
686 ：デフォルトの名無しさん：2006/08/27(日) 22:09:04
ここはゲイツが悪いということで収めてくれ
687 ：デフォルトの名無しさん：2006/08/27(日) 23:58:56
できればスティーブ・バルマーにしてくれないか？
688 ：デフォルトの名無しさん：2006/08/28(月) 00:11:17
>>683
FlashはAS3で化けたが、描画が早いとかそんなことはない
Javaのほうがはるかに早い
機能が段違いすぎ

少なくともFlashでは単純なものしかロジックは書く気にはならないだろ
689 ：デフォルトの名無しさん：2006/08/28(月) 00:11:20
もう、ゲイツには力は無いよ。

そしてマイクロソフトもGoogleに推されている。

いつかマイクロソフトがGoogleの力によって陥落するのも時間の問題。
690 ：デフォルトの名無しさん：2006/08/28(月) 00:32:22
力がなくなろうがなにしようが悪いのがゲイツ
691 ：デフォルトの名無しさん：2006/08/28(月) 01:50:37
ウィリアムさまの悪口を言うなんて
なんて罰当たりな！w

692 ：デフォルトの名無しさん：2006/08/28(月) 02:57:40
何でいきなりクソスレ化するんだよ
693 ：デフォルトの名無しさん：2006/08/28(月) 04:12:03
必要な機能なら誰かが外部ライブラリで作ってくれるさ
本当に標準に必要なのは何かもうすぐコアライブラリのシュリンクが
入ってもいいんじゃないかと思う
SEが肥大化しすぎていると感じる今日この頃

Jakartaでいいじゃん、っていう機能がコアに
取り込まれてる気がしてなぁ・・・・
まぁ使う側からいえば、ライブラリ追加しなくて楽なんだが
それよりむしろ外部ライブラリを簡単に利用できる
仕組みの方が欲しいかな、JWSのライブラリ取得の仕組みを
もっと積極的に活用してもいいような気がする
694 ：デフォルトの名無しさん：2006/08/28(月) 05:31:07
言語仕様で縛って遅くする＋ライブラリを肥大化させて互換環境を作りにくくする、
ってのがお日様の戦略なんだろ
695 ：デフォルトの名無しさん：2006/08/28(月) 08:57:30
特定の言語が腐ってるとかAPIが腐ってるとか言う奴がよくいるが、
お前が言うところのその程度の腐れが、仕事上でダメージを与えるシーンが
あったのか？そういうことが影響を与えるほど、センシティブな職場で働い
てみたいよｗ

今まで困ったことの例:
・馬鹿なプログラマが意図不明な長大コードを混入させ、そこにバグが
　あったため解析と修正を任された…
・頭の悪い上司から仕様不明目的不明ｲﾐﾌﾒｲの処理の実装を指示された…
・自社の自称エリート技術者ドモが、利用者側の要求と全く合致しない
　フレームワークの利用を押し付けてきた…
・どこぞの営業が経歴詐称して素人をプロジェクトに押し込んできた…

問題は全部、人依存でした…orz
696 ：デフォルトの名無しさん：2006/08/28(月) 09:14:54
問題は人なんだとしたら、Javaだと開発効率が良くバグも少ないというのは妄想。
697 ：デフォルトの名無しさん：2006/08/28(月) 10:11:18
>>694
そこまで斜めに見なくてもいいんじゃない？
じゃ、ばっさり互換性切り捨てるのがいいってわけでもないと思うが
バージョン変わったら名前は同じだが、まったく違う言語になるよりいいかと。。。
698 ：デフォルトの名無しさん：2006/08/28(月) 13:05:21
>>697
何でもかんでもコアに入れたがるのは、
俺たちにコントロールさせろ、って宣言だ。

SWT見たいな外圧がないと、
まともな高速化をしようともしないくせに、
ベンチマークのでっち上げだけはうまいんだから。
699 ：デフォルトの名無しさん：2006/08/28(月) 14:13:15
次世代のDesktop javaに必要なのは、SWT並みのLAFと、
Swing並みのプログラムしやすさを持ったツールキット。
Windows FormsをJavaから使えるようにできんもんか。
700 ：デフォルトの名無しさん：2006/08/28(月) 18:47:54
>>691
ゲイツはウィリアムテルでもなければ
フランスからイギリスを征服したウィリアム獅子親王でもリチャード王の十字軍でもない。
701 ：デフォルトの名無しさん：2006/08/28(月) 18:48:39
>>694
そりゃお前の脳内で描かれた陳腐な戦略。
702 ：デフォルトの名無しさん：2006/08/28(月) 18:49:34
>>698
でっちあげ？たとえばどんなふうに？
703 ：デフォルトの名無しさん：2006/08/28(月) 18:50:54
>>699
やっぱりJavaスレにたまに現れるドトネト忠だ。

っていうか、逆にドトネト関連スレにもこういう
イチャモンつけてくるアホって
湧いてこないよね。

まるでドトネト忠は日本にイチャモンつける韓国人や中国人みたいだ。
704 ：デフォルトの名無しさん：2006/08/28(月) 20:42:36
>>703
お前はたから見ててひたすら痛いんだけど気づかない？
705 ：デフォルトの名無しさん：2006/08/28(月) 22:03:46
誰でもどっぷり浸かると周りが見えなくなるということなのかなぁ
706 ：デフォルトの名無しさん：2006/08/28(月) 22:54:35
>>704
イタイのはお前だよドトネト忠w
707 ：デフォルトの名無しさん：2006/08/28(月) 23:00:30
救いようが無いなｗ
708 ：デフォルトの名無しさん：2006/08/28(月) 23:02:04
>>688
デスクトップでGUI以外そんなにロジックを組む事もないんじゃないか？
逆にswingでこったGUIを作る気になるか？（例えばOS Xのexposeとか）
swingはHTMLのFormの代わりくらいが限度じゃないか？

速度ではアニメーションや透明度を使う場合、圧倒的にFlash > swingだとおもうけど。
いつか実証してみよう。
709 ：デフォルトの名無しさん：2006/08/28(月) 23:32:37
同じ穴の狢(むじな)
710 ：デフォルトの名無しさん：2006/08/29(火) 00:13:52
「〜だと思う」で勝手な持論を展開する人は、何処にでもいるもんだな
711 ：708：2006/08/29(火) 00:48:08
でもあれだ、eclipseとかは到底無理だなflashじゃ。
iTunesくらいだったらflashでもいけるかな。
712 ：デフォルトの名無しさん：2006/08/29(火) 01:02:30
Javaじゃ60fpsは無理だしな。16.6秒の世界でsleepの分解能が15msて。
713 ：デフォルトの名無しさん：2006/08/29(火) 01:04:13
>>712
sleepなんてものつかうなよ
714 ：デフォルトの名無しさん：2006/08/29(火) 01:48:30
>>702
どっかのスレで散々議論されてたんじゃないか。
・JITが効果的に利くオブジェクトをほとんど生成しない
ベンチマークでC/C++と同等のパフォーマンスであると主張。
・Java[Runtime]は低レベルのアクセスしまくりでパフォーマンスを改善。
・上記２つをもって、Java[言語]で書かれたコードはC/C++と同等の
パフォーマンスであると主張。
それを信じて（？）Pure Javaでがりがり書かれたEJBのパフォーマンスときたら
715 ：デフォルトの名無しさん：2006/08/29(火) 02:48:24
しかしEJBのパフォーマンス問題はJavaだからというよりも
シリアライズが噛むからではあるまいか？
716 ：903：2006/08/29(火) 03:00:52
>>713
何を使えと？
717 ：デフォルトの名無しさん：2006/08/29(火) 03:19:40
>>716
PC は知らないが少なくともケータイだと一番分解能があるのは Object#wait だよ
718 ：デフォルトの名無しさん：2006/08/29(火) 03:56:43
>>714
話途中から変わってない?

JDKのパッケージングの問題(>>698)が、
JavaコンパイラのSunの自慢話に変わって、
そのSunの自慢を原因としてEJBの実装を叩いている。

でっちあげじゃなくて、JavaがC/C++より速い領域は結構あるよ。
719 ：デフォルトの名無しさん：2006/08/29(火) 09:14:24
>>714
言っていることが意味不明

> ・JITが効果的に利くオブジェクトをほとんど生成しない
> ベンチマークでC/C++と同等のパフォーマンスであると主張。

JITが効果的に効くオブジェクトをほとんど生成しないなら、
パフォーマンスはむしろ劣化するはずだが、それをもってベンチマーク
でC/C++と同等のパフォーマンスであるとは、どういうこと？

> ・Java[Runtime]は低レベルのアクセスしまくりでパフォーマンスを改善

何の話？ネットワーク、IO、GUIなどの箇所は、確かにネイティブコード(C言語)で書いてあるが、
それ以外のライブラリはほとんどPure Javaのはずだが。あと、そもそも低レベルアクセス
(OSのAPIを直接叩くことか？)すれば、パフォーマンスが改善するってもん
でもない。何故ならJavaからネイティブコードを呼び出すのは、かなりのオーバーヘッドが
かかるから。
720 ：デフォルトの名無しさん：2006/08/29(火) 09:33:01
>>718
> でっちあげじゃなくて、JavaがC/C++より速い領域は結構あるよ。
具体例をどうぞ。

Javaの方がパフォーマンスがいいなんて妄想もいいところ。
JVMがCでできてるんだから、CでJVM（もしくはサブセット）を実装して
その上で実行すればJavaより遅くなるわけが無い。
721 ：デフォルトの名無しさん：2006/08/29(火) 10:02:10
>>720
ハハハ・・・・
722 ：デフォルトの名無しさん：2006/08/29(火) 10:29:00
>>716
Timer関係＋wait関係でおけ
ポーリングしたいのならナノ秒取得するやつ使え

Winだとちゃんと高精度タイマで実装されているぞ
Linuxだとミリ秒の1000*1000倍が返されてたきがした
このへんの制度はVM依存だが、まったく動かないわけではないのでおけ

アクションゲーム関係で60fpsだしたいのなら垂直同期使うわけだし問題なし
723 ：デフォルトの名無しさん：2006/08/29(火) 10:56:44
>>710
アメリカにいけば著名人ですらそうだぞ。

I thinkI thinkI thinkI thinkI thinkI thinkI think


　ア　イ　シ　ン　ク　ッ　　！




だ。

論文でもそうだ。さもないと他人の意見をパクった韓国人や中国人
と同等に扱われる。
724 ：デフォルトの名無しさん：2006/08/29(火) 11:00:47
>>723
猿真似は日本人のお家芸。
725 ：デフォルトの名無しさん：2006/08/29(火) 11:02:47
>>711
Flashは4まではJavaのほうが圧倒的に早かった。
今はしらない。

Javaと違い、Flashでできることは限られている。
あれは時系列で開発してゆくからな。
Javaとは畑も開発スタイルも違う。
Flashは簡単なアニメーションなら高速で処理できる。
だが、三角関数や対数関数、指数関数などを徹底的に
駆使した幾何学模様の描画はどうだろう。
是非とも検証してみてくれ。

ActionScriptを使ってちゃんと三角関数などを使って計算してな。
726 ：デフォルトの名無しさん：2006/08/29(火) 11:05:35
>>714
そのEJBのバージョン、
それからプログラムのソースコードや
マシンのスペック、測定データをここに公開する気はないのかね。

まさか古いバージョンのJavaで作られたPetStoreを
例に挙げるわけではあるまい。
もう古くて参考にはならんぞ。

EJBを使ってるところは本当に少ないがな。
多くはEJBの変わりにPOJOを使ってるところばかりだし。
Seasar2とかSping Frameworkとかな。もしくはStruts + Tomcatオンリーとか。
StrtusやJSFすら使わないところも未だにあるが。
727 ：デフォルトの名無しさん：2006/08/29(火) 11:07:27
> Javaの方がパフォーマンスがいいなんて妄想もいいところ。
> JVMがCでできてるんだから、CでJVM（もしくはサブセット）を実装して
> その上で実行すればJavaより遅くなるわけが無い。


こういいきる奴は何度も見てきたが。浅はかで何も解って無いというか、
騙されているというか。Javaの進化に乗り遅れて古い知識しか持っていない
オッサンに多いんだな。
728 ：デフォルトの名無しさん：2006/08/29(火) 11:08:09
>>722
ナノ秒なら
Java5からも実装されたぞ。

System.nanoTime()
729 ：デフォルトの名無しさん：2006/08/29(火) 11:25:25
>>727
そういう小僧は盗んだコードで走る馬鹿だろう？
なんでもおっさん扱いしないでくれよ
730 ：デフォルトの名無しさん：2006/08/29(火) 11:38:05
みんな自分の信ずる言語・環境を支持すればいいだろ
どうしてJavaスレには他の奴らが荒らしにくるんだ？
他の言語・環境がどんなに素晴らしいのかしらんがスレ違いだ
巣に帰れ！
731 ：デフォルトの名無しさん：2006/08/29(火) 12:23:15
次世代を語るところだから、どうしても他の言語と比べた改善点とか要望が出るんじゃない？
732 ：デフォルトの名無しさん：2006/08/29(火) 13:08:47
>>728
言葉が足りなかったかな
すでに実装されている話なんだし次世代の話題じゃないだろうということ

>>716は細かい制御したいのに5.0のコンカレントAPIすらさわってないんだろうなーとかおもっちまう
733 ：デフォルトの名無しさん：2006/08/29(火) 13:53:56
>>731
お前はネイディブコンパイラとのパフォーマンス比較を改善点や要望とでも言うのか？
だたの攻撃だろ？違うのか？
734 ：デフォルトの名無しさん：2006/08/29(火) 14:04:44
>>730
昔懐かしい「C#って死滅しちゃうの？」シリーズスレで
大暴れしていた例のM$厨では？
735 ：716：2006/08/29(火) 14:10:20
>>732

nanoTimeだけじゃアニメーションできなくない？
nanoTimeはsleepの分解能チェックや誤差の補正に使うものかと
結局sleep使わなきゃだめなんじゃないか？
それかObject.waitか。

J2SE6ではDoubleBuffer関係で何らかの改良があると聞いたかが。

そうそうConcurrentは使ってないな。まだ。そんなに必要性も感じてないが。
736 ：デフォルトの名無しさん：2006/08/29(火) 15:08:29
>>727
> > JVMがCでできてるんだから、CでJVM（もしくはサブセット）を実装して
> > その上で実行すればJavaより遅くなるわけが無い。
> こういいきる奴は何度も見てきたが。浅はかで何も解って無いというか、
> 騙されているというか。Javaの進化に乗り遅れて古い知識しか持っていない
？
進化とか古いとか関係ないだろう。CでJavaコンパイラを実装してclassコードを実行するという話をしているのだから
「Javaの方が速い」とならないことは自明なのだが。
恐らく「Javaは実行中にコードの最適化するから速い」とか言いたいんだろうが、
その実装自体はCでできているんだから、どんなにがんばっても「Javaの方が速い」という事態には絶対にならない。
ただ、CでわざわざJVMを再実装するのはコストがかかるから現実的ではないというだけ。

別にそこを認めてもJavaの優位性は変わらないと思うんだけどね。
いつものことだが、JavaしかできないやつはJavaを否定されると自分自身も否定されたような被害妄想を抱くよな。
どっかの宗教団体みたいで嫌だ。いろんな言語触れよ。次世代Javaの議論にも役立つぞ。
737 ：デフォルトの名無しさん：2006/08/29(火) 15:32:33
とんでもない勘違いをしている奴がいるぞｗ
738 ：デフォルトの名無しさん：2006/08/29(火) 15:40:53
痛い子が居るなぁ。
739 ：デフォルトの名無しさん：2006/08/29(火) 15:43:39
>>736 → 737,738
740 ：デフォルトの名無しさん：2006/08/29(火) 15:48:26
>その実装自体はCでできているんだから、どんなにがんばっても「Javaの方が速い」という事態には絶対にならない。

この意味が分からない。絶対と言い切れる根拠はなんなんだろ？
741 ：デフォルトの名無しさん：2006/08/29(火) 15:51:25
Javaで作ってスーパーコンピュータで動かせば速い。
742 ：デフォルトの名無しさん：2006/08/29(火) 15:54:16
>>740
馬鹿には　つ　き　あ　う　な
743 ：デフォルトの名無しさん：2006/08/29(火) 15:57:28
>>740
> その実装自体はCでできているんだから、どんなにがんばっても「Javaの方が速い」という事態には絶対にならない。
> この意味が分からない。絶対と言い切れる根拠はなんなんだろ？
極論を言えば、
int main(){JavaVM *jvm;JNI_CreateJavaVM(&jvm);jvm->DestroyJavaVM();}
と書けば少なくとも速度は同じになるというだけのこと。
そんなにややこしいことは言ってない。
「JVMがCで書かれている」というのをもうちょっと考えろよ。
744 ：デフォルトの名無しさん：2006/08/29(火) 15:59:54
>>741
JVMの役割を知っていれば、わざわざスーパーコンピューターでJavaを使おうなんて考えないよ。
745 ：デフォルトの名無しさん：2006/08/29(火) 16:01:56
>743の続き
で、JVMのソースコード中から、実行に不要な部分を削除していけば、
JVMをいじれないJavaよりも、Cの方が速くなる。誰でも分かる話だと思うんだがな。
実際にはそんなところに開発コストをかけるのは無駄だから現実的ではないと言ってるだけ。

頭が悪いのか、それとも宗教にはまってるからなのか。。。
746 ：デフォルトの名無しさん：2006/08/29(火) 16:05:00
>>735
nanotimeはポーリング用

定期実行にはTimer方面つかえといっておろう
747 ：デフォルトの名無しさん：2006/08/29(火) 16:06:08
> JVMをいじれないJavaよりも、Cの方が速くなる。誰でも分かる話だと思うんだがな。

JVMはCのライブラリィではないよ（笑）
748 ：デフォルトの名無しさん：2006/08/29(火) 16:46:20
>>742
あい、了解したw
749 ：716：2006/08/29(火) 17:51:39
>>746
アニメーションとかの20msecとかそういう間隔の話をしているつもりだったんだけど、
Timer? ありえなくないか？
750 ：デフォルトの名無しさん：2006/08/29(火) 17:54:46
　
751 ：デフォルトの名無しさん：2006/08/29(火) 17:55:17
747はとても親切だ。
暴れてるやつは声を出して読むように。
752 ：デフォルトの名無しさん：2006/08/29(火) 18:00:01
>>749
どういう動きかわかってないんじゃない？
基本から勉強したほうがいいよ
753 ：716：2006/08/29(火) 18:07:25
>>752
教えてくれ。
Timerも結局waitを使っているとドキュメントされているが、
waitは正確性を欠く、それをnanoTimeとかで確認してスケジュールを補正するのが教科書とおりなのだが、
Timerを使ってしまうと補正ができなくないのではないか？

次世代になってもwaitとかの精度はそんなに変わらないんだろうな
754 ：デフォルトの名無しさん：2006/08/29(火) 18:15:40
そこまでわかってるなら問題あるまい


垂直同期にこだわらなければ60fpsにする必要もあるまい
垂直同期にしたら自動的にリフレッシュレートであわせられる

Win32ネイティブでやってるのと状況はかわらんよ
755 ：デフォルトの名無しさん：2006/08/29(火) 19:20:49
Windowsのマルチメディアタイマーは1msで寝れたと思うが
756 ：デフォルトの名無しさん：2006/08/29(火) 19:50:44
malloc/freeはどうした？＞最速厨
JVMは都合のいいタイミングまでガベコレを遅延できる。
これをやると、特にSMPで差が開く。
757 ：デフォルトの名無しさん：2006/08/29(火) 20:03:09
蒸し返すな
758 ：デフォルトの名無しさん：2006/08/29(火) 20:09:11
>>756
性能を重視するならmalloc/freeをそのまま使ったりなんてせず、
普通は独自アロケータを定義するでしょ。
759 ：デフォルトの名無しさん：2006/08/29(火) 20:54:34
>>720は、ぐぐってみたところ、
Javaの方が実行速度が速い例がたくさん見つかったので、
>>736>>743でごまかそうと必死w
760 ：デフォルトの名無しさん：2006/08/29(火) 22:55:04
Javaがなんでもかんでも速いというつもりは全然無いんだが、Ｃで組んだっ
て結局実装の仕方次第だろ。malloc/freeを何度も繰り返すような素のＣの
組み方したら、JVMの「そもそもメモリ解放自体めったにしないで確保してる
メモリを使い回す」ような実装より遅くてあたりまえ。

例えばObjective-CはＣのサブセットで、コンパイルすれば完全なバイナリに
なるわけだが、メソッド呼び出し速度とメモリ取得・解放速度でJavaのほうが上回る。
これはオブジェクト周りの実装の仕方の差だろ。

そこを意識して力技なパフォーマンスチューニングを組み込んでＣでゼロから
作れば、速くなるのも当たり前。

JavaがＣより速いとかいう話は、「Ｃで普通に組んだものより、Javaで普通に
組んだものの方が速いことがある。なぜなら、JVM自体にすでにパフォーマン
ス・チューニングがされているから」という意味だってことがわからないのだろうか。

普通に組んだ時のパフォーマンスの差には意味があると思うけどねえ。
761 ：デフォルトの名無しさん：2006/08/29(火) 22:55:23
>>736
C言語原理主義者の言い訳ごくろう。
また「Javaしかできない奴」とステレオタイプ貼り付けとは。
Javaで飯食ってきたかったらJavaしかできないなんてありえんからね。


762 ：デフォルトの名無しさん：2006/08/29(火) 22:57:39
>>758
その独自アロケータとやらは、Javaの世代別GCを超えられるのか？
ヒープアロケーションやデアロケーションに、凝った戦略(実行は超高速)
とってるよ、あれ。フリーリスト管理独自実装とか、ショボイことしてい
る間は越えられんでしょ。
763 ：デフォルトの名無しさん：2006/08/29(火) 23:03:03
コンパイラやＶＭの性能次第で、幾らでも早い言語・遅い言語になるわけだが。

言語の特性とコンパイラ最適化技術辺りは最低限踏まえて議論しような。
764 ：デフォルトの名無しさん：2006/08/29(火) 23:10:49
マイクロベンチしにくい言語だなぁと思うことはよくある。
例えばN秒間の実行回数が4400〜5200とか異常な数値を出すこともしばしば。
ヒープサイズは-Xms -Xmxともに同じサイズにしても起こすから原因がつかめない
765 ：デフォルトの名無しさん：2006/08/29(火) 23:12:15
結局、学生とかによくある卓上理論ってやつじゃないのか？
766 ：デフォルトの名無しさん：2006/08/29(火) 23:22:36
机上だと思う。
767 ：758：2006/08/29(火) 23:46:35
> その独自アロケータとやらは、Javaの世代別GCを超えられるのか？
越えられるよ。
つーか、JavaのGCとかboehmGCとか、そういう汎用的なメモリ管理実装に
満足できないから独自実装するわけで。

> ヒープアロケーションやデアロケーションに、凝った戦略(実行は超高速)
> とってるよ
それは独自アロケータでも同じ。
そもそも、あるサブシステムでは特定のサイズのメモリを大量にアロケートするとか、
そういうプログラム固有の事情も考慮した上で最適なアロケータを設計するんだよ。

一般道から高速道までいろいろな状況でもそれなりに速く燃費の良いエンジンを作るのと、
サーキット上での速さの極限を目指したエンジン作りとを比較するようなもの。
そもそも設計方針から全く違う。
768 ：デフォルトの名無しさん：2006/08/29(火) 23:52:47
いずれにしても現実にあるjavaのOOなプログラムは速度の最適化は難しいんじゃないか？
javaだからっていうか、OOだから。

例えば、java3dとか、hibernateとか、
769 ：デフォルトの名無しさん：2006/08/30(水) 00:04:22
じゃあ、比較すんなよ。
770 ：デフォルトの名無しさん：2006/08/30(水) 00:06:31
>>767はなんかすごそうな職人さんのようですね。
必要に迫られて独自にそういうすごいのを作ったのでしょうが、
凡人・汎用ではjava vmぐらいでいいです。ruby gc thread とか遅くても
ちゃんと答えを出してくれればいいです。
771 ：デフォルトの名無しさん：2006/08/30(水) 00:07:08
>> その独自アロケータとやらは、Javaの世代別GCを超えられるのか？
>越えられるよ。
>つーか、JavaのGCとかboehmGCとか、そういう汎用的なメモリ管理実装に
>満足できないから独自実装するわけで。

このように、独自実装厨はチューニングが重ねられた汎用アルゴリズムに
劣る糞コードを生成するわけだ。乙
772 ：デフォルトの名無しさん：2006/08/30(水) 00:08:40
Javaの利点はCPUにあわせた動的コンパイルなんじゃないのかねえ。
Cだとターゲットにあわせて自分でコンパイルオプションを指定しないといけないけど
Javaならある意味JVMが勝手にチューニングしてくれるし。
773 ：デフォルトの名無しさん：2006/08/30(水) 00:09:33
生産性を意識すりゃなんだって「それなり」の速度だっての。
うざいから他所でやってくれ、マ板でやることじゃないだろ。
774 ：デフォルトの名無しさん：2006/08/30(水) 00:23:50
>>768-774 みんなから一斉にツッコミのあらし。なんか知らないけど、笑いが止まらねー
775 ：デフォルトの名無しさん：2006/08/30(水) 00:30:06
次世代Javaに速度は強くもとめないということで。

おもいらそれよりSE 6のどこが素敵なのかまとめてくれんか？
776 ：デフォルトの名無しさん：2006/08/30(水) 00:38:07
ヒープ共有とタスクトレイはツール促進に繋がると思う。
777 ：デフォルトの名無しさん：2006/08/30(水) 00:48:00
Java 5.0 で既に十分高速なので議論しても仕方が無い。
それより、Java 6.0 Java 7.0 に予定されている言語拡張・ライブラリについて語ろうぜ。
778 ：デフォルトの名無しさん：2006/08/30(水) 01:08:56
>>11の
＞プロパティのサポート
＞メソッドリファレンスのレポート
＞クロージャのサポート
＞言語レベルでのXMLのサポート
＞JVM上で動作する動的言語のサポート
＞スクリプト言語サポートの拡張
＞モジュール化のサポート
＞Swingアプリケーション開発のためのツールの充実

のうち、今回出てきたのは「メソッドリファレンス（たぶんローカル・ファンクションのこと
だろう）」と「クロージャのサポート」なわけだが、
「プロパティのサポート」はまだ具体例が出てきてないね。

最後のSwingアプリケーション開発のためのツールって
のは、たしかSwingをベースにしたアプリケーション・フレー
ムワークを作るとかだったっけ。
779 ：デフォルトの名無しさん：2006/08/30(水) 01:17:25
最後のはただのNetBeansプラットフォームだったりしてな
780 ：デフォルトの名無しさん：2006/08/30(水) 01:27:48
# クラスパスのワイルドカード指定

これなｗ　これが一番重要な更新だったりしてｗ
781 ：デフォルトの名無しさん：2006/08/30(水) 01:48:38
ttp://weblogs.java.net/blog/hansmuller/archive/2006/06/jsr_296_bows_sw.html
ttp://weblogs.java.net/blog/hansmuller/archive/ts-3399-final.pdf
782 ：デフォルトの名無しさん：2006/08/30(水) 02:59:33
つ ttp://pc8.2ch.net/test/read.cgi/tech/1150286189/
783 ：デフォルトの名無しさん：2006/08/30(水) 03:04:55
Swing Application Frameworkって具体的にはどんなの？
784 ：デフォルトの名無しさん：2006/08/30(水) 03:25:08
>>758,>>767 その経験は選ばし者のみ体験できることぞよ。そこから習得した業をこれからも存分に発揮するが良い。わははははは
785 ：デフォルトの名無しさん：2006/08/30(水) 04:34:32
まずJavaをCたらしめているcloseメソッドをなんとかしろよ
まず名前をdeleteに変えてバカに気づかせろ
786 ：デフォルトの名無しさん：2006/08/30(水) 06:11:40
>>781
ktkr
いったいここまでたどり着くのに何年かけてんだ？
こんなのNEXTSTEPをSolarisにポートした連中なら最初に気が付いてるだろ
787 ：デフォルトの名無しさん：2006/08/30(水) 08:30:02
いやー、これなかなかいい設計だぞ？
今の基準でみると糞みたいなNEXTSTEPのフレームワークと違ってw
788 ：デフォルトの名無しさん：2006/08/30(水) 09:15:32
>>756
> malloc/freeはどうした？＞最速厨
> JVMは都合のいいタイミングまでガベコレを遅延できる。
分からん奴だな。そのガベコレをCで実装すればいい。
>>759
> >>720は、ぐぐってみたところ、
> Javaの方が実行速度が速い例がたくさん見つかったので、
Javaの方が速いっていうのは、C側ベンチでJavaと同じ事をしていないだけのこと。
Javaの挙動全てをCで実装すればJavaと同じ速度になるのは当たり前だと言ってるだけだ。
>>772
> Javaの利点はCPUにあわせた動的コンパイルなんじゃないのかねえ。
> Cだとターゲットにあわせて自分でコンパイルオプションを指定しないといけないけど
そんなもの不要。CPUにあわせた動的コンパイルをCで書けばいいだけ。
.classファイルを読み込んでJVM上で実行（もちろんJIT付き）するようなCプログラムを書けば、
Javaの方が速くなるなんてことは無いと言ってるだけなのに何で分からんかな。
789 ：デフォルトの名無しさん：2006/08/30(水) 09:18:19
必死だな。
790 ：デフォルトの名無しさん：2006/08/30(水) 09:22:30
こんなに頭悪い奴だとは思わなかった。
791 ：デフォルトの名無しさん：2006/08/30(水) 09:24:23
>>788
いいたいことはなんとなく分かったが、それを言うことで
あんたが何をしたいのかがさっぱり分からん。
792 ：デフォルトの名無しさん：2006/08/30(水) 09:28:24
自分の無知の隠蔽
793 ：デフォルトの名無しさん：2006/08/30(水) 09:34:40
痛い子が粘着してるな
明日までの辛抱かの
794 ：デフォルトの名無しさん：2006/08/30(水) 10:08:05
>>775
しかし、バージョンアップするたびに高速化してるみたいなんだけど。
次期バージョンJava6もPreJITによってかなり高速化が期待できるんでない？
二回目以降のアクセスからはCのネイティブと同じ扱いになってかなり高速化する、みたいな。
795 ：デフォルトの名無しさん：2006/08/30(水) 10:10:16
>>792
面白すぎる。
マ板で必死にJava叩きしてるおっさんどもを思い出すw
796 ：デフォルトの名無しさん：2006/08/30(水) 11:11:25
>>791
> >>788
> いいたいことはなんとなく分かったが、それを言うことで
このスレで頭がいいのはあんただけのようだな。
> あんたが何をしたいのかがさっぱり分からん。
>>720を理解できない奴が多かったから説明しただけ。
あんたみたいに理解力のある奴ばかりだったらいいんだがな。
>>736に書いた通り、Javaをけなそうとしているわけではないし、Cが素晴らしいなんて言うつもりも全く無い。
797 ：デフォルトの名無しさん：2006/08/30(水) 11:16:38
JVMはCで実装しなきゃいけない決まりでもあるの？
Javaチップ上でベンチ比較する場合についてはどう考えてるの？
この場合Cの処理系をまず用意しないとダメだけど…
798 ：デフォルトの名無しさん：2006/08/30(水) 11:45:08
>>796
どっかの宗教団体みたいなのはお前のほう。
お前の主張がいったい何になるのか説明できんだろ。
お前の意見が何もプラスにもならないならどっかの宗教団体と変わらない。

799 ：デフォルトの名無しさん：2006/08/30(水) 12:46:01
わかったから、アセンブラで書くと最強！
Cはその次！
で良いだろ
実の無い議論しても無駄だろ
800 ：デフォルトの名無しさん：2006/08/30(水) 13:19:58
こいつら一体何なんだ・・・
801 ：デフォルトの名無しさん：2006/08/30(水) 13:34:54
> JVMはCで実装しなきゃいけない決まりでもあるの？
> Javaチップ上でベンチ比較する場合についてはどう考えてるの？
はいはい、机上の仮説はどうでもいいから、
まずはC,C++で実装された現行のJVMにも性能面でひけを取らない
Javaチップを開発してからまた来てね。
802 ：デフォルトの名無しさん：2006/08/30(水) 13:36:25
>>800
Cで１からjvmもどきを書くと現行のJITより高性能をたたき出せる天才プログラマ様らしいよ
803 ：デフォルトの名無しさん：2006/08/30(水) 13:37:01
もうお前等来なくていいよ!
804 ：デフォルトの名無しさん：2006/08/30(水) 13:41:37
>>720 が悪い。
805 ：デフォルトの名無しさん：2006/08/30(水) 13:51:17
> > Javaの利点はCPUにあわせた動的コンパイルなんじゃないのかねえ。
> > Cだとターゲットにあわせて自分でコンパイルオプションを指定しないといけないけど
> そんなもの不要。CPUにあわせた動的コンパイルをCで書けばいいだけ。
まあ、CPUのサポートする命令セットに合わせて実行時に自己書換する、なんて
テクニックは大昔からあるよね。
今だって、多くの動画コーデックはSSE等の拡張命令の有無を実行時に調べて
動的に実行コードを生成したりしてるし。

そういう古くからあるテクニックの一部がJVM実装にも取り込まれるように
なってきた、ってだけの話。
806 ：デフォルトの名無しさん：2006/08/30(水) 14:06:40
俺よー、JVMの仕組みよく知らないんだけどJavaって実行時に
何度も実行される箇所はコンパイルしてネイティブコード生成するんだよな？

だから

コンパイル時間 + (CPU最適化コード実行時間 * n) > 386バイナリ実行時間

この式が成り立つ可能性は十分あると思ってる。( n が増加するほどJava有利)

なんかJavaはCを越えられないと言ってる奴はどうも
ネイティブコード生成後もJVMで解釈して実行してると思ってそうなんだが…？

CでもIntelMacのユニバーサルバイナリみたいに全CPUに最適されたコードを含んだ
バイナリを持てばJavaを上回るのは明らかだけど、そんな事してる奴いないよね。
807 ：デフォルトの名無しさん：2006/08/30(水) 14:23:54
> コンパイル時間 + (CPU最適化コード実行時間 * n) > 386バイナリ実行時間
>
> この式が成り立つ可能性は十分あると思ってる。( n が増加するほどJava有利)

だから、nが大きくて、CPU毎に最適化したコードによる恩恵が十分得られる場合は、
>805のような動的実行コード生成をC, C++でもやればいいだけの話。
で、こういう手法は机上の空論じゃなく、多くの動画コーデックや
OSカーネル(ページクリアに使うmovntiとか)など、多くの場所で用いられているんだよ。
808 ：デフォルトの名無しさん：2006/08/30(水) 14:32:31
>>807
>> >805のような動的実行コード生成をC, C++でもやればいいだけの話。

必ず同じ事ができるとは限らない。
809 ：デフォルトの名無しさん：2006/08/30(水) 14:34:51
「JavaがCより速い場合がある」ってのは、同じようなアルゴリズムでコードを書いた場合ってことだろ。
そりゃ、最適化したコードで比べればどんな場合でもCの方が速くなるだろうよ。
でも、その最適化したコードをCで書くのは、コストや能力を考えると現実的に不可能だ。
810 ：デフォルトの名無しさん：2006/08/30(水) 14:37:58
> >> >805のような動的実行コード生成をC, C++でもやればいいだけの話。
>
> 必ず同じ事ができるとは限らない。

その理由は?
Cで書かれたJVMにできて、Cで直接書かれたプログラムにできないことって何?
それともJavaチップのことでも言ってるの?(笑
811 ：デフォルトの名無しさん：2006/08/30(水) 14:51:14
>>806

コンパイル時間 << ε

ならば、誤差の範囲内として無視できる。

すると、JavaとCとでは速度はさほど変わらなくなる。


また、
Java実行速度 - C実行速度 << ε

なら、ますます無視できる。

ここでεとは非常に小さな値を表し、 <<は<よりもうんと大きな差があることを意味する。
つまりうんと小さくなるという意味。
812 ：デフォルトの名無しさん：2006/08/30(水) 14:55:54
で、Ｃでできるからなんだよ？
813 ：デフォルトの名無しさん：2006/08/30(水) 14:57:04
>>810

実例を出すと、ベクトル型スパコン。
Cで書かれたプログラムより、FORTRANプログラムの方が速いとされる。
コンパイラはどちらもCで作られている。

これは、ソースレベルでは同じアルゴリズムであっても、FORTRANで記述
されたプログラムの方が、Cよりも最適なベクトル化できるからである。

コンパイラを同じCで作っても、どこまで最適化できるかは、各言語仕様も
関係してくる。
814 ：デフォルトの名無しさん：2006/08/30(水) 15:48:19
あれ、いつの間にここはFORTRANスレになったのかな?
815 ：デフォルトの名無しさん：2006/08/30(水) 15:49:14
>>813
だから、｛Cで書かれたFORTRANコンパイラ＋.Fのソースファイル｝を合わせて、
一つのCで書かれたソフトウェアと見なすって話が延々と続いているわけだ。

論理的には正しいが、実効的な意味はない。
ってのが>>736の最後のパラグラフの意味だと思われ。
816 ：602：2006/08/30(水) 16:04:51
>>778
メソッドリファレンスって俺待望の　>>602　で書いたようなことじゃないのかね？

だとしたら、あと5年はjavaを使おうかと思うな

でもSE7からなのか。。。
817 ：デフォルトの名無しさん：2006/08/30(水) 17:09:12
>>788
> >>756
> > malloc/freeはどうした？＞最速厨
> > JVMは都合のいいタイミングまでガベコレを遅延できる。
> 分からん奴だな。そのガベコレをCで実装すればいい。

不可能。メモリ関数の使用を禁止せず、ガベコレを実装できない。
メモリ関数の使用を禁止すれば、ソースを書き直さなければならず、
もはやCのプログラムではなくなる。だから、JavaやC#のような新しい
言語ができたことを理解しろ。
818 ：デフォルトの名無しさん：2006/08/30(水) 17:15:04
>>817
へー、Boehm GCを使ったCプログラムはCのプログラムではないんだ。
819 ：デフォルトの名無しさん：2006/08/30(水) 17:25:20
>>818
ベタベタなコードにコンサバなGCで体裁繕ったらパフォーマンスでないぞ
いい加減みっともないまね続けるなよな

820 ：デフォルトの名無しさん：2006/08/30(水) 17:31:01
>>817
> 不可能。メモリ関数の使用を禁止せず、ガベコレを実装できない。
JVMはどうやってガベコレを実装してるの？
821 ：デフォルトの名無しさん：2006/08/30(水) 17:33:30
>>807
つまり、普通の人はそんなの作らない＆作れないから、
凡人が高速なプログラムを作ろうとしたらJavaで書いて実装した方がいいって事だよね。

理論的にCオンリーの方が早くなるっていうのは別に、誰も否定しないと思うけど
現実的にJavaの方が早くなる【場合がある】っていうのを認められないのは厨房だと思うな。
822 ：デフォルトの名無しさん：2006/08/30(水) 17:34:27
>>820
メモリ関数使ってるに決まってるだろ。馬鹿じゃねぇの？
823 ：デフォルトの名無しさん：2006/08/30(水) 17:38:48
Javaの人は、Cはほどほどに教養程度なんじゃない？
詳しかったらJavaの環境に居ないで、Cの環境（Win32やUnix）に行ってるでしょ。

せいぜい jni 程度でゴニョゴニョで、gc 実装とかそんなディープ話題は
次世代Java環境が気になるJava使いの人はついて来れないと思う。
824 ：デフォルトの名無しさん：2006/08/30(水) 17:42:27
>>823つまり冷やかしもほどほど程度にしとけってことかな？
825 ：デフォルトの名無しさん：2006/08/30(水) 17:47:11
言語仕様も関係するが、それよりも実行形式の抽象度の違いによるんだよ。
826 ：デフォルトの名無しさん：2006/08/30(水) 17:50:09
>>823
当然、おまいはGCの実装経験がある or 実装できるのだな。
各種GCアルゴリズムについて語らないか？
827 ：デフォルトの名無しさん：2006/08/30(水) 17:54:35
>>822は叩かれてる人？泣きそうになってるみたいだけど
828 ：デフォルトの名無しさん：2006/08/30(水) 18:09:04
>>807
>だから、nが大きくて、CPU毎に最適化したコードによる恩恵が十分得られる場合は、
>>805のような動的実行コード生成をC, C++でもやればいいだけの話。
>で、こういう手法は机上の空論じゃなく、多くの動画コーデックや
>OSカーネル(ページクリアに使うmovntiとか)など、多くの場所で用いられているんだよ。

if(SSE２命令が利用可能か？) {
// SSE２命令を利用したインラインアセンブラによるコード
}
else {
// SSE２命令を利用しないインラインアセンブラによるコード
}

これのどの辺りが動的実行コード生成になるのか説明してくれんか？
無知は怖いね。
829 ：デフォルトの名無しさん：2006/08/30(水) 18:52:56
高速化高速化いうてるけど
1.4.2のが5.0より速いらしいぞ
SUNのベンチ鵜呑みにするなや
830 ：デフォルトの名無しさん：2006/08/30(水) 18:56:32
>>828
ほらよ。
ttp://mkosaki.blog46.fc2.com/blog-entry-104.html
831 ：デフォルトの名無しさん：2006/08/30(水) 19:08:15
> せいぜい jni 程度でゴニョゴニョで、gc 実装とかそんなディープ話題は
> 次世代Java環境が気になるJava使いの人はついて来れないと思う。

だろうね。
というか、そういう話をこのスレでやるのがそもそも間違い。
パフォーマンス厨は↓へ行ってくれ。
http://pc8.2ch.net/test/read.cgi/prog/1153547716/
832 ：デフォルトの名無しさん：2006/08/30(水) 19:41:39
>>823
いまどきそうやってCはJavaよりも凄く、
「Cを知っていればJavaを知らなくても偉いんだ！」
と勘違いしてCしか知らず、Javaのことろくに勉強しないのも、恥ずかしいことなのだが。
833 ：デフォルトの名無しさん：2006/08/30(水) 19:49:41
いまどきそうやってJavaはCよりも凄く、
「Javaを知っていればCを知らなくても偉いんだ！」
と勘違いしてJavaしか知らず、Cのことろくに勉強しないのも、恥ずかしいことなのだが。
834 ：デフォルトの名無しさん：2006/08/30(水) 20:04:14
いまどきそうやって技術は一般常識よりも凄く、
「技術を知っていれば一般常識を知らなくても偉いんだ！」
と勘違いして技術しか知らず、一般常識のことろくに勉強しないのも、恥ずかしいことなのだが。
835 ：デフォルトの名無しさん：2006/08/30(水) 20:08:04
>>833
お前よ、餓鬼みたいに>>832のコピペしてるのどっかで見たことがあるぞ。
C#死滅スレのVBとC#を崇拝する、継承嫌いの餓鬼だろw
836 ：デフォルトの名無しさん：2006/08/30(水) 20:08:49
>>834
まてまて技術は一般常識の範疇に入るぞ
837 ：デフォルトの名無しさん：2006/08/30(水) 20:12:42
いつまでたっても馬鹿が釣られまくっとるな
ガキが相手するから正常化せんのだが能無しには分からんか
838 ：デフォルトの名無しさん：2006/08/30(水) 20:29:39
>>828
ﾌﾟ
無知は怖いね。
839 ：デフォルトの名無しさん：2006/08/30(水) 20:54:06
嵐が過ぎた後は誰もいなくなっている悪寒。

お前らCがJavaより早くJavaはCより早いのは分かったから
メソッドリファレンスが何なのか情報提供してくれ。
840 ：デフォルトの名無しさん：2006/08/30(水) 21:01:00
>>837
奴はＶＢとC#に詳しいアホだよ。
昔、語尾に「嘲笑激藁」「ﾌﾟﾌﾟ」「ｹﾞﾗ」「ﾜﾗ」「大爆笑」
をつけてた奴、ハンドルが「255」とかつけてた奴に
非常にそっくり。

結局あそこまでC#を持ち上げても、全然はやらなかったな。
どうせ奴は鬱憤晴らしにスレを荒らしてるだけだろう。
841 ：デフォルトの名無しさん：2006/08/30(水) 21:03:33
>>807
つーか、動的生成云々うるさいけど、それってモジュール切り替えでええんじゃないん？
実行時生成なんてしなくても、コンパイルしたモジュールも含めればいいだけの話。

C使いでもめったに使わない技術を得意げに語るのは哀れですらある。

Java厨だってバイトコードの自力生成なんて滅多にしない。
842 ：デフォルトの名無しさん：2006/08/30(水) 21:04:55
レスすんなカス
どこまで脳みそゆるいんだ
843 ：デフォルトの名無しさん：2006/08/30(水) 21:07:33
>>787
いやー盛り上がってるとこ悪いが、20年経ってその台詞恥ずかしくないかw
844 ：デフォルトの名無しさん：2006/08/30(水) 21:13:58
ところでJavaCardって何に使うの？
Java OneとSUNのシンクライアントでつかうくらいしか聞いたこと無い。
Edyのがすごいよ、コンビニ清算最速ってすごくね？
845 ：デフォルトの名無しさん：2006/08/30(水) 21:15:41
ココの住人には>>823は図星なのか？
みんなずいぶん喰らったみたいけど大丈夫か？
846 ：デフォルトの名無しさん：2006/08/30(水) 21:16:00
>>813
C言語にポインタがあるために、ベクトル化による十分な最適化ができないが、
FORTRAN言語にはそのポインタがないので、十分にベクトル化できると聞いた
ことがある。

Java言語が出たとき、JavaもポインタがないのでFORTRAN並に最適化できる
のではないかという極端な記事が、Cマガジンに載っていたような覚えがある。


今となってはJavaの仕様では、FORTRAN並に最適化は無理なのは自明だが・・。
847 ：デフォルトの名無しさん：2006/08/30(水) 21:17:28
>>841
バイトコードの自力生成ってできたの？しらなｋった。
ところで、どうやってやるの
848 ：デフォルトの名無しさん：2006/08/30(水) 21:19:42
図星ってのもあるが正直どうでもいい
特定環境に最適化されたGCなんて興味ないなって感じ
849 ：デフォルトの名無しさん：2006/08/30(水) 21:20:32
>>830
オイオイ、必死に何か探してきたと思ったらコレだ。
自己書き換えと動的実行コード生成は似て非なるものなんだが。
850 ：デフォルトの名無しさん：2006/08/30(水) 21:32:51
>>847
適当なバイト列を作ってClassLoader#defineClass()を呼ぶだけだ。
そのバイト列はJavaVM仕様に合わせて作ればいい。
BCELやasmなどのバイトコード作成用ライブラリもある。

Java5からはClassLoader側で細工しなくてもバイトコード変換ができるように
java.lang.instrumentパッケージ以下のクラスが追加された。
851 ：デフォルトの名無しさん：2006/08/30(水) 21:54:51
>>850 しらなかった、あんがと。Jakarta BCELを読んでみる。
852 ：デフォルトの名無しさん：2006/08/30(水) 21:59:14
>>851
正直言って、BCELは設計が古いというか微妙に使いにくいので、
新規ならASMかJavassist使った方が良いかと
他言語 -> Javaバイトコードのコンパイラ作るなら、Javassistはちょっと使いにくいが
853 ：デフォルトの名無しさん：2006/08/30(水) 22:09:50
今BCEL読んでる最中だけど、これってすげーな。
この技術と言うか概念というか、次のリリースでスクリプト言語を
java vmに取り込むとか言うのより、さらに高次元の話じゃん。
854 ：デフォルトの名無しさん：2006/08/30(水) 22:32:11
大体概要は分かったけど、すごかった。こういうツールが整備されて
徐々に万人向けに使いやすくなっていくと、これからも OSに依存しな
い Java の環境がより強固なものになっていく予感がする。
昔Sunが目指していたNetworkがどうのというやつなのかな。

> 他言語 -> Javaバイトコードのコンパイラ作るなら
>>852さんはこういう系の人なのでしょうか？
そうとは知らずに、言葉遣いが足らず失礼しました。
855 ：デフォルトの名無しさん：2006/08/30(水) 22:50:38
>>854
852だけど、一応そういう系の人です。Java VM上で動作する
とあるスクリプト言語開発してます。超マイナーな言語ですが
一応どんな言語かというと、Javaに似たセマンティクスに
スクリプト言語っぽいシンタックスシュガーをふりかけました
みたいな言語です

> 言葉遣いが足らず失礼しました

？別に特に>>854さんが失礼な言動をしたとは思わなかったけど
856 ：デフォルトの名無しさん：2006/08/30(水) 22:54:35
あ、ひょっとしたら誤解してるかもしれないんで一応いっておくと
>>850さんと>>852(= >>855)は別人なんで
857 ：デフォルトの名無しさん：2006/08/30(水) 23:31:46
　　 いや〜、やっぱりここにはいろんな人が来てるね〜
＼＿＿＿＿＿　＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　　　　　　 ∨　|　
　　　　　　　　　　　|　まいど、まいど！繁盛、繁盛！！
　　　　　　　　　　　＼＿　＿＿＿＿＿＿＿＿＿＿＿
　 ＿＿　　　　　　　　　 ∨
／　　／|　　　　　　　∧＿∧　　　　　　　
|￣￣|／|　　　　　　 （・∀・　）　(　　　
|￣￣| |￣￣￣|＼＿（＿　　 ）＿ （・∀・：　）Java は さいきょう じゃ
|￣￣| |＿＿＿| ∧＿∧ ￣￣￣　／／／／|
|￣￣| |＿＿＿|（　　　　）＿＿＿_|￣￣￣|／|
|￣￣　　　　　　（　○　 ）　　　　　￣￣￣|　 |
|　　　　　　　　　｜ ｜　|　　　　　　　　　　|　 |
| 　 　　　　　 　 （＿（＿）　　　　　　　　　　|／
858 ：デフォルトの名無しさん：2006/08/30(水) 23:44:50
ここで思ったんだが、JVM用のC言語を書くってのはどう？
859 ：デフォルトの名無しさん：2006/08/30(水) 23:47:50
>>858
JVMしか作成できない言語を作るの？
どんなメリットがあるの？
860 ：デフォルトの名無しさん：2006/08/30(水) 23:53:53
ちょっとだけスレを読んでみたけど、
ガベコレ実装しそうな職人とか、
サーバー用ツールと次世代Javaの関係が気になる人とか、
クライアント用(携帯アプリ)の開発者とか、
コンパイラ作る人とか、
CマンセーなのにJavaが気になる人とか、
JVM上で動作するスクリプト開発者とか、
いっぱい居て楽しそうだね〜♪
861 ：デフォルトの名無しさん：2006/08/30(水) 23:55:09
>>859
ごめん言葉足らずだったね
JVM上で動くバイナリを吐くC言語だ
862 ：デフォルトの名無しさん：2006/08/31(木) 00:10:41
>>861
> JVM上で動くバイナリを吐くC言語だ

Cのソースからクラスファイルを作るということ？
863 ：デフォルトの名無しさん：2006/08/31(木) 00:20:12
>>855
ちょいと質問なんだが、JRubyやJPyton、GroovyやJavaScriptじゃだめだったの？
独自スクリプト言語を新規開発するに至る動機はナンデスカ？
864 ：デフォルトの名無しさん：2006/08/31(木) 00:54:34
「独自スクリプト言語を新規開発する」どころか、
「独自スクリプト言語を新規開発するためのフレームワーク」が出て来ているのに、
そんな質問するに至る動機はナンデスカ？

せめてどんな特徴があるんですか？くらいにしてくれよ
865 ：デフォルトの名無しさん：2006/08/31(木) 00:56:48
>>862
そんな感じ
それなら単純にJava言語とC言語の比較が出来るだろ
866 ：デフォルトの名無しさん：2006/08/31(木) 01:01:57
>>861
そんな無意味なものを誰が使うんでしょうか。

性能上の要求が高くて、高級アセンブラを使うリスクを拾わなきゃいかん場合に、
仕方なくCを使うのであって、要求が低くてJavaなり何なり使って手抜きできるな
ら、手抜き言語使うんじゃないの。
867 ：デフォルトの名無しさん：2006/08/31(木) 01:02:58
> それなら単純にJava言語とC言語の比較が出来るだろ

言語仕様そのものを比較するわけじゃないから、意味なくない？
868 ：デフォルトの名無しさん：2006/08/31(木) 01:07:26
>>863 私の野生の勘ですが、javascript かjrubyの開発関係の人ですよ、きっと。もしくは学者先生。だからそそうのないように・・
869 ：sage：2006/08/31(木) 01:18:44
>>868
なんで2chで書きこみのリアル人生に気を使う必要があるんだと小一時間(ry
大体、そんなｴﾗｲ人がこんなところでクダまくかいな。
870 ：デフォルトの名無しさん：2006/08/31(木) 01:20:32
>>855
JVM系のスクリプト言語は多くが動的型で、パフォーマンスがJavaに比べて劣るから、
静的型でJavaと同等のパフォーマンスを保ちつつ、手軽に書ける言語が欲しかった
というところ
実際、簡単なベンチマークとってみたら、Javaとほとんど同等の速度が出てた
まあ、セマンティクスがJavaに極めて近いから、速度出るのは当たり前なんだが
とはいえ、予定していた言語仕様はそれなりに実装できたものの、ライブラリをまだ
全然作ってないので、Javaのライブラリを使うしかないという情けない状態になってるが
871 ：デフォルトの名無しさん：2006/08/31(木) 01:27:29
>>870
よくわかりませんが、それって、例えばGroovyみたいな言語
→JVMバイトコードのコンパイラ作ったってことですか？
872 ：デフォルトの名無しさん：2006/08/31(木) 01:27:45
>>858,>>861-862,>>865-867
現時点での実用性で考えると、いらない、意味無いというのは当たり前だと思う。

現状の、Java VMが各OS上のの単なる１サービスや１アプリケーションと考えると
無意味だけど、これとは逆に各OSはJava VM上の１アプリ・１コンテンツと考えると、
状況は変わってくるんじゃないかな？
よく言うところの、ネットワークをでかいプラットホーム見立てて各OSはJavaの環境
で統一って言うやつ。

ちなみに私は>>858じゃないよ。
873 ：デフォルトの名無しさん：2006/08/31(木) 01:28:06
>>869

855だけど

> 大体、そんなｴﾗｲ人がこんなところでクダまくかいな。

まあ、そりゃそうだわなw
リアルではただの大学院生です
ただ、エライ人でも興味ある分野のスレ見てる人は結構居るみたいですが
874 ：デフォルトの名無しさん：2006/08/31(木) 01:29:30
>>871
そういうことです
しかし、自分が言えたセリフじゃないが書き込みのペースが早いなw
875 ：デフォルトの名無しさん：2006/08/31(木) 01:31:55
>>867
だって、JavaとCの比較ならおかしくないだろ
JITとAOTのどっちが早いってだけの話なのか？
876 ：デフォルトの名無しさん：2006/08/31(木) 01:36:29
なんか知ってるかもと思ったので質問。

Java6のHotSpotコンパイラでエスケープ解析が入るのが売りの一つらしい
けど、スタックにオブジェクトが積めるようになるとそんなに性能上がるの？

世代別GCならヒープへのオブジェクトの確保解放はたいしたコストじ
ゃないし、どうせ短寿命なら初回MinorGCでedenからさようなら〜なので、
なんかイメージつかないんだけど、ナニがどう軽くなるんでしょう？
877 ：デフォルトの名無しさん：2006/08/31(木) 01:43:02
ところで、JVMで動作するC言語の処理系だけど、既にあるよ
JVMで動作するっていうか、C言語 -> Java言語のプログラムへの
トランスレータだけど。C2Jでぐぐってみるといいと思う
878 ：デフォルトの名無しさん：2006/08/31(木) 01:45:47
>>875
静的コンパイルとHotSpotでどっちが早いというのがテーマなのかねえ…
「HotSpotコンパイル」の中身がどんな最適かなのかわからないことには、
なんともかんとも。
879 ：デフォルトの名無しさん：2006/08/31(木) 01:49:48
もしスクリプト言語作るなら、
個人的には数式処理・代数処理程度で、
それをevelする程度で十分なんですけど。

複素数や行列の独自表記ができたり、(a+b)^2と書けたり
多項式展開や因数分解できたりとかです。

Java VMで動くバイトコードコンパイラ、スクリプトコンパイ
ラ？を作る意義・動機と言うのは、そういう特定用途に特化し
た言語を作るのでもありということだと思うんですけど・・
880 ：デフォルトの名無しさん：2006/08/31(木) 03:49:03
C言語厨である>>841はなぜJava似のC++も使いこなせ
なかったんでしょう
881 ：デフォルトの名無しさん：2006/08/31(木) 03:50:11
>>844
Javaカードは、
住民基本台帳カード、
大日本印刷が作ったカード、
海外の国民健康保険カードに使われているよ

882 ：デフォルトの名無しさん：2006/08/31(木) 04:24:32
>>876
そりゃヒープに取らないで済めば、その分処理が軽くなるでしょう。
ヒープはGC含めてなんだかんだで競合が多いので、
C10Kな時なんかには効いてくる。object poolもしないで済む。
883 ：デフォルトの名無しさん：2006/08/31(木) 05:56:41
>>877

そのトランスレータ使える？　たった一行のCのプログラムもとんでもない量のJavaになるし、
ポインタ演算している所なんか、酷すぎる。
884 ：デフォルトの名無しさん：2006/08/31(木) 07:12:58
>>787
ちょw
まだアプリ間連携もまともにできないJavaなのにw
どうみてもやっと「アプリケーション構成を考えるようになりました」ってレベルだろ？
http://docs.sun.com/app/docs/doc/802-2112/6i63mn60p?l=ja&a=view
のデリゲートとか
http://docs.sun.com/app/docs/doc/802-2112/6i63mn62q?l=ja&a=view
のサービスにいつ追いつくのやらw
20年前のフレームワークに負けてるってはずかしくね？
885 ：デフォルトの名無しさん：2006/08/31(木) 09:15:02
>>828
> >>807
> >だから、nが大きくて、CPU毎に最適化したコードによる恩恵が十分得られる場合は、
> >>805のような動的実行コード生成をC, C++でもやればいいだけの話。
> >で、こういう手法は机上の空論じゃなく、多くの動画コーデックや
> >OSカーネル(ページクリアに使うmovntiとか)など、多くの場所で用いられているんだよ。
> if(SSE２命令が利用可能か？) {
> // SSE２命令を利用したインラインアセンブラによるコード
> }
> else {
> // SSE２命令を利用しないインラインアセンブラによるコード
> }
> これのどの辺りが動的実行コード生成になるのか説明してくれんか？
> 無知は怖いね。

無知晒し上げ
886 ：デフォルトの名無しさん：2006/08/31(木) 09:31:54
最近、各種OSは、
securityがらみでdata領域を実行出来なくする方向だけど、
JIT/HotSpotはそれじゃ困るやね。
887 ：デフォルトの名無しさん：2006/08/31(木) 10:01:01
>>883
.いや、たぶん実用にはならないだろうなあとは試してみて俺も思ったけど
まだそういう処理系は無いという前提で話が進んでいるように見えたので、
一応そういうものはあるということが言いたかっただけ
888 ：デフォルトの名無しさん：2006/08/31(木) 11:34:40
>>884
なんかcocoaとかで見る名前だね。
あたりまえか。

何でこれがSunにおいてあんだ？
889 ：デフォルトの名無しさん：2006/08/31(木) 11:44:02
>>885
ﾄﾞﾄﾈﾄ厨笑えるw
890 ：デフォルトの名無しさん：2006/08/31(木) 11:59:42
>>888
OPENSTEP
891 ：デフォルトの名無しさん：2006/08/31(木) 12:44:51
>>886
デフォルトが実行不可になるってだけで、
別途実行可能な領域を確保する方法は用意されている。
たとえばUNIX系ではmmap()にPROT_EXECフラグを付けて領域を確保すればいい。

というか、IA32アーキテクチャではNXビットがサポートされるようになったごく最近まで
PROT_EXECフラグの有無にかかわらず常に実行可能になっていたってだけで、
他のアーキテクチャでプログラムしていた連中にとっては今更って話だろうね。
892 ：デフォルトの名無しさん：2006/08/31(木) 15:09:33
Java6.0っていつリリースされるの？
893 ：デフォルトの名無しさん：2006/08/31(木) 19:36:00
>>888
これSunがSolarisにポートした幻のOPENSTEPのやつだな
俺リアルで使ってたけど、、
894 ：デフォルトの名無しさん：2006/08/31(木) 19:56:15
>>1の「分離」とかSockets Direct Protocol
はMustangで実現してなくないか？

dolphinで?
895 ：デフォルトの名無しさん：2006/08/31(木) 19:58:30
>>892
そのうち
896 ：デフォルトの名無しさん：2006/08/31(木) 20:45:38
That house?
897 ：デフォルトの名無しさん：2006/08/31(木) 21:11:58
次のjavaではインライン・アセンブラが出来るようなる
らしい・・・
898 ：デフォルトの名無しさん：2006/08/31(木) 21:49:05
>>892
Java6.0はリリースされない
リリースされるのはJava6
899 ：デフォルトの名無しさん：2006/08/31(木) 22:14:09
>>897
ネタだろうけど、あえて反応してみる。こんな感じか？

public class HelloWorld {
　public static void main(String[] args){
　　asm("getstatic java/lang/System.out:Ljava/io/PrintStream;");
　　asm("ldc \"Hello, World\"");
　　asm("invokevirtual java/io/PrintStream.println:(Ljava/lang/String;)V");
　}
}

しかし、もし仮に本当にJavaにインラインアセンブラが搭載されたとしても、goto
使えるくらいしか利点が無さそう…
バイトコードレベルでは、大した最適化もできんし、JITコンパイラの最適化を阻害する危険もあるしな
900 ：デフォルトの名無しさん：2006/08/31(木) 22:45:40
>>899

>>897はネタの匂いがするけど

それだったらJava標準でなくてもすでに誰かが
作ってそうだ。
Java 6ではそれと似たような方式でスクリプト言語をサポートしていたし。
結局、Jakarata OROと同じように文字列のエスケープは避けられないというわけで。
外部ファイルに置いた場合だけエスケープしなくて済むってほうが言語としてまともだね。
901 ：デフォルトの名無しさん：2006/08/31(木) 23:43:59
コンパイラサポートすんだから普通にやるんじゃないか。
902 ：デフォルトの名無しさん：2006/09/01(金) 00:06:39
>>892
2006年10月以降？
http://journal.mycom.co.jp/news/2006/08/31/340.html
903 ：デフォルトの名無しさん：2006/09/01(金) 06:18:20
>>902
ありがとう！
904 ：デフォルトの名無しさん：2006/09/01(金) 09:52:57
この秋といってたけど、１１月以降が濃厚だな。
905 ：デフォルトの名無しさん：2006/09/01(金) 11:13:19
Java6の魅力はＧＵＩまわりの強化くらいかね。

アノテーションが増えたって言うけど、どんなもんが増えた？

新たにGenerics対応したクラスも出る？
906 ：デフォルトの名無しさん：2006/09/01(金) 14:30:24
> JVMはどうやってガベコレを実装してるの？

JVMにはJava言語用に作られたGCがあるだけで、C言語には使えないよ。
907 ：デフォルトの名無しさん：2006/09/01(金) 14:41:41
>>906あんまり正確じゃないなその表現は。
908 ：デフォルトの名無しさん：2006/09/01(金) 15:37:41
いつになったら.NET並の速度になるん？
909 ：デフォルトの名無しさん：2006/09/01(金) 16:00:38
javaと.netは目指しているものが違うから同じように比べてもねぇ
910 ：デフォルトの名無しさん：2006/09/01(金) 18:50:50
>>908
CLR の仮想関数呼び出しは遅すぎで使い物にならないわけだが。

Pure Java と Pure C# なライブラリを比較すると
明らかに JVM >>>>>>>>>>>> CLR であることがわかる。
911 ：デフォルトの名無しさん：2006/09/01(金) 19:32:29
>>908
ドトネト並みっていってるが、
ドトネトだってJavaより遅いのは遅いぞ。
どっちもVM上で動いているんだから。

どっちも遅いんだし。

比べるならC/C++とのほうが重みがある。
ドトネトだとVMの性質がJavaと異なるし
得意分野、得意分野が微妙にことなる。
912 ：デフォルトの名無しさん：2006/09/01(金) 19:39:22
Java6 mustang = null;
Java5 tiger = new Java5();
tiger.swing++;
tiger+=derby;
tiger+=webServer;
Java6 mustang = (Java6) tiger;

こんな感じかな？
913 ：912：2006/09/01(金) 19:40:07
最初の一行いらないね。失礼。
914 ：デフォルトの名無しさん：2006/09/01(金) 20:48:22
NETが日本で最も普及しているプログラム言語
http://pc8.2ch.net/test/read.cgi/tech/1156986942/
915 ：デフォルトの名無しさん：2006/09/01(金) 21:17:57
>>912
Java5型はオブジェクトの型なのか文字列型なのか数値なのか

どっちみちString型の猿まねはできないし++や+=を使えるのは
Stringオブジェクトか数値型だけなのでエラーになるわな。
916 ：デフォルトの名無しさん：2006/09/01(金) 21:18:20
>>914
つまらんし、根拠がない
917 ：デフォルトの名無しさん：2006/09/01(金) 21:28:45
>>915
オペレータオーバロードｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━�!!!!
918 ：デフォルトの名無しさん：2006/09/01(金) 21:51:25
>>911
わからないでもないが、同じバーチャル・マシンという環境で比べた方が公平だと思うぞ
Cはネイティブ・マシンだろ
またガベコレがどうしたこうしたとかなのか？
919 ：デフォルトの名無しさん：2006/09/01(金) 21:52:39
ネイティブ・マシン……
920 ：デフォルトの名無しさん：2006/09/01(金) 22:02:58
そういや、Stringには++使えないんだった。
つーかJavaに演算子オーバーロードなんて期待すべきでないし
勧めるべきじゃない。
C++の二の舞になったC#と同じ道を歩む。
あれは大失敗だった。
921 ：デフォルトの名無しさん：2006/09/01(金) 22:05:07
>>918
同じVMといってもな、VMは各種ベンダによって速度が異なるし。
IBMが作ったのとSunが作ったのとではJVMの速度やライブラリによる速度も変わってくる。

その辺りも厳密に考えないと逝けない。

そう考えると、面倒だし議論するだけ無駄だと思うんだが。


そういう比較は、こだわると、FFとドラクエとを比較するくらい実にくだらない議論になると思うよ。

922 ：デフォルトの名無しさん：2006/09/01(金) 22:20:11
>>921わかってるじゃん。
923 ：デフォルトの名無しさん：2006/09/02(土) 00:26:08
>>905
1.2〜1.4のようにデスクトップアプリが大幅にパワーアップするようなのはあんまりなさそうだ

5.0以降デスクトップに力入れてますといってるけど、小粒なのが多くて
むしろ力入れてないのではと思いたくなる
924 ：デフォルトの名無しさん：2006/09/02(土) 02:48:50
public class Java6 extends Java5{

Swing swing = getSwing().add(new AntiAlias());

DB db = new Derby();

public Java6() throws NotReleasedException{
try{
openSource();
}catch(Exception e){
log.error("やっぱり無理だった");
}
throw new NotReleasedException("もうちょっとまって");
}

}
925 ：デフォルトの名無しさん：2006/09/02(土) 03:40:53
しかし.NETのCLRが「速い」というのは初めて聞く意見なんだが、
なんか速くなったのか？ ずっと「遅い遅い」と言われ続けてたと
思うんだが。
926 ：デフォルトの名無しさん：2006/09/02(土) 10:27:07
>>920
演算子のオーバーロードは便利だよ。演算子オーバーロードじゃなくても、
クラスごとに演算子の動作を定義できるのは便利。
C＋＋のはいけてないけど、pythonのように、演算子ごとに対応するメソッドを
用意する方法ならわかりやすいし、実装も簡単（コンパイラに手を入れるだけで済む）。

Javaユーザは、Javaにない機能はすぐに「あんなものイラネ」とかいいだすから嫌い。
927 ：デフォルトの名無しさん：2006/09/02(土) 10:38:16
>>926
> Javaユーザは、Javaにない機能はすぐに「あんなものイラネ」とかいいだすから嫌い。
激同
で、いらないっていいながらJavaに実装されるといきなりﾏﾝｾｰし始めるからもっと嫌い。
Javaは好きだがJavaをまともに使えるのはほんの一握り。大抵は基礎の無い阿呆ばっかだ。厨の割合が高過ぎる。
928 ：デフォルトの名無しさん：2006/09/02(土) 10:40:06
少なくともBigなんちゃらや日付時間関係は演算子使いたいよな
文字列だけ砂糖付きはずるいぞ
929 ：デフォルトの名無しさん：2006/09/02(土) 11:06:01
> 厨の割合が高過ぎる。

そういう業界だろｗ
930 ：デフォルトの名無しさん：2006/09/02(土) 11:30:59
>>928
BigDecimalが対応されたらクライアント用でも業務系での地位は確定するな
931 ：デフォルトの名無しさん：2006/09/02(土) 12:11:19
>>926
>>927
そんなもの別にJavaユーザに限った話じゃないでしょ。なんですぐにそういう話になるかなあ
C++ユーザだってよく、Javaに対して、GCなんてイラネとか言っているのは耳にする
ある程度普及した言語には、厨や信者が一定割合でつくというだけの話だと思う
932 ：デフォルトの名無しさん：2006/09/02(土) 12:17:23
>>926
演算子っつーと、[] も演算子だよな。
数値計算しないから + や - のオーバーライドはできなくても個人的には困らんけど
MapやListで list.get(0) や map.get("key”) が list[0] や map["key"] と書けるようになるとうれしいなあ。
933 ：デフォルトの名無しさん：2006/09/02(土) 12:30:06
listのほうは難しい気がするがmapのほうは現行の構文とかさならないからできそうな気がするんだけどね

とおもったけどキーがIntegerとかでintわたしてオートボクシングとかされると配列とみわけがつかんか
934 ：デフォルトの名無しさん：2006/09/02(土) 13:41:26
>>926-927
大丈夫か？MSや.Netマンセーなのか？
例えば、そんなのオレは面倒とかを除けば、
やってる事は同じなんだけど、そういうの気がつかないのかな。
プロパティとかインデグザとか。
delegate, eventはいいね。なんともMSらしい。
935 ：デフォルトの名無しさん：2006/09/02(土) 13:45:56
コンパイラをいじれば、
いつでもできるんじゃないの。
ただ実質同じことだし、
そういう要求をかなえてまで、
面倒くさいぞー系の蛆が溢れると、
Javaの品質が下がるからまだ今もやらないってこと。
936 ：デフォルトの名無しさん：2006/09/02(土) 17:43:09
>>926
Genericsは、「あんなものイラネ」と言われたことないよ。
937 ：デフォルトの名無しさん：2006/09/02(土) 17:46:46
>>936
Genericsイラネ
938 ：デフォルトの名無しさん：2006/09/02(土) 17:50:21
>>937
C厨
939 ：デフォルトの名無しさん：2006/09/02(土) 17:58:10
>>933
なんでlistだと難しいのかくわしく。
940 ：デフォルトの名無しさん：2006/09/02(土) 17:58:15
JavaもtoStringは演算子オーバーロードできるしな

例えばインタフェースベースの演算子オーバーロードなら
interface Calculateableみたいなのを用意して
Numberと同じメソッド定義しておけば、目的を見失うことも無いだろう。
941 ：デフォルトの名無しさん：2006/09/02(土) 18:04:28
>>939
配列と区別がつかないからだろ
942 ：デフォルトの名無しさん：2006/09/02(土) 18:33:17
個人的には言語仕様の拡張はしなくてもいいから
VMの性能とデスクトップ周りの強化をしてほしいな・・・
943 ：デフォルトの名無しさん：2006/09/02(土) 18:36:08
>>942
それは着々と進んでるだろ。
944 ：デフォルトの名無しさん：2006/09/02(土) 20:03:27
>>941
区別はつくよ。むしろなんで区別がつかないと思うのか聞きたいところだ
945 ：デフォルトの名無しさん：2006/09/02(土) 20:26:27
128bit Java
946 ：デフォルトの名無しさん：2006/09/02(土) 20:45:46
>>926
おまえは何も解ってない。
ストラウストラップが警告した事項を
947 ：デフォルトの名無しさん：2006/09/02(土) 20:45:57
>>944
もちろんコード全体を見りゃ区別はつくさ
objs[i]と書いてあるときにobjsは配列かListか
すぐには判断できない場面があるわけだ
両者が共通の性質やAPIを持つなら区別できなくても問題ないけどな
実際には配列は固定長だし、APIもlengthでサイズを知るなど異なるわけ
配列を廃止するならともかく両立させるのは混乱の元
948 ：デフォルトの名無しさん：2006/09/02(土) 20:47:03
>>926-927は同一人物による書き込みだよな
949 ：デフォルトの名無しさん：2006/09/02(土) 20:48:17
>>932
[]は単項演算子みたいなもんだからいいんだよ
+や-となると２項演算子なので
演算子の優先順位を意識するのが大変になるんだよ。
それに他人が作った奴の演算子が混ざったらどうなると
思ってるのか。
950 ：デフォルトの名無しさん：2006/09/02(土) 20:49:15
>>932
> MapやListで list.get(0) や map.get("key”) が list[0] や map["key"] と書けるようになるとうれしいなあ。
その程度のことのためだけにそんな演算子を付加するのか。
C#のget/setと変わらないくだらん機能だな
951 ：デフォルトの名無しさん：2006/09/02(土) 20:52:14
>>940のやり方なら間違った演算子定義は出来ないからいい。
問題があるとすれば右辺値の一番左の値がプリミティブじゃなかったときくらい。
952 ：デフォルトの名無しさん：2006/09/02(土) 21:28:30
>>942
俺的には、Java3Dの強化をなんとかして欲しいな。
953 ：デフォルトの名無しさん：2006/09/02(土) 21:29:01
>>947に激しく同意できる。
C++の二の舞になったら終わりだ
954 ：デフォルトの名無しさん：2006/09/02(土) 21:30:17
統合アーカイバプロジェクト並みの圧縮ファイル対応とか
デスクトップ周りでやらなきゃいけないことは、まだまだ沢山あると思う
デスクトップ周り専門のApacheみたいなグループが登場しないと無理だが
955 ：デフォルトの名無しさん：2006/09/02(土) 21:33:18
BigDecimalで演算子を使えるようにしてくれって要望は、
BigDecimalクラスをラッパークラスとするプリミティブなbigdecimal型を
用意するっていうC#のdecimal型でどうにかするって手もあるが、
あれは、128bits限定だからな。

BigDecimalのコンストラクタにMathContext.DECIMAL128を設定した
精度しか得られないしな。
956 ：デフォルトの名無しさん：2006/09/02(土) 21:34:11
>>954
圧縮ファイルで一体何をしたいんだ？
つか、Jakarta Commonsにそれっぽいのないか？
もしくはSourceForgeにありそうだが
957 ：デフォルトの名無しさん：2006/09/02(土) 21:39:17
何がしたいって聞くようなことか？
958 ：デフォルトの名無しさん：2006/09/02(土) 21:41:01
Commons Compressだったかがβすら出ずに存在したような気がする
959 ：デフォルトの名無しさん：2006/09/02(土) 22:24:20
>C#のget/setと変わらないくだらん機能だな
Java7の拡張の候補にプロパティが入っているのだけどな。
960 ：デフォルトの名無しさん：2006/09/03(日) 00:04:24
入ってたとしても、C#と全く同じってことはなかろうと予測
961 ：デフォルトの名無しさん：2006/09/03(日) 00:27:08
>>959それどこの記事でわかるの？
962 ：デフォルトの名無しさん：2006/09/03(日) 00:32:42
>>959がデマだったりすることはよくある。
あの文体は、いつものJavaスレを荒らしてるドトネト厨だから。
3年も4年も前からJavaスレや死滅スレで大暴れしてる変態。
963 ：デフォルトの名無しさん：2006/09/03(日) 00:35:56
やっぱりドトネト棒ってハズレだったんだね。
コーヒーの方が大人だね。
964 ：デフォルトの名無しさん：2006/09/03(日) 00:42:45
>>961-963
まずこのスレを「プロパティ」で検索してみたらどうなんだ？
965 ：デフォルトの名無しさん：2006/09/03(日) 00:45:38
ttp://journal.mycom.co.jp/articles/2006/05/18/javaone3/
にしっかりと「プロパティのサポート」が発表されたと書いてあるんだが。。。

プロパティサポートといっても、それがget/set生成みたいなもの
なのか、式言語みたいに「obj.property」というようにアクセスできる
ようにする、という意味なのか、groovyの「@Property」みたいに

@Property size

とか宣言できるようにするのか、といった具体的な話はまったくない
わけだけど。
966 ：デフォルトの名無しさん：2006/09/03(日) 00:48:13
>>962
>>963
こういうやつらっていつになったらJavaの世界から消えてくれるんだろ
967 ：デフォルトの名無しさん：2006/09/03(日) 01:05:16
>>963
ドトネト棒って語呂と名前がｳｹﾙw
968 ：デフォルトの名無しさん：2006/09/03(日) 01:08:17
>>965
その、アノテーションっぽい気がした。
@Propertyならいいねえ。
get/setはねえちょっと。
getter.setterに相当するメソッドに
@Propertyアノテーションをつけるのが妥当って感じだね。
969 ：デフォルトの名無しさん：2006/09/03(日) 03:11:05
>>967それも棒の先には「おまえらは、ハズレ」って書いてあるんだろうだしｗｗｗ
970 ：デフォルトの名無しさん：2006/09/03(日) 10:27:31
>>946
「ストラウストラップが警告した事項」って具体的に何？

>>947
おいおい、Javaは静的な型があるんだから、別にコード全体を見るまでもなく、変数の宣言部分をみれば配列かListかはすぐに判断できるし、別に混乱なんかしないだろ。
この程度で混乱なんかしないでくれよ。

>>949
[]は単項演算子じゃなくて、+や-と同じ２項演算子だよ。
それに演算子の動作を自分で定義できることと、演算子の優先順位は関係ないよ。
PythonもRubyも演算子の動作を自分で変えられるけど、優先順位は変えられない。だから別に混乱しない。

>>950
でもELでは[]でアクセスできるようになってるよね。「その程度」のことであれば、
ELでも[]でなくてgetter/setter使えばいいはずだし、もっといえばEL自体必要ない。
Javaユーザは「[]なんてイラネ」といっておきながら、ELの[]は便利とかぬかすから嫌い。
971 ：デフォルトの名無しさん：2006/09/03(日) 10:39:13
>>970
言っている事自体はだいたいまともだが

> Javaユーザは「[]なんてイラネ」といっておきながら、ELの[]は便利とかぬかすから嫌い。

とJavaユーザを一緒くたにして煽るのはやめてくれ。ELの[]が便利と言っている層とJavaには[]は
イラネと言っている層がどれくらい重なっているのか調べたわけでもないだろう？
972 ：デフォルトの名無しさん：2006/09/03(日) 10:43:14
そもそもJSP上でaddなんてしないんだから[]で何の問題も無いだろ
粘着にレスすんなよ
973 ：デフォルトの名無しさん：2006/09/03(日) 11:30:35
>>970
いっとくが、JavaとELとは全く別の言語だ。
Javaユーザが[]はイラネといってるのはJavaの文法にいらねといってるだけで
ELの文法に[]がいらねといっとるわけではなかろう。

そんなこともわからないでJavaエンタープライズアーキテクトを侮辱するとは
身の程知らずもいいところだ。
974 ：デフォルトの名無しさん：2006/09/03(日) 11:50:25
JavaとELとが別言語なんてのはだれだってわかってる。
だからなんでわざわざELなんて用意されたかを考えろや。
Javaそのままだと書きにくいからELが用意されたんじゃないの。
Javaの書きにくさのひとつとして list.get(1) や map.get("key") があり、
これが list[1] や map["key"] とかけたらいいなといってるだけ。
ほんとうにlist.get(1)やmap.get("key")が書きやすい/読みやすいなら
ELでもそれをつかえばいいだけ（ELにはメソッド呼び出しないけど）。
「JavaとELとが別言語」なんて話がずれるだけじゃん。
975 ：デフォルトの名無しさん：2006/09/03(日) 12:13:34
>>971
> とJavaユーザを一緒くたにして煽るのはやめてくれ。

一緒くたにしている馬鹿には馬の耳に念仏では?

976 ：デフォルトの名無しさん：2006/09/03(日) 13:45:49
http://pc8.2ch.net/test/read.cgi/tech/1157227790/

次スレ
977 ：デフォルトの名無しさん：2006/09/03(日) 14:06:08
>>970
ストラウとラップは演算子のオーバーロードを
誤った使い方をするとろくなことがないぞってことを言ってるんだよ。
誤った使い方をしなければいいといっても
誤った使い方をする奴は腐るほどいるし。
それで複数の会社組織が独自に演算子を定義して
デスマって酷いことになるわけだ。
978 ：デフォルトの名無しさん：2006/09/03(日) 14:07:23
>>974
じゃあさ、お前にはなんでJakarta Velocityみたいなのが
用意されたのかわかるの？

プリプロセッサではなくVelocityが用意された理由を。
979 ：デフォルトの名無しさん：2006/09/03(日) 15:24:48
[]のオーバーロードは欲しいな。
980 ：デフォルトの名無しさん：2006/09/03(日) 15:35:42
ListだったらどうせIterator経由でアクセスしない？
List.getなんて滅多に使わなくないか？
981 ：デフォルトの名無しさん：2006/09/03(日) 17:07:07
んだな
982 ：デフォルトの名無しさん：2006/09/03(日) 17:47:33
しかもIteratorにはfor(:)の砂糖が既に入ってるしな
983 ：デフォルトの名無しさん：2006/09/03(日) 19:27:06
うむ、そうだ
984 ：デフォルトの名無しさん：2006/09/03(日) 20:02:49
次世代は無糖でｗ
985 ：デフォルトの名無しさん：2006/09/03(日) 20:23:27
new ArrayList=("あああ","いいい","ううう");
みたいに出来んかな。

public ArrayList(String... varArgs);
こんな感じのコンストラクタで。
986 ：デフォルトの名無しさん：2006/09/03(日) 21:05:54
>>985
それもだけど、
ArrayList#addAll(Collection<? extends E> c);も、
c.toArray();で配列に直してから使ってる。
ArrayList#addAll(E[] c);がないのはもったいない。

987 ：デフォルトの名無しさん：2006/09/03(日) 21:46:14
>985
Arrays.asListでいいんでないの？
988 ：デフォルトの名無しさん：2006/09/03(日) 21:55:40
あーたしかにコレクションをパっとつくりたいと思ったことはあるな。
とくにテストコードで。
今だと
List strList = Arrays.asList( new String[]{"test1", "test2"});
とかやっててくどいとは思う。

一方で、Javaの、文法はシンプルに、機能はクラスライブラリで、という
スタンスは嫌いじゃない。文法拡張するときは「そんな砂糖いらね」という
抵抗があったほうがちょうどいいと思うぞ。やたら拡張するよりはね。
989 ：デフォルトの名無しさん：2006/09/03(日) 23:11:48
>>987
確かに5.0のArrays.asListは
　public static <T> List<T> asList(T... a)
だからまあ悪くないんだが、返ってくるのが変更不能リストなのがイマイチ
変更可能リストを返すメソッドが欲しいな。コードはこんな感じで
public class ListUtil {
　public static <T> List<T> list(T... a){
　　List<T> newList = new ArrayList<T>();
　　for(T t : a) newList.add(t);
　　return newList;
　}
}
使うときはstatic import使えば、
list("A", "B", "C", "D")
のようにするだけで変更可能なリストが作れるので便利
990 ：デフォルトの名無しさん：2006/09/03(日) 23:21:03
>>985
まるでPerlやPHPまんまだな
991 ：デフォルトの名無しさん：2006/09/03(日) 23:24:05
>>989
それもPHPまんまやないか
992 ：デフォルトの名無しさん：2006/09/03(日) 23:32:02
>>991
意味不明。PHPで、array(...)などとして配列が作れることを言っているつもり？
そんなもん別にPHP(やPerl)独特のものでもなんでも無い。
なんで厨はすぐに自分の知っている(好きな)言語の機能のパクリかのように言いたがるかなあ
993 ：デフォルトの名無しさん：2006/09/04(月) 00:30:14
なになに、どっちにしろ型の概念が曖昧な
スクリプト言語に共通する書き方だよな
994 ：デフォルトの名無しさん：2006/09/04(月) 00:52:40
>>980
for( : )使うことが多いけど速度の差も結構あるし
何番目かを意識したりループの中で挿入とか削除とかもある
for( : ) 使うのが80％くらいかな
995 ：デフォルトの名無しさん：2006/09/04(月) 01:05:58
O'Camlなみに型推論しる！
996 ：デフォルトの名無しさん：2006/09/04(月) 03:09:08
あのー・・・
997 ：デフォルトの名無しさん：2006/09/04(月) 07:23:57
>>989
Arrays.asListってlistの様に振る舞うけど、
結局は配列のままのwrapper返すんじゃないの?
998 ：デフォルトの名無しさん：2006/09/04(月) 07:32:05
>>997
確かそう。
これをArrayListに追加するときは、>>986のようにまた配列にもどして使うのでもったいない。
999 ：デフォルトの名無しさん：2006/09/04(月) 08:09:13
>>989
new LinkedList(asList(a, b, c, d))
でいいやん。
1000 ：デフォルトの名無しさん：2006/09/04(月) 08:17:59
asXxxはビュー(実態は変わらず見方を変えたもの)を返す、ってことだな。
1001 ：１００１：
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。