Cから虎へ～JDK1.5について！Part2

1 ：デフォルトの名無しさん：04/03/16 20:58

比較上等！

前スレ
http://pc2.2ch.net/test/read.cgi/tech/1056807119/l50

2 ：デフォルトの名無しさん：04/03/16 21:04

華麗に削除依頼

3 ：デフォルトの名無しさん：04/03/16 21:15

あれほど半角#には気をつけろと･･･

4 ：デフォルトの名無しさん：04/03/16 21:18

誰か立て直してくれ。

C＃から虎へ～JDK1.5について！Part2

5 ：デフォルトの名無しさん：04/03/16 21:19

いいよ。ここが本スレで。

6 ：デフォルトの名無しさん：04/03/16 21:21

じゃあ、そうするか

7 ：デフォルトの名無しさん：04/03/16 21:43

>>1晒し上げしていいですか？

8 ：デフォルトの名無しさん：04/03/16 23:38

j2se1.5β
http://java.sun.com/j2se/1.5.0/index.jsp

eclipse3.0
http://download2.eclipse.org/downloads/drops/S-3.0M7-200402122000/index.php
(Platform Runtime Binaryをダウンロード）

JAVAとC#の比較
http://objectclub.esm.co.jp/cs-vs-java//cs-vs-java.html

J2SE1.5の新機能
http://www5.airnet.ne.jp/sakuraba/java/laboratory/J2SE1.5/contents.html

C++とJavaの総称
http://www.mamezou.com/tec/Tips/javaGenericsVsCppTemplate/

JavaGenerics概説
http://objectclub.esm.co.jp/JavaGenerics/

9 ：デフォルトの名無しさん：04/03/16 23:40

とりあえず、LinuxユーザーはJavaを使えばいいんでないかと。

それから
AWTとSWINGとSWTの区別がついてない人がいるみたいですが
注意と。

10 ：デフォルトの名無しさん：04/03/16 23:41

j2se1.5beta(日本語サイト)
http://java.sun.com/j2se/1.5.0/ja/index.html

11 ：デフォルトの名無しさん：04/03/16 23:44

J2SE 1.5 の重要な特徴です。
・新しい言語拡張:メタデータ、ジェネリック型、列挙型、プリミティブ型の Autoboxing
・新しい JVM 監視および管理 API
・改善された out-of-box パフォーマンス
・新しい (互換性のある) デフォルト Java Look & Feel

http://java.sun.com/developer/technicalArticles/releases/j2se15/

12 ：デフォルトの名無しさん：04/03/16 23:51

out-of-boxってなんですか？

13 ：デフォルトの名無しさん：04/03/17 00:00

個人的には、Javaコードでプロファイリングを織り込めてしまうの
がありがたいな。

14 ：デフォルトの名無しさん：04/03/17 01:01

Enhanced for loopって
iterator()のあるクラスじゃないと使えない？

15 ：デフォルトの名無しさん：04/03/17 01:08

なんでCだかC#なんだ？

かえってC#厨が邪魔しにくるだけじゃないのか？

16 ：デフォルトの名無しさん：04/03/17 01:13

WebSphereでの正式対応がおそらく3年後なので、はっきり言ってどうでもいい＞ JDK1.5

17 ：デフォルトの名無しさん：04/03/17 01:55

>>14
配列も使える

18 ：デフォルトの名無しさん：04/03/17 02:14

ていうかなんでC#が関係あるんだYO!
C#厨が立てたスレかYO!　

19 ：デフォルトの名無しさん：04/03/17 02:16

JDK1.5なんで死語だろ
J2SE1.5だろ

それとＣは関係ないだろ。

スレ立て直しだろ。
J2SE1.5についてだけ語るスレにするべきだ。

さもないと前スレのようにC厨とかC#厨とかがスレを荒らすのでウザイ。

20 ：デフォルトの名無しさん：04/03/17 02:30

隔離スレ認定

21 ：デフォルトの名無しさん：04/03/17 02:43

　　　　　　　　　　　　　;∵;,".　　;；∴”:ﾟ・,'.ﾟД;∵ζ;,".
　　　　　　　　　　　　　　　　　;∵;,".;；∴”:ﾟ,'.　　）;∵;,".
　　　　　　　　　　　　　　　　　　;∵;,".　 /　　　ヽ
　　　　　　　　　　　─　＿-　 ;∵;,".　 ./　　 /| ..|
　　舞えやぁ！　　　-─_｀;,　　　　　/ 　　 | ..| │←>>C#＆Anders Hejlsberg
　　　　　　　　　　　　ヽ　ゝ　　″　／ |　　| ..|　|
　　　　　　　　　　　　 .|　 │　∵;／　／|　│　巛
　　　　　∧　∧　　　　|　　|　／　／　 |　 .| 　　　　　
　　　　（　ﾟ∀ﾟ）､　　　/ 　 /⌒　／　　.｛　│
　　　＿」＿ノ　丿　 /　. /　　　　　　　 |　 |
　　（＿_＿＿／ヽノ　 ./ 　　　　　　　（　　）
　／　／＼　　　　　/　　　　　　　　　￣
(＿／　　 ..＼　　 /ノ
　　　　　　　|　　 |
　　　　　　 /　　/
　　　　　　../　　/
　　　　／　／
　　　／　／
　 .　（＿_ノ
　　　　　　　　　　　　　　　　　　──────────
────────　　　　　　　　　　──────

22 ：デフォルトの名無しさん：04/03/17 02:44

C#厨はバカばっか。Java以外の言語は全て糞。

23 ：デフォルトの名無しさん：04/03/17 02:51

そうやってJava厨のフリして自作自演して
「Javaしかできない奴って(ry」とか言うんだろC#厨。
嫌な奴。

24 ：デフォルトの名無しさん：04/03/17 02:53

巷の企業の不正、例えば雪印、また道路公団なんてものを見てれば判るが、
内部告発、セルフフィードバック、自己批判がゆるいのはその組織、集団に
勢いが無い証拠。適正な外圧が加われば長くはもたない。
あと、外部の批判に感情的ってのもあるな。
身に覚えのある痛いところを突かれそうな組織ほど、マスコミの取材はさけるし、
オーム信者でもなんでも見てたらわかるだろ？よーするに身内でオナニーできればそれでいい。

25 ：デフォルトの名無しさん：04/03/17 02:55

>WebSphereでの正式対応がおそらく3年後なので
ベータでよければ、もう対応してるけど・・・

26 ：デフォルトの名無しさん：04/03/17 03:00

しょうがねえ。このスレでJ2SE1.5の話題をしろってのかよ。。。。。。。。。。。。。。

いっちょいったるか。

1.5でjava.util.concurrentがでたってことは

ＯＳの仕組みを復讐しないとあかんのか。

瀬間ふぉとかミューテックスとか

27 ：デフォルトの名無しさん：04/03/17 03:02

・JavaができればC#はできるし
・C#ができればJavaはできる
・CとJava(C#)ができれば、C++ができる
・C++ができれば、CとJava(C#)ができる
この関係が崩れてるやつは、言語を習得できてない

28 ：デフォルトの名無しさん：04/03/17 03:02

セマフォもミューテックスも
シンクロナイズと変わらないと思うけど。
つまり、OSの仕組みを復習する必要はない。

29 ：デフォルトの名無しさん：04/03/17 03:07

>>27
しかしその三つの言語知っているだけでは何かが足りない。
そうだ！　Prologだ！ Lispだ！ Perlだ！
ってか。

30 ：デフォルトの名無しさん：04/03/17 05:33

今日本屋いったらJavaとEclipseの本を読んでるオタ風不細工メガネデブの隣で
かわいい女の子がVB.NETの本を熱心に読んでたよ。
なんか時代は変わったと思ったね。

31 ：デフォルトの名無しさん：04/03/17 09:49

>>30
コピペ厨ウザイから荒らすな

32 ：デフォルトの名無しさん：04/03/17 09:50

perlはいらないよ

33 ：デフォルトの名無しさん：04/03/17 10:23

J2SE1.5から
今までGenericsでなかったクラスがいくつかGenericsになるわけか

34 ：デフォルトの名無しさん：04/03/17 10:44

まあ、C#に比べたら真のgenericsじゃないけどね。(ｹﾞﾗ

35 ：デフォルトの名無しさん：04/03/17 10:44

それは逆だと思うけど。

36 ：デフォルトの名無しさん：04/03/17 10:52

リフレクションでgeneric typeかどうかも分からない糞仕様なんて･･･

37 ：デフォルトの名無しさん：04/03/17 11:17

そんなもん仕様の問題じゃないし。
APIがまだ実装されてないだけじゃね？

38 ：デフォルトの名無しさん：04/03/17 11:27

http://www.artima.com/intv/generics.html
JavaとC#のgenericsについて、ヘジが語ってる。

どうもあれだな。
Javaは様々な機能を独自のやり方で取り入れて行ってる。
C#は、昔のJavaからスタートして、C++っぽい考え方で仕様を拡張して行ってる。
ってな感じがする。

ヘジはJavaの欠点ばかり指摘しようとしてるが(っつーかJava対抗だから当たり前だが)、
俺はC++臭のするgenericsよりも、シンプルでwild cardが使えるgenericsの方が好きだな。

39 ：デフォルトの名無しさん：04/03/17 11:35

>>36
JavaでもC#でもわかるけど・・・C++のことか？

40 ：デフォルトの名無しさん：04/03/17 12:24

ヘジルスとゴスリングとでは
知識の幅の広さの違いが感じられる。
プログラミング経験量の違いもでているんだろうか。

41 ：デフォルトの名無しさん：04/03/18 17:22

ところでgenericとか誰が必要としてるの？

42 ：デフォルトの名無しさん：04/03/18 17:29

JDK1.5なんて必要ありません
genericsも必要ありません
enumも必要ありません
boxingも必要ありません
foreachも必要ありません
IDEも必要ありません
進歩したら学習コストがかかるからね

43 ：デフォルトの名無しさん：04/03/18 18:16

Vector< T extends X >って構文の意味がわからんよ。
Vector< X >では駄目なんか？
また、newのある意味がわからんよ。
daleteが無いんだから、別にnewが無くても構成上支障は無いはず。

44 ：デフォルトの名無しさん：04/03/18 18:23

タイガーだのパンサーだの、負け組みにはネーミングの共通点があるのか？
おそらく押さえ込まれてるのを無意識にでも自覚しているので、文字通り
虎の威をかる狐になっちゃうのかな？

45 ：デフォルトの名無しさん：04/03/18 18:28

>>44
最後の一行が言いたかっただけ、と読んでみました。

46 ：デフォルトの名無しさん：04/03/18 18:29

>>45
いや書きながら思いついて自然とそうなったよ。
むしろ何かパンサーと似てるなとか思ったから。

47 ：デフォルトの名無しさん：04/03/18 18:40

翔って名前つける親はDQNが多い。
親は自分が社会的に地味なので、子供に派手な名前をつけて希望を託す。
名は体を表すと言うが、地に足がついてないような名前はどうかね？龍とかさ、わからんでもないが。
MSとかAMDなんか地名が多いよね、雪山の名前とか都市名とか。
ところで次のJDK1.6のコードネームってなに？

48 ：デフォルトの名無しさん：04/03/18 20:47

>>47
借りて来た cat.

49 ：デフォルトの名無しさん：04/03/18 22:17

>>41
j2se1.5β
http://java.sun.com/j2se/1.5.0/index.jsp

eclipse3.0
http://download2.eclipse.org/downloads/drops/S-3.0M7-200402122000/index.php
(Platform Runtime Binaryをダウンロード）

JAVAとC#の比較
http://objectclub.esm.co.jp/cs-vs-java//cs-vs-java.html

J2SE1.5の新機能
http://www5.airnet.ne.jp/sakuraba/java/laboratory/J2SE1.5/contents.html

C++とJavaの総称
http://www.mamezou.com/tec/Tips/javaGenericsVsCppTemplate/

JavaGenerics概説
http://objectclub.esm.co.jp/JavaGenerics/

50 ：デフォルトの名無しさん：04/03/19 00:45

>>42
かかんねえよ。
foreachあんんて滅多につかわないし
enumはシンプルで重宝するし。
学習コストはgenericsと真APIだけだろ
それでもかなり有益だが。

51 ：デフォルトの名無しさん：04/03/19 00:48

>>47
それって日本語に訳してるだけじゃん。

ＡＭＤのCPUもわざわざ日本語に訳して解釈するのかい？
Thunderbird → 雷鳥
Barton → 豚
ムスタング　→　馬

とか

52 ：デフォルトの名無しさん：04/03/19 02:09

>>51
噛み合ってない？

53 ：デフォルトの名無しさん：04/03/20 14:53

げねりくそめちゃ便利だ

foreachとか使いまくってるけど。

てか、今まで作ったコード書き直してるんだけど
これがすごい大変なんだな（泣）

54 ：デフォルトの名無しさん：04/03/20 15:30

>>53
　後方互換性あるのだから、とりあえず新規分だけ使えばいいのでは？
　キャストしてバグでていないなら、Generic 使って書き直す価値は無い。

55 ：デフォルトの名無しさん：04/03/20 15:37

じぇねりっくよりｅｎｕｍだよなぁ
既存のコード買えてまでなおしたくなるのは

56 ：デフォルトの名無しさん：04/03/20 15:39

じゃばよりC#だよなぁ
既存のコード捨ててまでいこうしたくなるのは

57 ：デフォルトの名無しさん：04/03/20 16:39

じゃばより漁師だよなぁ
既存の生活捨ててまでいこうしたくなるのは

58 ：デフォルトの名無しさん：04/03/20 21:51

もちろん、書き直す必要はないけど
せっかくげねりくそあるから書き換えたくなるじゃん。

まじで便利だよ。
C#もいいけど、りなくそで使いたいからさ。

59 ：デフォルトの名無しさん：04/03/20 22:07

Ｇｅｎｅｒｉｃｓ使うからといってコードをすべて書き換えなくちゃならない理由はないだろ

60 ：デフォルトの名無しさん：04/03/20 23:26

Javaがどんどん汚されていくな
もう余計な構文糖の追加はいらんよ

61 ：デフォルトの名無しさん：04/03/20 23:44

>>60
そんな貴方に BrainFuck

62 ：デフォルトの名無しさん：04/03/21 00:33

>>60
そうでもなさげ。
JavaでC++のtempalteが使えるGenericsがでると聞いたときは
ショッキングでまさかと思ったがよく調べてみたら
C++のtempalteほど汚くはならなかった。
C++のような危険な使われ方をせずに済みそうだ。

63 ：デフォルトの名無しさん：04/03/21 00:36

型キャストなくす”だけ”しかできないGenericsなんてｲﾗﾈ。
俺も最初はC++のtemplateがJavaでも使えると思って期待したけけどさ。

64 ：デフォルトの名無しさん：04/03/21 01:33

型強化のためでしょ？

テンプレートのようなぐちゃぐちゃを目指した訳じゃないから
ｊａｖａの方向性としてこれでいいんじゃないの？

65 ：デフォルトの名無しさん：04/03/21 02:53

>>59
キャストがめっさ減る
そして美しいソースコードへ変貌する
だから、どうしても書き直したくなる

66 ：デフォルトの名無しさん：04/03/21 07:47

>>63
キミ自身がリアクション取らなかったんだからしょうがないでしょ。
少なくとも1999年に generics の案が JCP に出た後、5年間もあったし、
その前からも議論はあったわけで。

生簀の魚みたいに口開けて待ってるだけだと損するよ。

67 ：デフォルトの名無しさん：04/03/21 10:38

>>63
それだけじゃあねえだろ。
おかげでtypesafe Enumとか可変長引数とかを使いやすくなったのだから。

C++のtemplateのようなリスキーな機能はバグばかり出すプログラミングが横行するからイラネ

68 ：デフォルトの名無しさん：04/03/21 10:41

>>66
なにげに、J2SE1.5の仕様策定でJCPが下した決断は正しいと思うな。
ジェームズゴスリングは目先の利便性よりもあとあとの問題の対応で困らないように慎重に慎重に検討しているようだ。

69 ：デフォルトの名無しさん：04/03/21 11:43

java,c++初心者ですが

>型キャストなくす”だけ”しかできないGenericsなんてｲﾗﾈ。
他に何ができるんでしょうか？
何個くらいありますか？

70 ：デフォルトの名無しさん：04/03/21 12:00

>>69
簡単に言うと、
GenericがC++に登場したのはコンテナの問題があったから。
ベースクラスがないC++では、いちいちクラス毎のコンテナを作るか、
プリプロセッサマクロでシコシコ作る労力が必要だったけど、
templateの導入でその辺が解消された。
標準ライブラリもSTLへ書き直された。
というか、それ以前はまともなライブラリが存在しなかった。

Javaは最初からベースクラスが存在していたので、
コンテナを作る労力の問題はなかったけど、
いちいちキャストを行う必要があった。
それを不要にしたのが今回のGeneric拡張。

事情は違うけど、どっちも構文的にクソの類に近づいているとは思う。

71 ：デフォルトの名無しさん：04/03/21 12:12

えーと
ちょっとわかってないのですが、
結局、javaとc++はどこが違うんですか？

ベースクラスがある、なしは
言語仕様の問題ですか？

72 ：デフォルトの名無しさん：04/03/21 12:16

まぁ俺もgeneric多用するコードはよくないと思う
キャストが面倒なだけなら本来はラッピングしたクラス用意すべきだし

コーディングの手間を減らすには多少の効果はあるけどね
積極的に使用すべきものはtype safe enumだけかと

型が厳密な綺麗なコードってのは人が取っつきにくいコードでもあるからねぇ
どこで妥協すべきかってのは難しい問題
javaは現在主に使われている言語ではお堅いほうだからね
俺はそれがいいと思ってるんだけど、そう思ってない人も多いみたいで

73 ：デフォルトの名無しさん：04/03/21 12:28

>>71
つまりJavaのGenericは動的な部分が残るってこと。
現状では型安全の強化＋キャストの代行って意味合いが強い。
対してC++のtemplateは、可能な限り静的に展開される。
ただしC++の方式は、用法に気をつけないとtemplateの
展開で生成されるコードが無闇に増大し、プログラムが
大きくなりすぎるというリスクがある。

74 ：デフォルトの名無しさん：04/03/21 12:36

> 対してC++のtemplateは、可能な限り静的に展開される。
可能な限り？ C++のtemplateって動的に展開される事もあるんだっけか？

75 ：デフォルトの名無しさん：04/03/21 12:53

今まで散々Javaにないからといってgenerics不要論唱えてきて
急に採用されたからって照れ隠しに反対してる馬鹿数名。

76 ：デフォルトの名無しさん：04/03/21 12:53

>キャストが面倒なだけなら本来はラッピングしたクラス用意すべきだし
generics使うのと何が違うの？

77 ：デフォルトの名無しさん：04/03/21 13:14

低能でも使える道具は良い道具。しかしさらに良い究極の道具は低能には使いこなせない。

セスナ機は誰でも簡単に操縦できるが高性能戦闘機は難しい。携帯電話を使いこなせる近
所のおばちゃんはパソコンが難しいと言う。JavaはできるがC++は難しいというプログラ
マーは大量にいる。

ここ数年で急増したJavaプログラマーは、C++など他の言語の習得に失敗した専門学校上
がりのDQNが多い。濃縮された低能集団が大量に集まっている。質より量で低能プログラ
マーを大量投入しなければならず、人件費の平均単価は下がる一方だ。

日本の企業はいまだに能力による待遇差別を嫌う。君がいくら有能なJavaプログラマーで
あっても、大量の低能プログラマーとほとんど同じ賃金を受け取ることになる。

仕事が速い有能プログラマーや、定時間内に集中して仕事をするプログラマーは、残業手
当が少なくなってしまう。低能プログラマーは仕事が遅いため多くの残業手当を手にする。
ただでさえ低い賃金に悩んでいる有能プログラマーは、低能プログラマーの高い残業手当
を見て憤りを感じ、これを続けることで有能なプログラマーが壊れることになる。

Javaは良い言語だが、そのスキルは将来の収入アップには繋がらない。向上心を持っても
無駄だ。低能集団の中の有能なプログラマーは出る杭として打たれる。

それでもJavaは良い言語。「個性を望まない」「みんな同じを望む」という日本の教育で
作られた大量の低能達をうまく使いこなすにはJavaが一番だ。安価な歯車になって人生を
全うする覚悟があるならば、是非ともお奨めしたい。今の日本に必要とされる人材だ。

78 ：デフォルトの名無しさん：04/03/21 13:19

Java開発者の７割は本物のスキルを持っていない、ガートナー調査より
http://www.itweb.co.za/sections/software/2004/0403191257.asp?A=APD&S=Software%20Development&O=FPT

79 ：デフォルトの名無しさん：04/03/21 13:21

>>78
他の言語でも似たようなもんだろ。
そもそも本物のスキルって何だ？

80 ：デフォルトの名無しさん：04/03/21 13:23

要は複雑怪奇な糞仕様をIDEで隠すこともできず破綻し始めてるということだな

81 ：デフォルトの名無しさん：04/03/21 13:24

糞仕様ってどのへんが？

82 ：デフォルトの名無しさん：04/03/21 13:25

破綻ってどのへんが？

83 ：デフォルトの名無しさん：04/03/21 13:25

複雑怪奇ってどのへんが？

84 ：デフォルトの名無しさん：04/03/21 13:39

どのへんがってこのへんか？

85 ：デフォルトの名無しさん：04/03/21 14:07

IDEってどのへんが？

86 ：デフォルトの名無しさん：04/03/21 15:03

>>77
JavaをVBに置き換えれば本来の文章になるね。

87 ：デフォルトの名無しさん：04/03/21 15:14

>>79
他の言語というか、開発者数の問題だな。
マイナーなうちは、他の言語もできる、スキルを持った人が大半を占める。
メジャーになると、その言語しかしらない人が増える。
Javaも普及したもんだ。

88 ：デフォルトの名無しさん：04/03/21 17:39

荒らす前に、ここらのページを理解して来いよ。
釣られる気にもならない。
ちなみに、C++プログラマの９９％はオブジェクト指向が使えない。
C++プログラマの99.9%はヘッダファイルをちゃんと書けない。
C++プログラマの99.9%はTemplateの間違った使い方をする。（あるいは使えない）
C++プログラマの99.9%はtry/catchの間違った使い方をする。（あるいは使えない）
C++プログラマの99.99%は関数ポインタを使えない。
（まあ、オブジェクト指向ができればいいんだけどさ）

j2se1.5β
http://java.sun.com/j2se/1.5.0/index.jsp

eclipse3.0
http://download2.eclipse.org/downloads/drops/S-3.0M7-200402122000/index.php
(Platform Runtime Binaryをダウンロード）

JAVAとC#の比較
http://objectclub.esm.co.jp/cs-vs-java//cs-vs-java.html

J2SE1.5の新機能
http://www5.airnet.ne.jp/sakuraba/java/laboratory/J2SE1.5/contents.html

C++とJavaの総称
http://www.mamezou.com/tec/Tips/javaGenericsVsCppTemplate/

JavaGenerics概説
http://objectclub.esm.co.jp/JavaGenerics/

89 ：デフォルトの名無しさん：04/03/21 18:23

eclipse3.0M7って1.5に対応してるの？

90 ：デフォルトの名無しさん：04/03/21 18:40

>>88
関数ポインタを何か特別な物だとお思いのようで。
何かトラウマでも？

91 ：デフォルトの名無しさん：04/03/21 18:41

>>88
ｽｹﾞｰﾅ、アンタの周り、アホしかいないのか。どこの会社の人？

>>C++プログラマの99.99%は関数ポインタを使えない。
まあ、C++なら使わなくても問題ないしー。

92 ：デフォルトの名無しさん：04/03/21 19:13

>関数ポインタ
制御文を式で代用出来るから表記が簡潔になる。
と初心者は有難がるが、実は最新のIDEでも
間接的にしか定義をトレース出来ないから、
見通しが悪くなる罠。
理解できないからといって、そんなに卑屈に
なる必要は無いぞ。>>88よ。

93 ：デフォルトの名無しさん：04/03/21 19:15

メソッドポインタのないC++は糞

94 ：デフォルトの名無しさん：04/03/21 19:19

>93
卑屈になるなといってるのに・・

95 ：デフォルトの名無しさん：04/03/21 19:21

メソッドポインタのないJavaも糞

96 ：デフォルトの名無しさん：04/03/21 20:25

強い型付の言語で汎用ルーチン書こうとするとGeniricsが欲しくなるのは
仕方ないように思うよ。

97 ：デフォルトの名無しさん：04/03/21 22:17

>関数ポインタを何か特別な物だとお思いのようで。
オブジェクト指向が使えない→関数ポインタが使えない
これは真

関数ポインタが使えないけど、オブジェクト指向が出来る人

まあ、多少はいるけど・・・
オブジェクト指向ができれば、関数ポインタも使えるから
関数ポインタが使えない事とオブジェクト指向が出来ない事は
等価だな。

>制御文を式で代用出来るから表記が簡潔になる。
>と初心者は有難がるが、
え、この人何言ってるのｗ

98 ：デフォルトの名無しさん：04/03/21 22:53

ここで糞と言われている全てのことはD言語で解決

99 ：デフォルトの名無しさん：04/03/21 23:03

>>97
> 関数ポインタが使えないけど、オブジェクト指向が出来る人
> まあ、多少はいるけど・・・

と

> オブジェクト指向ができれば、関数ポインタも使えるから

が矛盾してるぞ。

> え、この人何言ってるのｗ

お前に言うべきせりふだよ。(藁

100 ：デフォルトの名無しさん：04/03/21 23:40

つまり構文的にはアセンブラが一番美しいということでよいですね？

101 ：デフォルトの名無しさん：04/03/21 23:41

すると必然的に見た目が似ているHSPも美しいということになりますよね

102 ：デフォルトの名無しさん：04/03/22 00:03

HSPは確かに美しいが、スレ違いだ。

103 ：デフォルトの名無しさん：04/03/22 02:33

typedef int (Test::*testfunc)(int);
testfunc f = &(Test::func);
Test* t = new Test;
int result = (t->*f)(5);
まあ、確かにそりゃないよ～って思う。
こんな構文じゃ、使えない奴が多くても驚かんね。

104 ：デフォルトの名無しさん：04/03/22 05:28

>>98
D言語は存在そのものが糞。
まずはstring型実装してコンパイラ安定させろ。
話はそれからだ。

105 ：デフォルトの名無しさん：04/03/22 10:01

Genericsとかって要るの？　安全にコレクションのやりとりしたけりゃオブジェクトの配列を使えばいい

String[] strs;

106 ：デフォルトの名無しさん：04/03/22 10:01

コレクション（コンテナ）＝配列ですかそうですか。

107 ：デフォルトの名無しさん：04/03/22 10:55

>>105
サイズ可変のものを安全に操作したい。
マップを安全に操作したい。

108 ：デフォルトの名無しさん：04/03/22 10:57

>>72-73
Genericsを多用すべきでないと言うことは

JavaでGenericsが出たら心がけるべき
使用方法というのがあるとか？

すくなくともコレクション系やNumberクラスをメソッドの引数にするようなものには
よく使いたいのだが。

109 ：デフォルトの名無しさん：04/03/22 10:58

>>75
何言ってんだこいつ。
急に採用されたと思いこんでいるみたいだな。
何年も前から慎重に議論されてきたことだというのに。

110 ：デフォルトの名無しさん：04/03/22 11:01

>>77自身はC++もJavaもフルに使いこなすことができないんだろうな。

「Javaは糞、俺はC++できるぜ」といっておきながら
JavaにはないC++の機能をフルに使いこなすこともできない、
Javaにある機能すらフルに使いこなすこともできない
使いこなせるレベルはただのC言語レベル。
実際こういうのが多いんだよね。C++厨の仮面を被ったC厨ってのが。

111 ：デフォルトの名無しさん：04/03/22 11:01

ユーザーがgenericsを直接使ってライブラリを作る必要はそうないだろ。
だから多用も何もないよ。
あくまでgenericsで構築されたコンテナライブラリを使うだけ。
だからヒステリックに反対したり大げさに騒ぎ立てる必要はない。

112 ：デフォルトの名無しさん：04/03/22 11:02

やっとtemplateが採用されたか。
次は演算子オーバーロードだな。

113 ：デフォルトの名無しさん：04/03/22 11:04

JavaもどんどんC++の真似を始めてるな

114 ：デフォルトの名無しさん：04/03/22 11:14

>>112
残念ながらＣ＋＋のtemplateのようにはいかない。

115 ：デフォルトの名無しさん：04/03/22 11:15

>>111
Generics使うとデザインパターンでも役に立つモノがあるわけだが。
StrategyパターンとかBridgeパターンとか

116 ：デフォルトの名無しさん：04/03/22 18:57

演算子オーバーロードするならMLみたいに
キーワード演算子も対応してほしい。

117 ：デフォルトの名無しさん：04/03/22 19:11

>>113
C++ しかできない人にはそー見えるのかもしれん。

118 ：デフォルトの名無しさん：04/03/22 19:14

>>117
真似に見える時点でC++もできてない。

119 ：デフォルトの名無しさん：04/03/22 19:17

つーかデフォルト引数だろ。
似たようなメソッド3つも4つも
作って何が楽しいのかと。

120 ：デフォルトの名無しさん：04/03/22 19:34

そうだね。
デフォルト引数は欲しいね。

121 ：デフォルトの名無しさん：04/03/22 19:37

デフォルト引数はバグの元としてC++/Delphi->C#で廃止された。

122 ：デフォルトの名無しさん：04/03/22 20:39

名前付き引数のほうがいいな。

123 ：デフォルトの名無しさん：04/03/22 22:13

なにそれ?

124 ：デフォルトの名無しさん：04/03/22 22:19

>>114
C++のようなtemplateは、そもそも要らない。

125 ：デフォルトの名無しさん：04/03/22 22:55

デフォルト引数は、python や ruby には存在するね。
D には…ないのか。

126 ：デフォルトの名無しさん：04/03/22 23:15

>>116
危険で無駄な機能は不要だよ。
Jakarta Veloocityで代用できる。
少なくとも演算子オーバーロードが
ただのenumではなくtypesefe enum、
ただのtemplateではなくGenericsのようなしっかりとした
堅牢性の高い仕様でなければ不要と言わざるを得ない。

127 ：デフォルトの名無しさん：04/03/22 23:25

> しっかりとした堅牢性の高い仕様でなければ不要と言わざるを得ない。
採用されるまでは「不要だ不要だ」と言っておきながら、採用されたとたんにこれか。

128 ：デフォルトの名無しさん：04/03/22 23:44

>>127 今でも不要と思っているけどね。あれもこれも必要とつけていくと、気付くと C++ のようになる予感。

129 ：デフォルトの名無しさん：04/03/22 23:49

>>127
ちょっとまてよ。
で、何が採用された？
Genericsなど、実際に採用されたものはC++のtemplateとは異なるものだ。
あれでは「C++のtemplate機能は不要といったにもかかわらず採用された」
ということはできない。

よってGenericsが不要といったわけでもなければC++のtemplateは採用されたわけでもない。

130 ：デフォルトの名無しさん：04/03/22 23:49

すまんが >>116 の「キーワード演算子」ってのがわからんのだが、何？

131 ：デフォルトの名無しさん：04/03/22 23:50

>>129
まあそう興奮するな。ただの煽りだ。

132 ：デフォルトの名無しさん：04/03/22 23:55

>>130
任意の識別子を使って中置演算子を作れるってやつじゃないの

133 ：デフォルトの名無しさん：04/03/23 00:04

>>132
ああ、それか。
でも、それがどういう理由で危険なのかな。>>126

134 ：デフォルトの名無しさん：04/03/23 00:05

>>133
悪意を持った人間が
10 minus 4が40を返すように定義される「可能性」があるからです。

135 ：デフォルトの名無しさん：04/03/23 00:08

add() メソッドが足し算することが保証されているわけでもないのにな。

136 ：デフォルトの名無しさん：04/03/23 00:28

そもそもメソッドと演算子は仕組みが違うし。

演算子は引数が一つか二つに限られたメソッドみたいなものだし。

137 ：デフォルトの名無しさん：04/03/23 00:33

>>135
同意。
「10 mius 4 が40を返すように定義される可能性」と，
「minus()メソッドが掛け算を行うように定義される可能性」では，
前者の方が可能性が高いと言える理由が分からない。
演算子のオーバーロードが普通のメソッドに比べて「より」危険である理由を
説明してくれる人は誰かいないの？

138 ：デフォルトの名無しさん：04/03/23 00:34

>>137
頭痛の種は二つより一つの方がまだましだからです。

139 ：デフォルトの名無しさん：04/03/23 00:36

演算子オーバーロードの危険性ってのは、
定義済み演算子の意味をも変更できるから危ないってことでしょ。

140 ：デフォルトの名無しさん：04/03/23 00:37

本音：S○Nのパースの実装が糞なので演算子オーバーロードなんてJavaには組み込めません

141 ：デフォルトの名無しさん：04/03/23 00:39

>>137
C++の演算子オーバーロードって、ユーザが想像もつかないようなことが起きやすい
っすよね。アホが勇み足で=だの[]だの&だのに変なオーバーロードをかけていたせ
いで、えらい目にあったことがある人、手を挙げて～。

142 ：デフォルトの名無しさん：04/03/23 00:43

↓　自作自演開始

143 ：デフォルトの名無しさん：04/03/23 00:55

お前ら演算子のオーバーロードについてあまりめったなことを口にしないほうがいいよ。
何が起こるかわからないからな。今回の事がいい教訓になっただろう。

144 ：デフォルトの名無しさん：04/03/23 00:57

今回のことってどういうこと？

145 ：デフォルトの名無しさん：04/03/23 01:08

>>137
機能性の高さからメソッドのオーバーロードがあれば演算子のオーバーロードはいらん
といえるが

演算子のオーバーロードがあればメソッドのオーバーロードはいらんとは
言えないだろ。

とりあえずここではメソッドがstaticだとして説明するぞ。

doMethod(int x, int y)というメソッドを
演算子で x doMethod y　のように定義できたとしても

doMethod(int x, int y, String z, Number a, FileInputStream b)
なんてメソッドを演算子で定義できるか？
三項演算子のような演算子を再定義できるようにしろというのか？
かえって可読性が低下するだけだぞ。

それにdoMethod(AudioInputStream x, Socket y)
doMethod(AudioOutputputStream x, URL y)

なんて二つのメソッドを同じ演算子で使うようにしたいとき
型の違いによる煩雑さが増すだけだ。
それに演算子の優先順位も決定しなくてはならない。
混乱が増えるばかりだ。スパゲティコードを作りやすくなる。
それにくらべJ2SE1.5の新機能はスパゲティコードを作りやすい方だと言えるか？ >>143よ

146 ：デフォルトの名無しさん：04/03/23 01:10

1.6ではpropertyとdelegateが導入されます。

147 ：143：04/03/23 01:15

>>145
俺に聞くなよｗ
ただ一つ言えるのは>>145の発言はしっかりログとして保存されるということだ。
削除依頼だすなら今のうちだぞｗ

148 ：デフォルトの名無しさん：04/03/23 05:01

>>145
中卒？群とか環とか体とか知ってる？

149 ：デフォルトの名無しさん：04/03/23 11:35

なんかいらない機能増えてるなぁ…
そんなにキャスト嫌いなのか？？
私は嫌いじゃないんだけど…

150 ：デフォルトの名無しさん：04/03/23 11:37

じゃあ参照保持する変数もObject型だけで十分ですね。
キャストすればいいだけですから。

151 ：デフォルトの名無しさん：04/03/23 17:03

まあ今なかったりかつてなかった機能を必死に拒絶したくなる気持ちも分からなくもない。
2chで突っ込まれると劣等感を感じるみたいだしな。
Del厨も正規表現ライブラリいらないとか言い張ってｳｻﾞいの何の。

152 ：デフォルトの名無しさん：04/03/23 17:04

>>149
get するときのキャストが嫌いっつーよりも
set するときの型チェックが嬉しいのでは。

153 ：デフォルトの名無しさん：04/03/23 17:17

setArray(ArrayList<Integer> al)
こんな感じになるのかなぁ？？

154 ：デフォルトの名無しさん：04/03/23 17:25

List<Hoge> list = .....;
list.set(index, new Foo());

で、Foo が Hoge の下位クラスでなければコンパイルエラーになるのが
嬉しいって事では？

155 ：デフォルトの名無しさん：04/03/23 18:09

Genericsがあるのにtypedefがないって、
unko< tinpo< omeko< hiroyuki< sine< damepo< ore > > > > > obj;
みたいなクラスは、ただひたすら直気書きするしかないのか？

156 ：デフォルトの名無しさん：04/03/23 18:13

>>155
class Obj extends unko<tinpo<omeko<hiroyuki<sine<damepo<ore>>>>>{ ... }
すれば良いだけでは？

157 ：デフォルトの名無しさん：04/03/23 18:26

>>156
ただ可読性を上げる為だけにクラスつくんの？
ありえなーい。

158 ：デフォルトの名無しさん：04/03/23 18:39

>>155みたいな思考でtypedef欲しいってのも相当アホだけどね。

159 ：デフォルトの名無しさん：04/03/23 18:46

>>158
そうか？俺は一般的なtypedefの使い方だと思うけど。
hash_map< ClassA, ClassB, ClassA::HashFunc >とかベタで使う奴の方が
俺はアホだと思う。

160 ：デフォルトの名無しさん：04/03/23 19:03

ヘッダファイルみたいなもんが無い Java では
複数のファイルで共通の typedef 宣言を参照させるのは難しい。
プロジェクト内の .java ファイル全部に同じ typedef 書き連ねるつもりか？

くらいの問題点は2,3分考えりゃ誰でも気が付くと思うんだけどなぁ…

161 ：デフォルトの名無しさん：04/03/23 19:11

だいたいデフォルト引数が使えないJavaだが、
Genericsのパラメータにデフォルト値は付けられるのか？
（ドキュメント流し読みではそんな記述は見つけられなかったが・・。）
typedefも使えない、デフォルト値も駄目ときては
IDEのサポートでもなければ、とても使用に耐えないような気がする。

162 ：デフォルトの名無しさん：04/03/23 19:17

>>160
むしろJavaはヘッダしか無いと言った方が正しいのでは？
単にusingでインポートさせればいいじゃん。

163 ：デフォルトの名無しさん：04/03/23 20:03

>>161
まぁ、使えない人は使わなくてもいーんじゃないでしょーか。

164 ：デフォルトの名無しさん：04/03/23 20:05

> むしろJavaはヘッダしか無いと言った方が正しいのでは？
？

> 単にusingでインポートさせればいいじゃん。
思いつきで言われてもねぇ。やりたければ自分で実装してみれば？

165 ：デフォルトの名無しさん：04/03/23 21:40

>演算子のオーバーロードが普通のメソッドに比べて「より」危険である理由を
>説明してくれる人は誰かいないの？
他人の作ったライブラリーで演算子のオーバーロードしてあるクラスを
ポリモーフィズムさせて使ってみな。
おまけに、自分で作ったクラスも加えてみれば
もはや使い物になりませんと。

166 ：デフォルトの名無しさん：04/03/23 21:43

167 ：デフォルトの名無しさん：04/03/23 21:45

>ただ可読性を上げる為だけにクラスつくんの？
>ありえなーい。
たかがクラスを一個作るだけだろ。
eclipse使いなら5秒でできる。

168 ：デフォルトの名無しさん：04/03/23 23:12

>>165
a + b を a.add(b) に解釈するような単純な演算子オーバーロードの実装でもだめなの？
あと、メソッドならポリモーフィズムを使っても問題にならないという理由が理解できないんだが。
数値型ならそもそも派生することがナンセンスだし、
C#の event のようなものなら、+= の右辺は派生クラスである（実装したリスナのような）ことが当然じゃないのか？

169 ：デフォルトの名無しさん：04/03/24 00:15

>>167
あほ。そういう問題じゃねぇよ。

170 ：デフォルトの名無しさん：04/03/24 01:06

>>169
演算子オーバーロードって、たかが可読性のためにメソッド一個定義するわけ
ですが。どう違うのですか？

171 ：デフォルトの名無しさん：04/03/24 01:16

誰かがつくった仕様書で
引き継いだPGが即日仕様を理解して実装できる。
そのために

172 ：デフォルトの名無しさん：04/03/24 01:20

>>170
あほ。演算子オーバーロードなぞいらんわ。

173 ：デフォルトの名無しさん：04/03/24 05:14

> C#の event のようなものなら、+= の右辺は派生クラスである（実装したリスナのような）ことが当然じゃないのか？
・listenerA += (listenerB += handler) ができない。
・(listener += handler)(sender,e); ができない。
とかはどーなんだろーね？

っつーか、C#のイベントの += と -= は add と remove で何が悪いのかさっぱり理解できない。

174 ：デフォルトの名無しさん：04/03/24 18:34

>>170
可読性よりも記述性じゃないかと。

極端な話だが、演算子の無いLISPと演算子の塊の様なC、
どっちが書きやすいだろうか。

175 ：デフォルトの名無しさん：04/03/24 19:41

可読性も大事だと思うです。

176 ：デフォルトの名無しさん：04/03/24 19:46

プログラムは書く時間よりもコンパイルする時間よりも
読む時間のほうが長いからなあ

177 ：デフォルトの名無しさん：04/03/25 10:43

genericsって、結局コンテナ問題の妥協の産物でしかないんだろうか。

178 ：デフォルトの名無しさん：04/03/25 12:23

>>177
お前の人生妥協の連続

179 ：デフォルトの名無しさん：04/04/07 01:54

>>154
うむ、非常にうれしい。

>>155
そのような記述方法が制限されるということはないだろうか？

無駄に継承すればいいってもんでないのと一緒

180 ：デフォルトの名無しさん：04/04/07 01:56

>>160 >>168
ヘッダファイルやtypedef、演算子オーバーロードがどうしても欲しければ

Jakarta Velocityで解決

181 ：デフォルトの名無しさん：04/04/07 01:58

>>147
これだけ時間が経過しても具体的に反論できないのか。

>>148
集合論を持ち出して何の意味がある。
スパゲティコードと位相幾何学との相関を求めよ。

182 ：デフォルトの名無しさん：04/04/07 02:07

>>180
Javaから省いた蛇足がVelocityなんだなｗ

183 ：デフォルトの名無しさん：04/04/07 02:18

蛇足っちゅーか
Java にないけど使いたくてしょうがないから
Velocity の連中は作っちゃったって話だろ？

184 ：デフォルトの名無しさん：04/04/07 02:22

Javaの精神を理解してないね。Velocityの連中は。

185 ：デフォルトの名無しさん：04/04/07 02:24

Javaに見捨てられたVelocity。
いやJavaを見捨てたVelocityというべきか？ｗ

186 ：デフォルトの名無しさん：04/04/07 05:59

>>180
Velocity 使わんでも自分が欲しいプリプロセッサ探すか、作ればいーだけの話。

187 ：デフォルトの名無しさん：04/04/07 12:28

>>184
それをいうならC#や.NET作った連中なんか全然理解していないだろw
Velocity作った連中のほうが良く理解している。

188 ：デフォルトの名無しさん：04/04/07 12:42

マルチタスク実現へJava言語改良
http://www.itmedia.co.jp/news/articles/0404/07/news018.html

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

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

またJ2SE 1.6では、Javaプログラム間の高速通信を可能にするSockets Direct Protocolの
サポートが計画されている。カウンディンヤ氏によると、J2SEに施された改良は、その後間
もなくJ2EEにも組み込まれる予定。

　1月にβ版がリリースされたJ2SE 1.5は、6月のJavaONEカンファレンスで正式リリース
の運びとなる見通し。J2SE 1.5では、Javaプログラミングの簡易化に焦点を当てている。

　

189 ：デフォルトの名無しさん：04/04/07 12:43

J2SE1.6では今までOSだけでしかできなかったことがJavaだけでできるようになるのか。
汎用プログラミング言語初？

190 ：デフォルトの名無しさん：04/04/07 13:41

>>188
Tiger でやってるJITコンパイル後のネイティブコードをJVM間で共有するってのを促進するだけでしょ。

191 ：デフォルトの名無しさん：04/04/07 14:09

1.5って起動が鬼はやじゃね？

192 ：デフォルトの名無しさん：04/04/07 14:18

>>190
そうかねえ。

OSに依存せずにスケジュール管理ができると期待しているけれども

193 ：デフォルトの名無しさん：04/04/07 14:21

マルチタスク実現へJava言語改良
http://www.itmedia.co.jp/news/articles/0404/07/news018.html

> 1月にβ版がリリースされたJ2SE 1.5は、6月のJavaONE
> カンファレンスで正式リリースの運びとなる見通し。

β使った人は知ってると思うけど、あのバグだらけのTigerが
あとたった２ヶ月で正式リリースだって。

これだけでも手抜きの現実が浮かび上がってくるね。 s

194 ：デフォルトの名無しさん：04/04/07 14:24

>>193
しかも３０００人解雇でしょ。
普通に考えて間に合わないんじゃないかな。

195 ：デフォルトの名無しさん：04/04/07 14:25

235 名前：デフォルトの名無しさん[sage] 投稿日：04/04/07 10:17
リッチ・グリーン氏　3/31のコメント。
同氏は、「Java Desktop System」などのSun製品を売り込み、また、底辺からたたき上げ、採用を増やしている技術が勝利を収めているというビジネストレンドについても説明した。
このトレンドは、Sunの製品よりも、IntelのハードやLinuxに有利に働くかもしれないが、SunはソフトウェアでMicrosoftを追い越していると同氏は語った。

数日後、
「SunでJava推進の先頭に立ってきたリッチ・グリーン氏が同社を去ったことは、この提携がSun社内の対立を引き起こし、ひいてはJavaコミュニティーの内部対立につながる可能性を示すものだ」とカーペンター氏は指摘する。
Sunでは、グリーン氏の退職は同社のリストラ計画の一環だとしている。

＜もうわが社にはJava信者は要りません。逝ってよし！＞

IBMはグリーン氏を拾ってやれよ。悲惨すぎるぞｗ

196 ：デフォルトの名無しさん：04/04/07 14:26

>>193
ちなみに、どんなバグがありましたか？

197 ：デフォルトの名無しさん：04/04/07 14:27

>>196
聞いても無駄。彼は技術的なこと何も知らんのだから。

198 ：デフォルトの名無しさん：04/04/07 14:32

>>194
IBMが昔30万人を一斉解雇したことにくらべれば3000人解雇なんてたいしたことじゃないし

199 ：デフォルトの名無しさん：04/04/07 14:32

IBMもJavaの凍結死に一役買ってるね。

WebSphere5はいまだにJ2SE1.3ベース。
おかげで、現場でいまだに1.4を使ったことのない人多数。

こんな状態で1.5をリリースしてもどうなることやら。

200 ：デフォルトの名無しさん：04/04/07 14:35

>>193
> β使った人は知ってると思うけど、あのバグだらけのTigerが
> あとたった２ヶ月で正式リリースだって。

バグがあるならお前がJCPに報告すればいいだろうが。
それともお前は英語ができないのか？
お前にとってはバグでないものもバグを見なしているだけか。
実際どんなバグがあるかも明示できないお前が手抜きしている現実を浮かび上がらせているわけだが。

201 ：デフォルトの名無しさん：04/04/07 14:37

>>200
手抜き、ではなくて能力の限界でしょ。
あとJCPに報告すんのは固まってない段階の仕様にバグがあるときだけだよ。

202 ：デフォルトの名無しさん：04/04/07 14:43

＞Javaと.NETの連携技術の改善に向け協力する。

JavaVMとCLRではないところがミソかな。

203 ：デフォルトの名無しさん：04/04/07 14:43

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

Sunは本来のハードウェア事業に本腰。めでたしめでたし。

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

DB2もJavaから.NETへ。さすがIBMさんは分っていらっしゃる。

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

Oracleは焦って薄利多売路線へ。ｗ

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

MSはユーザーの声をどこの企業よりも大切にします。

204 ：デフォルトの名無しさん：04/04/07 14:44

リッチ・グリーンって3/31にはまだいたじゃん。
こんなことを言って追い出されちゃったのか･･･。
http://www.itmedia.co.jp/news/articles/0404/01/news030.html

205 ：デフォルトの名無しさん：04/04/07 14:47

>>199
> IBMもJavaの凍結死に一役買ってるね。
どこが買っているんだよw

Eclipse3.0, WADの開発が着々と進みDeveloperWorksも相変わらずJavaに関する記事を紹介しているだろw

ドトネト厨はどこまで妄想をもっているんだろうなw

> WebSphere5はいまだにJ2SE1.3ベース。
> おかげで、現場でいまだに1.4を使ったことのない人多数。

WebSphereと WebSphere Studioとの区別も付かないアフォですかねこいつは?w

> こんな状態で1.5をリリースしてもどうなることやら。

1.3と1.4,1.5との違いも即座に理解できないなんてチミはプログラマ失格だね。
あ、そうか、ドトネト厨はVBからVB.NETに移行して苦労しているから
１.3から1.4,1.5に移行するのに相当苦労すると妄想しているんだw

206 ：デフォルトの名無しさん：04/04/07 14:49

>>204
話し合いの末自分から辞めることを選んだろうと予測。
完全オープンソース化をする気なら減給するかクビにするしかないが、
それでもいいか？　と聞かれ退職することを選んだんだと予測。

207 ：デフォルトの名無しさん：04/04/07 14:49

アホアンチ荒らすなボケ

208 ：デフォルトの名無しさん：04/04/07 14:49

>>205
なるべくなら、ここでは.NET厨無視の方向で。
実は自作自演なのかもしらんけど。ageてるし。

209 ：デフォルトの名無しさん：04/04/07 14:52

リッチ・グリーン氏　3/31のコメント。
同氏は、「Java Desktop System」などのSun製品を売り込み、また、底辺からたたき上げ、採用を増やしている技術が勝利を収めているというビジネストレンドについても説明した。
このトレンドは、Sunの製品よりも、IntelのハードやLinuxに有利に働くかもしれないが、SunはソフトウェアでMicrosoftを追い越していると同氏は語った。

数日後、
「SunでJava推進の先頭に立ってきたリッチ・グリーン氏が同社を去ったことは、この提携がSun社内の対立を引き起こし、ひいてはJavaコミュニティーの内部対立につながる可能性を示すものだ」とカーペンター氏は指摘する。
Sunでは、グリーン氏の退職は同社のリストラ計画の一環だとしている。

＜もうわが社にはJava信者は要りません。逝ってよし！＞

210 ：デフォルトの名無しさん：04/04/07 14:55

>>203
こちらへ誘導準備しました。

次回はこちらでどうぞ。
【大反響】どうして.netは死滅してしまったのか？3
http://pc5.2ch.net/test/read.cgi/tech/1079428078/

211 ：デフォルトの名無しさん：04/04/07 15:00

>>203

Sun、NASメーカーProcomとライセンス契約
http://www.itmedia.co.jp/news/articles/0404/07/news005.html

IBMの次世代データベース「Stinger」、月末にもデビュー
http://www.itmedia.co.jp/news/articles/0404/07/news014.html
この記事をよんでJavaからドトネトだなんて妄想だなw
Javaのほうがすでにサポートが進んでいるからサポートが遅れている.NETとLinuxへの
対応を強化すると表明しているだけじゃん。ドトネト忠は頭が悪いなw

DellとOracle、廉価版DB普及へ提携拡大
http://www.itmedia.co.jp/news/articles/0404/07/news015.html
この記事をよんでOracleが焦って薄利多売路線？　アフォですねドトネト厨はw

http://www.itmedia.co.jp/news/articles/0404/07/news016.html
こんな記事よんだくらいでM$がユーザの声をどこの企業よりも大切にするだって？w
ユーザの声を無視して互換性のないソフトを作って仕方が無くWindowsを使わされている者が大半だという
ことにも気づかないなんてドトネト厨らしいやｗ

212 ：デフォルトの名無しさん：04/04/07 15:04

>>211
で、リッチーの首切りはどう解釈するの？

213 ：デフォルトの名無しさん：04/04/07 15:30

Javaでタスク管理、いいねえ。

java.util.concurrentを使うようになるのか？

214 ：デフォルトの名無しさん：04/04/07 16:12

>>211 .NET厨に付き合うなら、以下のスレでどうぞ。

【大反響】どうして.netは死滅してしまったのか？3
http://pc5.2ch.net/test/read.cgi/tech/1079428078/

215 ：デフォルトの名無しさん：04/04/07 16:19

ノシ

216 ：デフォルトの名無しさん：04/04/08 13:57

>>193
>>213
これって複数のJavaアプリ立ち上げてもJVMは一つで済むってことですかね？

217 ：デフォルトの名無しさん：04/04/08 14:00

つまりセキュリティホール。(ｹﾞﾗ

218 ：デフォルトの名無しさん：04/04/08 15:19

>>216
おいおい、んな機能すでにJavaに取り込まれているぞ。

これでセキュリティホールだったらC#のCLRなんか穴だらけだなw
少なくともJavaよりも穴が多いのは事実だが。

219 ：デフォルトの名無しさん：04/04/08 15:27

そうなんですか…。

>「J2SE 1.6」には、JVMのアプリケーション共有を強化する「分離」機能が備わる。
>この機能によってローカライズコンピューティング処理実行のための分離が可能になり、
>第2のJVMを要求することなくJVM内部でマルチタスクが行えるようになるという。

この意味がよく分からないので…。

220 ：デフォルトの名無しさん：04/04/08 16:06

>>219
予想でしかないのだけれど。
例えば、2つのアプリケーションでrt.jarが共有できるってなことかと。
メモリ効率向上と高速化(JIT結果の共有)が期待できそう。
既にクラスローダがそれっぽいことしてるので、もっと踏み込むはず。
詳細が早く知りたい。

221 ：デフォルトの名無しさん：04/04/08 17:15

1つのVMを起動しっぱなしにして、クライアントアプリを毎回そのVMにアタッチさせて早く見せかける手法か？

222 ：デフォルトの名無しさん：04/04/08 17:19

J2SE1.6が未来のJavaOSになる可能性もあるわけか

223 ：デフォルトの名無しさん：04/04/08 17:21

>>221
それだったらすでにある。
昔の古いヴァージョンでうごくJavaアプリは起動するたびに
(Windowsの場合)java.exeを起動していた。複数起動すると
java.exeが複数起動するという効率の悪い仕様だった。
しかし今はその問題は解決されている。

224 ：デフォルトの名無しさん：04/04/08 17:22

今までサービスやプロセスなどの管理をOSにまかせっきりだったが
J2SE1.6によってOSでしかできなかったことがJavaでもできるってか？

ということはマルチスレッドしかできなかったことを
マルチプロセスｍマルチタスクで実現できるのか。

225 ：デフォルトの名無しさん：04/04/08 17:26

>>223
ほんとかよ。J2EEサーバ立ち上げるとjava.exeだらけだぞ。

226 ：デフォルトの名無しさん：04/04/08 17:49

つまり、今までOSの機能を使って実現されていたプロセス間通信が
ピュアJavaコードによってなされるってこと？
いや、今までJavaがプロセス間通信をサポートしていたのかは知らんが。

227 ：226：04/04/08 17:52

プロセス間通信じゃなくてマルチプロセス機能？

228 ：デフォルトの名無しさん：04/04/08 20:19

>>222
例のJavaOSとは別に
こんなのみつけた
↓
ttp://emulin.netfort.gr.jp/

激しく本末転倒でﾜﾛﾀ

229 ：デフォルトの名無しさん：04/04/08 20:49

結局なんなのかよく分からないんですが。

230 ：デフォルトの名無しさん：04/04/08 21:24

>>229
Javaで書いたLinuxエミュレータ

231 ：デフォルトの名無しさん：04/04/08 22:53

>>225
それはLinuxがプロセスリストにスレッドも列挙してるからだろ。
でも>>223 が言ってることは謎。あるとしか言わないから詳細がわからん。

232 ：デフォルトの名無しさん：04/04/09 01:40

>>225
バージョンはいくつ？
ついでにJ2SEのバージョンも　

233 ：デフォルトの名無しさん：04/04/09 01:43

>>792
これってどうよ？

private final double[] vector;

public DoubleVector(double[] vector) {
this.vector = (double[]) vector.clone();
}

public double max() {
double max = (-1) * Double.MAX_VALUE;
for (int i = 0; i < size(); i++) {
max = StrictMath.max(max, get(i));
}
return max;
}

234 ：デフォルトの名無しさん：04/04/09 01:43

誤爆した

235 ：デフォルトの名無しさん：04/04/09 02:07

>>225
とりあえずApplet, JavaweStart対応アプリでは
すでに解決済み。

古いバージョンのコンパイラでつくったバイナリでは無理。　

236 ：デフォルトの名無しさん：04/04/09 07:25

>>231
Linux のプロセスリストに java.exe があったら怖いな。

237 ：デフォルトの名無しさん：04/04/09 09:04

> 古いバージョンのコンパイラでつくったバイナリでは無理。　
？

238 ：デフォルトの名無しさん：04/04/09 09:10

>>236
ln -s java java.exe でO.K.

ところでrt.jarの共有って、1.4のコンパイラで-source 1.4つけてコンパイルすれば有効になる？

239 ：デフォルトの名無しさん：04/04/09 09:19

> ln -s java java.exe でO.K.
んなアホな事するか。

> ところでrt.jarの共有って、1.4のコンパイラで-source 1.4つけてコンパイルすれば有効になる？
？

240 ：デフォルトの名無しさん：04/04/09 10:21

>>237
たとえばJ2SE1.2でコンパイルしたUMLツールのＩＩＯＳＳとか。
いくつも起動すると起動した数だけjava.exeが沢山立ち上がる。

241 ：デフォルトの名無しさん：04/04/09 11:04

J2SE 1.4 でコンパイルしなおせば
> いくつも起動すると起動した数だけjava.exeが沢山立ち上がる。
にならない、とか考えてるわけ？

242 ：デフォルトの名無しさん：04/04/09 11:14

IIOSSはJ2SE1.4には未対応だよん。
未だに1.2だか1.3でシコシコSwing使っているんだから
おもたくてしょうがない。

243 ：デフォルトの名無しさん：04/04/09 11:20

IIOSSも古すぎ。サイトの更新が去年の4月で終わってる。

ソフトウェアの更新履歴についても具体的に触れていない。
もう枯れているというか。Eclipse UML Omondoがタダで便利ならみんなそっちのほうを使ってしまう。

http://www.iioss.org/QA/iioss-j.html#iioss-jdk1-4-x
[Q] JDK1.4 では動作しないのですか?
いくつか動作しない機能もあります。

244 ：デフォルトの名無しさん：04/04/09 11:28

winで1.4.2だけどたくさん起動するとjavaw.exeがガンガンたまっていくぞ

245 ：デフォルトの名無しさん：04/04/09 12:38

やっぱりAppletやJavaWebStarｔだけにしか対応していないっぽい。

Eclipseとかはだめぽ

246 ：デフォルトの名無しさん：04/04/09 12:46

>>245
それはつまり、AppletやJavaWebStartを起動するJavaプラグインが
個別のAppletやJWSごとに別スレッドを立てているだけか。
きっとブラウザを複数プロセス立ち上げてそれぞれでApplet動かしたら
java.exeが複数動くんだろうな。
>>223の話と違うな。てことは223の勘違いってことでFA？

247 ：デフォルトの名無しさん：04/04/09 12:54

>>246
> きっとブラウザを複数プロセス立ち上げてそれぞれでApplet動かしたら
> java.exeが複数動くんだろうな。
いや、そうはならなかった。Applet, JavaWebStart対応アプリを複数起動しても
java.exe, javaw.exeは一つだった。

248 ：デフォルトの名無しさん：04/04/09 13:31

Windows2000とSun J2SE1.4.2_04上でJavaWebStartアプリをコンパイル&実行してますが、
新しく起動するたびにタスクマネージャのプロセスにjavaw.exeが増えていきます。
223や247の環境はどうなってるんでしょうね？
それとも、こちらの環境でのコンパイルをEclipse付属のコンパイラにやらせたのが原因？
（Eclipseは内部に独自のコンパイラを持っている）

249 ：デフォルトの名無しさん：04/04/09 13:47

> それとも、こちらの環境でのコンパイルをEclipse付属のコンパイラにやらせたのが原因？
なんで原因になるんだ？

250 ：デフォルトの名無しさん：04/04/09 13:57

Windows XP - J2SE 1.4.2_04 で試してみた。

Applet:
複数起動してもプロセスにjavaw.exeは一つもない。
ブラウザを複数プロセス立ち上げても同じ。

Java Web Start:
起動した数だけプロセスにjavaw.exeがある。

Java Application(.jarをダブルクリックして起動):
起動した数だけプロセスにjavaw.exeがある。

251 ：デフォルトの名無しさん：04/04/09 14:19

Appletはブラウザのプロセス上のスレッドで動いている。

Java Web StartやJava Applicationはそれぞれのプロセスで動いている。
1.6ではJVM上のプロセスで動くようになる。

こんな理解でよろしいか？

252 ：デフォルトの名無しさん：04/04/09 14:37

>>251
1.6 って3年後くらいか？
.NET の Longhorn みたいにあまりにも先の話はむなしい。

253 ：デフォルトの名無しさん：04/04/09 14:40

ベータが今年秋で、来年リリースだと
言ってるだろうに、ソース嫁。

254 ：デフォルトの名無しさん：04/04/09 14:40

今秋β版が登場し、2005年に一般リリース予定。だそうです。

255 ：デフォルトの名無しさん：04/04/09 14:43

まあ、最後のJ2SEだけどね。(ｹﾞﾗ

256 ：デフォルトの名無しさん：04/04/09 14:47

Javaは相変わらず遅いままか

257 ：デフォルトの名無しさん：04/04/09 16:04

少し前に 1.2 から 1.4 にリプレースしたばかり。
1.6？とりあえず 3 年は仕事には関係ない。

258 ：デフォルトの名無しさん：04/04/09 23:39

>>159
public class HogeMap extends hash_map< ClassA, ClassB, ClassA::HashFunc > {}

でええやん。

たくさんあるなら同じパッケージにまとめてimportさせるよろし。

259 ：デフォルトの名無しさん：04/04/10 00:03

> public class HogeMap extends hash_map< ClassA, ClassB, ClassA::HashFunc > {}
Java と C++ が混じってるのか？

260 ：デフォルトの名無しさん：04/04/10 05:02

条件コンパイル入れてくれたらなあ。
デバッグプリントとかつけはずししたいし。

261 ：デフォルトの名無しさん：04/04/10 10:43

>>260
AspectJつかうとよろし。

262 ：デフォルトの名無しさん：04/04/10 11:22

>>260
final なデバッグフラグならコンパイル時に消去されるので問題なし。

public static final boolean DEBUG
～
if(DEBUG){
　　System.out.println();
}

まあ、大概はassertで片付く気もするが。

263 ：デフォルトの名無しさん：04/04/10 11:37

ログ使うって方法もあるんじゃない

264 ：デフォルトの名無しさん：04/04/10 11:40

>>258
ちなみにJavadocで、そのクラスの説明は何て書くの？

265 ：あぼーん：あぼーん

あぼーん

266 ：デフォルトの名無しさん：04/04/10 12:36

>>262
正確には定数式である事が条件なので final で修飾しただけではダメ。
> public static final boolean DEBUG = Boolean.getValue("debug");
とかなってる場合は
> if(DEBUG){
> 　　System.out.println();
> }
はコンパイル時には絶対に消去されない。

267 ：デフォルトの名無しさん：04/04/10 13:41

>>266
そういった議論がなされている時点で、
○○でやれば無問題って意見は却下だよなぁ。
しかし、>>260みたいなことをしたければ
Velocityのようなシステムを使えってのには同意だ。
別に言語仕様に含めるもんでもないからな。

268 ：267：04/04/10 14:15

Velocityは関係なかった。すまそー。

書いた後でちょっと考えたら
やっぱ>>267では問題あるような気がしてきた。

269 ：デフォルトの名無しさん：04/04/10 16:57

Logger とレベル設定じゃ、あかんのか？

270 ：デフォルトの名無しさん：04/04/10 18:12

>>269
それでいーと思われ。

271 ：デフォルトの名無しさん：04/04/11 02:06

>>269
そもそもリリース版でメソッド呼ぶコストがｷﾆﾅﾙ(そんなのが気になるような
ら、そもそもスレッドスタックが深くなりがちなJavaなんぞ使うべきではない
が)場合の話ではないかな。

もし本当に問題になるなら、デバッグ版だけAspectJつかうか、IoCコンテナで
インスタンス作ることにしといてデバッグ版だけLogging全てかますProxyでラ
ップ掛けとく、あたりがいいんじゃないのかな。

272 ：デフォルトの名無しさん：04/04/11 14:39

Logjでええんじゃん

273 ：デフォルトの名無しさん：04/04/11 20:10

>>271
>260 がコストとかを気にしてるようには見えなかったんで。
実際、JDK Logger や Log4J のパフォーマンスが問題になるのは
よほどのことが無い限り、無いと思う。
アンタが言うとおり Java を使ってるんであれば。

AOP や IoC コンテナを使えばパフォーマンスも良いかもしれないし
柔軟性も高いかもしれない。が現時点で人によう勧めん。

274 ：デフォルトの名無しさん：04/04/12 08:48

.NETのPreJITまでパクってたのか。見境なしだな。
http://java.sun.com/j2se/1.5.0/docs/guide/vm/class-data-sharing.html

275 ：デフォルトの名無しさん：04/04/12 09:35

そんな程度のことでパクリだパクリだいってどうすうのやら。
M$もJITをパクって.NETを作ったわけだし。

276 ：デフォルトの名無しさん：04/04/12 11:41

もともとパクリだパクリだって騒ぎ出したのはJava厨だけどね。
そのJavaもパクっているってこった。

277 ：デフォルトの名無しさん：04/04/12 13:03

>>274
IBM の JRE では .NET が出る前からやってる手法だし。

278 ：デフォルトの名無しさん：04/04/12 18:36

そのうち、どちらともなくアルファベットを使うのはパクリだといいだしかねない勢いだな。

279 ：デフォルトの名無しさん：04/04/12 21:59

つまりドトネトがIBM JREをパクったわけか

280 ：デフォルトの名無しさん：04/04/12 22:37

内容を見ずに言葉の誤解があるような。

281 ：デフォルトの名無しさん：04/04/12 22:46

PreJITよりセキュアなら全然オッケー。
ノータッチデプロイメントといいドトネト製品はどうもセキュリティの脆弱性が高すぎて。

282 ：デフォルトの名無しさん：04/04/13 00:01

>>281
脆弱性が高いって変な表現だなぁ

ちなみにノータッチデプロイはJavadeいうアプレットだと思うんだけど。
セキュリティモデルはちゃんとある。

283 ：デフォルトの名無しさん：04/04/13 06:15

けどデフォルトでは有効になってないっておち？

284 ：デフォルトの名無しさん：04/04/14 00:13

>>282
M$がいっているやつのほうよ。
ドトネト厨が速度が速いからJavaWebStartのほうがいいと豪語してる。
実際のところ、セキュリティ上の問題を抱え込んでる。

285 ：デフォルトの名無しさん：04/05/28 12:44

jdk-1_5_0-beta2 age

286 ：デフォルトの名無しさん：04/05/28 13:12

C#のパクリ

287 ：デフォルトの名無しさん：04/05/28 14:42

bold が若干きれいになったような気がする…

288 ：デフォルトの名無しさん：04/05/28 16:45

>>286
じゃあ、1.5を朴ってC#++を作れ。

289 ：デフォルトの名無しさん：04/05/29 05:15

bata2のあとは何？
正規版はいつごろ？

290 ：デフォルトの名無しさん：04/05/29 05:35

>>289
> bata2のあとは何？
BugParadeで tiger-rc で検索したらいくらかひっかかるけど
tiger-beta3 で検索しても何も見つからないので、
Sun としては次は RC を出したいのではないかと推測。

> 正規版はいつごろ？
2004年の前半とかいってたよーな気もするが。
俺の考えでは beta2 -> RC まで1ヶ月、RC -> 正式版まで1ヶ月かかると推測。
とすると最も早くても7月の終わり頃ではないかと思われ。

291 ：デフォルトの名無しさん：04/05/29 10:52

年の前半っていうことは、8月くらいに出ればいいんだよ。
後半の場合は、次の年の３月くらいまで。

あと、夏ごろリリース予定、は、夏ごろにリリース予定日が発表されるという意味。

292 ：デフォルトの名無しさん：04/05/30 13:14

demoの
jvmti っていうのが何をするものかわかりませぬ
あと、sample の jnlp も

293 ：デフォルトの名無しさん：04/05/30 14:52

>>292
JavaNetworkLaunchingProtolco

294 ：デフォルトの名無しさん：04/05/31 02:36

お前らﾍﾞﾀ2が出てますよ

295 ：デフォルトの名無しさん：04/05/31 02:37

Beta2age

296 ：デフォルトの名無しさん：04/05/31 02:40

あおぅ、三日も前に既出だった
吊ってくる

297 ：デフォルトの名無しさん：04/05/31 15:33

Beta1もそうだったけど、ReaderのJISAutoDetectのアルゴリズムにバグがあるね。

298 ：デフォルトの名無しさん：04/05/31 20:37

>>297
これかな？
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5053096

俺は三票とも使っちゃてるので JISAutoDetect 使う人は vote しといてください。

299 ：297：04/06/01 00:41

ありゃ、登録済みか。さっき自分で登録したけど無駄だったか。

300 ：デフォルトの名無しさん：04/06/01 14:43

>>298
voteした。

301 ：デフォルトの名無しさん：04/06/03 01:05

SwingのOpenGL描画うまくいった人いる？
うちのノートのRadeonじゃろくに動かなかったんだけど。

302 ：デフォルトの名無しさん：04/06/03 11:21

yahooのチャットもできない。

303 ：デフォルトの名無しさん：04/06/04 01:40

>> 301

GeForce FXで試したけどえらい遅かった。まだ問題あるみたいね。

ttp://java.sun.com/j2se/1.5.0/docs/guide/2d/new_features.html#ogl
> Note: The latest drivers from both Nvidia and ATI have known issues
> on Microsoft Windows that might cause rendering artifacts in your application.
> We are actively investigating these driver bugs and are working
> with the manufacturers to have them resolved in future driver updates.

304 ：デフォルトの名無しさん：04/06/04 07:38

java2dの描画もopenglを使うようになったって聞いたけど

305 ：デフォルトの名無しさん：04/06/04 08:42

-Dsun.java2d.opengl=true
まだあまり効果無いよ。遅くなることもある。

306 ：デフォルトの名無しさん：04/06/04 11:32

現状でもJava2DはDirectDrawが効くモードにすると遅くなることもあるよ
つーか、Win自体がそうなんだけど
GDI（DDB）のほうがDirectDrawより速いこともあることはある

307 ：デフォルトの名無しさん：04/06/05 01:10

インストールディレクトリの名前がJDKだね。
JDKっていう言葉は1.1までで、それ以降はJ2SEかJ2SDKになってたと思うんだけどね。

308 ：デフォルトの名無しさん：04/06/10 21:47

それにしても一体何時になったら本物がリリースされるんだ？

309 ：デフォルトの名無しさん：04/06/10 21:52

β２いじってるとぱっとみβ１のJava2Dのバグが無くなってたので一安心

OpenGLによるアクセラレーションは確認してないがDirectDrawつかってる
1.4より遅くなければいいや

310 ：デフォルトの名無しさん：04/06/11 01:20

DirectDrawにOpenGLで勝つのは至難

311 ：デフォルトの名無しさん：04/06/11 01:26

速度的な物よりもDirectDrawでのアクセラレーションが限定すぎるのが現状問題
OpenGLで回転拡大縮小程度が加速されればそれなりに使いやすくなるかと

あとは通常合成の他に加算合成をいれてくれぇ～

312 ：デフォルトの名無しさん：04/06/11 01:35

WindowsではデフォでDirectX(Draw + 一部D3D)とGDIだよ。
>>311
System.setProperty( "sun.java2d.translaccel", "true");
System.setProperty( "sun.java2d.ddscale", "true");
これはやってる？

313 ：デフォルトの名無しさん：04/06/11 01:44

>>312
311じゃないが、そんなの知らなかった！ありがとう！

314 ：デフォルトの名無しさん：04/06/11 11:38

>>312
それって1.5での話だよね？
1.4でのアクセラレーションが限定的すぎるといってるだけ

315 ：デフォルトの名無しさん：04/06/11 11:53

>>314
それって１．４の話だよね？だったら、他所行ってやれやｳﾞｫｹ

316 ：デフォルトの名無しさん：04/06/11 12:08

>>315
そのつぎの話をしてるんだからいいんじゃない?

317 ：デフォルトの名無しさん：04/06/11 12:13

現状（１．４）がアクセラレーション効かないのが多い、
１．５ではどこがアクセラレーションきくかという話

もしかしてJava2d触ってるヤツって少ないのか？
１．４のアクセラレーション効く場所とか分かってないようだし

318 ：312：04/06/11 19:32

System.setProperty( "sun.java2d.translaccel", "true");
System.setProperty( "sun.java2d.ddscale", "true");
これやれば1.4でアクセラレーションをアルファの描画と
スケールにかけられるって話なんだが。

分かってないってのはどこが？

319 ：デフォルトの名無しさん：04/06/11 20:02

正確には効いてないじゃないな
その設定でアクセラレーションが効くときは背景が透過しなくなるんだよ

効くには効いてるが実用にならないってこと

あと、いかにもDirectDrawそのままですという感じでクリッピングエリアに
描画がかかるといっきにソフトウェア描画になって使い物にならない
このへんは自動的にやってほしかった

速度だけならともかくハードウェア描画になるときはアンチエイリアスが
かかるし（DirectXの設定に従ってると予想）見た目での違いが
そのままでる（ソフトになると急にゼロ補完）ので厳しい

そしてソフト描画になるとbitmaskにしないと遅くて使えない

ラッピングされているが上の苦しみというか

320 ：デフォルトの名無しさん：04/06/11 20:28

そもそもJavaでOpenGLなんて遅くて使い物にならないから無問題。

321 ：デフォルトの名無しさん：04/06/11 20:34

Javaが従来遅かったのはハードウェアアクセラレーションを積極的に使ってこなかったから。
Windowsだってすべてソフト描画だったらWindow描画だけで大変に重い。

1.4からは描画にvramを使えるようになってそれなりにアクセラレーション効くようになったが
依然限定すぎるというところ。

1.5でどれだけきくようになってるか見物といったところだろう。

でも、ネットで検索してもこの辺の資料がほとんど無いことからみんなサーバーサイドしか
やってないのが分かるね。

322 ：デフォルトの名無しさん：04/06/11 20:54

>>320
バカハケーン

323 ：デフォルトの名無しさん：04/06/11 20:58

クライアントサイドのJavaなんて、アプレット以外は死滅して久しい訳だが。

324 ：デフォルトの名無しさん：04/06/11 21:01

>>323
バカを指摘されて涙ぐみながら、Javaの死滅を語るバカハケーン

325 ：デフォルトの名無しさん：04/06/11 21:02

>>321
sun.java2d.ddscale みたいな設定の説明ってどこに書いてあんの？

326 ：デフォルトの名無しさん：04/06/11 21:13

http://java.sun.com/j2se/1.5.0/docs/guide/2d/flags.html

327 ：デフォルトの名無しさん：04/06/11 21:16

>>325
日本語の資料ではsunの一つのみかと。
でも、このシステムプロパティはセットしても1.4では事実上使い物にならないので注意すべし。

328 ：デフォルトの名無しさん：04/06/11 21:19

>>326-327
さんきゅ

329 ：デフォルトの名無しさん：04/06/12 04:21

言語界の三菱ことJavaには未来はあるのですか？

330 ：デフォルトの名無しさん：04/06/12 07:13

>>321
おいおい。その理屈はおかしいだろ。

> Windowsだってすべてソフト描画だったらWindow描画だけで大変に重い。
つまり、Window描画はハードウェアアクセラレーションを使っていると言いたいんだよな？
それはまさかDirectXアプリだけのことじゃないよな？
Windows描画ってことはGDIのAPIもハードウェアアクセラレーションを
使っているってことだろ。

> Javaが従来遅かったのはハードウェアアクセラレーションを積極的に使ってこなかったから。
そのJavaは内部でWindows描画に何を使っているんだ？
ハードウェアに直接命令を出しているわけないよな。
当然GDIのAPIだろ？ハードウェアアクセラレーションを使っているGDIのAPIだろ？

331 ：デフォルトの名無しさん：04/06/12 09:05

おい、おまいら最新のビルドが落とせるようになってますよ。
http://java.sun.com/j2se/1.5.0/snapshots/index.jsp

332 ：デフォルトの名無しさん：04/06/12 10:00

http://java.sun.com/j2se/1.5.0/ja/index.html
使うならこっちの方がいいよ。

333 ：デフォルトの名無しさん：04/06/12 10:37

>>330
winならGDI使ってるけど
その動きはjavaのバージョンで大きく異なる

GDIレベルだとほとんどアクセラレーション効かないし、直接bit演算
出来ない時点でＪａｖａ2Dのほうが性能的に下回るかと

速度以外に目を向ければかなりのものだとは思うけどな＞Ｊａｖａ2D

volatileimageは積極的にDirectDraw使うんでせめてDirectDrawで
カバーできる範囲くらいはちゃんとやってほしいというところ

334 ：デフォルトの名無しさん：04/06/12 12:32

ハードの性能ぎりぎりまで引き出したい時はC++使えばいいんだけどさ、
そうじゃない時はJavaでいい。
個人レベルでハードの性能ぎりぎりまで使うって事はないでしょ。
Javaが遅いってのはプログラマの腕がへっぽこなだけだと思うんだけどな。

335 ：デフォルトの名無しさん：04/06/12 12:44

Ｊａｖａが速度的にネックとなる場所は少ない
ただ、画像とか扱うと重いのはどこでアクセラレーションきいていてどこがきかないか
それがなかなかはっきりした説明がないから

実際にゲームとか作った人じゃないとこのへんの最適化のコツはつかめないと思われ
だから>>312のようなやつがでる

336 ：デフォルトの名無しさん：04/06/12 13:18

>>335
粘着うざい。

337 ：デフォルトの名無しさん：04/06/12 14:50

>>334
じゃ、NetBeansのプログラマはへっぽこって事で。

338 ：デフォルトの名無しさん：04/06/12 16:04

NetBeans3.6は重さあまりきにならんけどな
>>337のマシンはへっぽこな予感

339 ：デフォルトの名無しさん：04/06/13 01:41

genericsに関する質問
Unsafe type operation: Should not invoke the method add(E) of raw type ArrayList.
References to generic type ArrayList<E> should be parameterized
ってどういう警告ですか？

こっちもお願いします。
Unsafe type operation: The method test(ArrayList<Test2>) in the type Test
should not be applied for the arguments (ArrayList). References to generic types should be
parameterized

340 ：デフォルトの名無しさん：04/06/13 02:17

コード貼れよ

341 ：デフォルトの名無しさん：04/06/13 11:15

あと一年、1.4でも十分かな？

342 ：デフォルトの名無しさん：04/06/13 11:55

>>339
要約すると「ちゃんとgenericとして扱ってくれよ」

343 ：デフォルトの名無しさん：04/06/13 11:57

>>219
SEの話題じゃないけど、
携帯電話で別々のアプリが一つのJVMインスタンスで実行できたら、
携帯電話のJavaアプリも便利になるな。

一番単純な完全分離型でいいから早く欲しいな。

344 ：デフォルトの名無しさん：04/06/13 12:52

携帯でメモリに余裕があるとは考えにくいからどうだろうね

345 ：デフォルトの名無しさん：04/06/13 15:11

>>339
英語読めないし、
そもそも、genericsなんて使った事あるやつなんて
まだいないっしょ。

346 ：デフォルトの名無しさん：04/06/13 15:21

>>336
バーカ

347 ：デフォルトの名無しさん：04/06/13 15:42

>>339
一つ目は ArrayList を使うときに ArrayList<Test2> とやってないと思われる。

二つ目は Test クラスでは test(ArrayList<Test2>) とメソッドを宣言しておきながら
一つ目ので間違えて ArrayList にしちゃったものを引数に与えていると思われる。

348 ：デフォルトの名無しさん：04/06/13 19:04

J2MEはJavaじゃねぇ。Javaの面汚し。

349 ：デフォルトの名無しさん：04/06/13 23:01

英語読めるのうらやましい。
みんな英語読めるの？
Java1.5のドキュメントって日本語ないよね。
そうじゃなきゃ、俺は使えない。

350 ：デフォルトの名無しさん：04/06/13 23:06

プログラミングしようと思ったら英語はできないと半年は時流に取り残されるよ。

351 ：デフォルトの名無しさん：04/06/13 23:30

がーん

352 ：デフォルトの名無しさん：04/06/13 23:39

中学レベルの文法＋プログラム関連の単語、でざっと読む。
まとまった解説とかは日本語で書いてくれるえろいひとのサイトを読む。
でかなりいけると思われる。

353 ：デフォルトの名無しさん：04/06/13 23:51

>>352
そのまとまった解説サイトが出てくるまでに半年はかかるんだってば。

354 ：デフォルトの名無しさん：04/06/14 00:03

オプソなJava処理系はいつになったらJDK1.5に追いつくんだろうか
Swingすらまともに実装されてない現状では何年たっても無理か
やはりJavaはオプソの敵だ

355 ：デフォルトの名無しさん：04/06/14 00:11

1.4すら使いこなせないお前らがそんなこと言うな

356 ：デフォルトの名無しさん：04/06/14 03:29

>>354
そーゆー事は Swing を自力で実装してから言え。

357 ：デフォルトの名無しさん：04/06/14 11:02

英語読めなくてもドキュメントのプログラム見ればだいたいわかんじゃん。

358 ：デフォルトの名無しさん：04/06/14 13:22

>>349
とりあえず1.5の新機能(genericsとか)に関しては
「Java 1.5 Generics」
とそのまんまのキーワードでぐぐればいくつか解説出てくるし、そこを
見ながらサンプル作って試せば大体どんな感じかは分かるはずだが。

359 ：デフォルトの名無しさん：04/06/14 14:40

だが、彼にはできないのだよ。そこが不思議。

360 ：デフォルトの名無しさん：04/06/14 19:58

文学的な表現してるわけじゃないし、慣用句が使われてるわけでもないのに、どうして読めないんだろう。
辞書でいっこずつ単語ひきゃわかる程度なのに。

361 ：デフォルトの名無しさん：04/06/15 01:19

>>360
プログラム用語がわかってないと辞書ひいても読めんかも。

362 ：デフォルトの名無しさん：04/06/15 03:03

それだと、日本語でも読めないわけで。

363 ：デフォルトの名無しさん：04/06/15 11:09

>>362
日本語でも(プログラム関係の文章は)読めてないんでは？
tiger の解説記事なんてググればすぐ出てくるし。

364 ：デフォルトの名無しさん：04/06/16 08:23

まあ2chで概説機構なんてのは幾らなんでもムチャだ。

365 ：デフォルトの名無しさん：04/06/19 16:15

日本語の雑誌で探すのはどうだ？
どうせ出たらすぐ特集組まれるだろうし

少し前のJAVAPRESSでも
Tigerの新機能を逆アセンブルしてる記事があったよ
俺としてはおもしろかったし、わかりやすかった

366 ：デフォルトの名無しさん：04/06/19 22:22

JDK 1.5.0 Beta 3 Build 56

367 ：デフォルトの名無しさん：04/06/20 12:35

正式リリースはいつなんじゃ

368 ：デフォルトの名無しさん：04/06/21 19:01

1.4.x で動いていた自作のネットワークプログラムが
1.5 beta-2 に移行したら

java.lang.OutOfMemoryError: Java heap space

なんて素っ頓狂なエラーでハングするようになった。
止むを得ずソース細かくコンソール出力を入れて細かく追ったら、
>>297 だった。嵌ったよ。

369 ：デフォルトの名無しさん：04/06/22 16:01

1.3でも挙動が変わったし、相変わらずJavaはその辺がいい加減だな。

370 ：デフォルトの名無しさん：04/06/22 16:27

実際のところAutoDetectに頼らないといけないって状況自体がイマイチだ
AutoDetectだとMS932とれんよね？

他にはEUCと分かっていても一部文字が取得できないし
UTF8かMS932かしかwebアプリの選択肢はない

371 ：デフォルトの名無しさん：04/06/23 03:07

>>369
バージョンが大きくかわって、細かい挙動の変更がない環境なんかないよ。
あるなら挙げてほしい。

372 ：デフォルトの名無しさん：04/06/24 09:38

>>371
Delphi

373 ：デフォルトの名無しさん：04/06/24 09:49

>>372
うそつき
ずっとボーランドでやってきたが大きく変わってるよ

374 ：デフォルトの名無しさん：04/06/24 14:52

4→5あたりで、デフォルトが変わったTFormのプロパティがあって、MLで質問流れまくりだったなぁ。

375 ：デフォルトの名無しさん：04/06/29 09:22

JDK 1.5.0 Beta 3 Build 57 age

376 ：デフォルトの名無しさん：04/06/29 09:36

Eclipseも3.0がついに出たことだし
J2SEもそろそろ1.5が出てほしいな

377 ：デフォルトの名無しさん：04/06/29 09:49

おいおまえら、Java2SE5.0Betaが出てますよ。

378 ：デフォルトの名無しさん：04/06/29 09:50

>>331-332
なんじゃ？　J2SE5.0ってなんじゃ？
J2SEが1.4からいきなり5.0に数値がインフレ起こしたのか？
よくわからぬネーミングというかナンバリングだ

379 ：デフォルトの名無しさん：04/06/29 10:17

あれかな。 1.4 -> 1.5 だとマイナーバージョンアップっぽいから
メジャーバージョンアップっぽく 5.0 にしてみますた、ってとこかな。

ところで、APIリファレンスとか java -version の結果とかは
未だに 1.5.0 なんだけど、これは正式版では変わるのかな？

380 ：デフォルトの名無しさん：04/06/29 10:22

今年のJavaOneの最大の目玉が5ですか？(ﾌﾟ
中身はC#1.0以下だけどね。(ｹﾞﾗ

381 ：デフォルトの名無しさん：04/06/29 10:38

>>379
System.getProperty("java.version") と "1.5" とを直接比較するプログラムとかは
書き直さなきゃダメかもね。

382 ：デフォルトの名無しさん：04/06/29 10:50

これは互換性が低下してもいいよねってゆー暗黙のアピールなんだろか？

っつーか -source 1.5 すると -target 1.5 しなきゃいかんみたいだし。
これだったら generics の実装は erasure で無くてもよかったんじゃ…

383 ：デフォルトの名無しさん：04/06/29 12:58

C#が未だに1.0で2.0が出るか出ないかってところなのにJavaは既に5.0。C#の5倍すごい。

384 ：デフォルトの名無しさん：04/06/29 13:29

>>383
いままでが1.4だったから、正確には((5.0 / 1.4) / (2.0 / 1.0))倍だよ。
1.8倍。

385 ：デフォルトの名無しさん：04/06/29 14:07

>>384
C#が1.0でJavaが5.0でどこから1.8なんて数字出てくんの？

386 ：デフォルトの名無しさん：04/06/29 14:25

>>385
計算式書いてあるじゃないか。

387 ：デフォルトの名無しさん：04/06/29 16:30

２３４すっ飛ばして５するわりにJ２SEって。。。
2005年の５かな。それともとうとう狂ったかな、サン。

388 ：デフォルトの名無しさん：04/06/29 16:36

LonghornではJVM廃止されて.NETが肩代わりするらしいね。

389 ：デフォルトの名無しさん：04/06/29 16:44

肩代わりではなく、アメリカお得意の強制委譲だろう。

390 ：デフォルトの名無しさん：04/06/29 16:45

このスレタイはdeprecatedだ。立て直せ。

391 ：デフォルトの名無しさん：04/06/29 17:10

よくわからんからただの誤植だと思ってたけど、マジで5.0からになるの？

392 ：デフォルトの名無しさん：04/06/29 17:12

バージョン番号インフレさせてなにやらすごそうに見せたいんだろ。
売り文句がない時によく使われる手だよ。

393 ：デフォルトの名無しさん：04/06/29 17:38

むしろ凄そうに見せるときは、,NETとかXPとか良くわからない英略語を
使用する場合が多いと思うが。

394 ：デフォルトの名無しさん：04/06/29 17:43

dlしたが、ファイル名は jdk-1_5_0-beta2～だったぞ。
何がしたいんだSunは？

395 ：デフォルトの名無しさん：04/06/29 18:01

ただ単に1.5.0を5.0とを間違えただけってことはないですかねえ？

396 ：385：04/06/29 18:02

>>386
「Javaのバージョン番号がC#の5倍」っていう話でしょ。
1.0を1.8倍しても5.0にはならない。

397 ：デフォルトの名無しさん：04/06/29 18:03

お前らバージョン番号以外に話すことないのかよ。
C#からのパクリばっかで新鮮味がまったくないからしょうがないとはいえ。

398 ：デフォルトの名無しさん：04/06/29 18:22

>>397
C#はAPIが糞。Javaの方が遥かに美しい。

399 ：デフォルトの名無しさん：04/06/29 18:32

>>396
・・・算数がわからない人には通じないジョークだったか。

400 ：デフォルトの名無しさん：04/06/29 18:40

>>395
うーん、1個所だけならまだしも、目に付くところすべて5と書いてあるのでそれはないかと。
J2SE 5 ってなんだよ…

401 ：デフォルトの名無しさん：04/06/29 18:48

正式発表(?)
http://java.sun.com/javaone/tech_sessions1.html

> Java 2 Platform, Standard Edition (J2SE) Version 5.0 (code name "Tiger").
> This new release of the Java platform includes a very large number (almost 100)
> of Java Specification Requests (JSRs) and other updates designed to improve ease
> of development, speed performance, and extend monitoring and management capabilities.
> Even core XML support has been enhanced. If you're wondering why Tiger is J2SE "5.0"
> instead of the traditional J2SE "1.x", Hamilton noted that "because J2SE 5.0 is our
> biggest update to the platform since the original 1.0, it felt kind of stupid that
> we were still calling things 1.1, 1.2, ... And with a big roaring Tiger,
> we wanted to change the numbering system, so we're now going to use the 5.0 number for J2SE,
> and similarly Jave 2 Platform, Enterprise Edition (J2EE) is going to move to 5.0.
> Future releases will be 6.0 and 7.0."

402 ：デフォルトの名無しさん：04/06/29 19:12

>>400
まあ、Java2SE 1.5もどうかと思うけどね。
つまり、Java2ってなんだよ、って。

403 ：デフォルトの名無しさん：04/06/29 19:24

2で文句を言うなら、#とか何だよって話になるが。

404 ：デフォルトの名無しさん：04/06/29 19:45

>>403
J#はJ++++という一応の意味はあるけどね。

405 ：デフォルトの名無しさん：04/06/29 19:46

なんで 2 をとらなかったんだ？？？・・・もうアボガド。

406 ：デフォルトの名無しさん：04/06/29 19:46

より意味不明だけどな。

407 ：デフォルトの名無しさん：04/06/29 19:48

Javaの2ではなく、Java2って言う物だからだろ。

プロジェクトA2をプロジェクトAの2と言わないのと同じだ。

408 ：デフォルトの名無しさん：04/06/29 19:58

1.2のときに大幅に機能アップしたよ！ってことでJava2プラットホームにしたんだよね。
だから今回はJava3プラットホームだ！ってんなら話は分かる。一貫性がなくて美しくない！

409 ：デフォルトの名無しさん：04/06/29 20:06

次はJava2 Version5.0 1.6とかいう名前になるのか？ｗ

410 ：デフォルトの名無しさん：04/06/29 20:07

Solaris8(SunOS5.8)みたいなものだろ。

411 ：デフォルトの名無しさん：04/06/29 20:12

>>399
すごい照れ隠しだな。間違って微分しちゃっただけだろ。
こんな間違いどうってことないからそんなに気にするな。

412 ：デフォルトの名無しさん：04/06/29 20:14

J2SE 6.0 (code name "Mustang")
J2SE 7.0 (code name "Dolphin")

10.x からは J2SE X v10.x になります。

413 ：デフォルトの名無しさん：04/06/29 20:20

Java3SE6.0 for Microsoft .Net Framework

414 ：デフォルトの名無しさん：04/06/29 20:44

>>411
ちゃんと>>384に計算式書いてるのに、なんでこういう突っ込みがくるのかなぁと思ったのさ。
おれとしては、そんなバカな計算してどうする、みたいなツッコミ期待してたのだけど。

415 ：デフォルトの名無しさん：04/06/29 20:50

>>414
C# は (2.0/1.1) にしないとダメじゃないか？
あんま変わらんけど。

416 ：デフォルトの名無しさん：04/06/29 21:22

つーかもうJavaはいいから、他のOSでもまともに使える.NET Frameworkのクロスプラットフォームライブラリと実行環境を作成しる。
M$製の窓にべっとり粘着してる在りがちな糞ライブラリなぞ使う気にならん。

417 ：デフォルトの名無しさん：04/06/29 21:32

>>416
MONOとかで作ってるけど、gtkにべっとり粘着、
もしくはwineにべっとり粘着、どっちがいい？

マルチプラットフォームなGUIライブラリなら、
むしろSWTをいろんな言語で使えるようにした方が早いかも。

418 ：デフォルトの名無しさん：04/06/29 22:51

SWTレベルでいいのならSwingでJComponentを継承して軽いの作った方が手間無く早そう

419 ：デフォルトの名無しさん：04/06/29 23:28

作れるスキルのない奴ほどそういうことを言う。(ｹﾞﾗ

420 ：デフォルトの名無しさん：04/06/29 23:43

ｹﾞﾗとかﾌﾟﾌﾟとか、ちゃんとわかりやすく書いてくれることに、好感すら覚える。

421 ：デフォルトの名無しさん：04/06/29 23:54

どこのjavaスレにもププさんきますね

422 ：デフォルトの名無しさん：04/06/29 23:57

>>401
JCPの圧力があって5.0というネーミングになったのか。
そうみえるのだが

423 ：デフォルトの名無しさん：04/06/30 00:13

日本共産党おそるべし

424 ：デフォルトの名無しさん：04/06/30 00:33

漏れ、generics と foreach が便利すぎて、もう 1.4 に戻れない。
業務でつかっていいですか？

425 ：デフォルトの名無しさん：04/06/30 00:34

今日は最強のJava IDEがリリースされたな。
http://lab.msdn.microsoft.com/express/vjsharp/default.aspx

426 ：デフォルトの名無しさん：04/06/30 00:40

>>425
最強のJavaIDEはEclipse3.0ですが何か？

427 ：デフォルトの名無しさん：04/06/30 00:54

J2SE 5.0(ﾌﾟに対応してないIDEを発表して最強扱いか。(ﾌﾟﾌﾟ
これがJavaの現実だよな。(ｹﾞﾗ

428 ：デフォルトの名無しさん：04/06/30 00:54

>>423
言うと思った

429 ：デフォルトの名無しさん：04/06/30 00:56

>>426
おれもEclipse3.0のことかと思ったら、これだね。
M$のサイト晒してばかりでホントにM$社員みたいだね彼は。
しかも>>427でアホなこといってますよ彼は。

430 ：デフォルトの名無しさん：04/06/30 01:10

>>422
どこ読んだらそーなるん？

431 ：デフォルトの名無しさん：04/06/30 02:08

>>425
それ正式版も只なの？

432 ：デフォルトの名無しさん：04/06/30 11:22

まさかとは思うが>>430は>>423のネタに騙されて
ここで議論しているJCPが本当に日本共産党だと勘違いしているのだろうか。

433 ：デフォルトの名無しさん：04/06/30 11:23

Next Thread の Title は J2SE 5.0

をタイトルに含めよう

434 ：デフォルトの名無しさん：04/06/30 22:51

J2SE5.0はJava1.5.0なの？

435 ：デフォルトの名無しさん：04/06/30 23:42

J2SE 10.0 は Java 2.0 になるの？

436 ：デフォルトの名無しさん：04/07/01 05:35

>>434
Java2 SE 5.0

437 ：デフォルトの名無しさん：04/07/01 14:15

>>417
gtkは色々な環境で動くんだから、特定の環境に粘着とは言わないのでは？

438 ：デフォルトの名無しさん：04/07/01 17:04

>>437
それならSwingでも色々な環境で動くし。

439 ：デフォルトの名無しさん：04/07/01 19:07

>>438
よく見ろ。
Windowsにべったりかどうかの話で、
gtkもべったりだろという反論に対しての話だぞ。

440 ：デフォルトの名無しさん：04/07/01 19:25

べったりのレイヤーがOSかそれより上かなだけで
べったり(依存するものがなくなると存在できない)という意味では
どっちもどっちなんじゃ。

441 ：デフォルトの名無しさん：04/07/01 19:34

まぁ、そんなレベルで話を進めると、JavaはJavaランタイムにべったりとか、
,NETは.NETframeworkにべったりとか、そういうところまで行き着くな。

442 ：デフォルトの名無しさん：04/07/01 20:15

>>441
そんな当たり前の事に行き着くのはオマエだけ。
普通の人にとっては常識。出発点以前。

443 ：デフォルトの名無しさん：04/07/01 21:49

なんで話の流れを読まずに粋がってるんだろう・・・

444 ：デフォルトの名無しさん：04/07/02 12:49

当たり前のことに行き着くんだったら、普通の人は全員行き着くと思うが。

445 ：デフォルトの名無しさん：04/07/02 20:03

Swingで不都合がある環境って、Windowsだけじゃないの？
違うの？

446 ：デフォルトの名無しさん：04/07/02 20:07

LinuxのGUI環境はSwingにも劣る、というだけのことだと思うが。

447 ：デフォルトの名無しさん：04/07/02 20:28

ﾜﾗﾀ
Macはネイティブに近い実装だし、Solarisは見たことないけど、Sunのことだから頑張ってるだろう、と思ったのさ。

448 ：デフォルトの名無しさん：04/07/03 00:25

3年ブリくらいにJDKダウソしたよ。
Javaアプリってメチャクチャ早くなってるね。（漏れのPCも強力になったけど）
正直、ちょっとショック。

449 ：デフォルトの名無しさん：04/07/03 01:58

慣れたら、やっぱ遅いや、って思うんだけどね。
昔みたいに使い物にならんほどじゃないけど。

450 ：デフォルトの名無しさん：04/07/03 08:23

虎って次のMacOS?

451 ：デフォルトの名無しさん：04/07/03 08:48

>>449
そりゃ藻前のマシンのスペックがたいしたことが無く今となっては劣悪なんだろう。
たとえ2GHzでメモリ512ＭＢ積んでいようともな。
サービスや常駐プログラム起動しすぎ重たくなった環境でな。

3GHz, メモリ1GBがあればJavaのGUIサンプルは綺麗に快適に動く

452 ：デフォルトの名無しさん：04/07/03 09:31

>>451
そこまでなくともDemoくらい1GHzクラスでさくさくだろ

453 ：デフォルトの名無しさん：04/07/03 10:43

>>451
うちはPentiumIII866で512MBだけど、サクサク動くが。

454 ：デフォルトの名無しさん：04/07/03 11:16

このスレでは「Java は重い」と書くと叩かれるのか

455 ：デフォルトの名無しさん：04/07/03 11:23

まぁ、、Javaが重い環境だと、.NET Frameworkでも重いからな。
AppletとWindowsネイティブアプリケーション比べて重いとか
言ってるんだったらそりゃAppletの方が重いに決まってるが、
EclipseとVS比べても、起動時間以外は変わらなかったりするし。

456 ：デフォルトの名無しさん：04/07/03 11:55

> EclipseとVS比べても、起動時間以外は変わらなかったりする

なぜ起動時間を除外する？起動時間って結構大事だろ

457 ：デフォルトの名無しさん：04/07/03 12:00

起動時間なんてどうでもいいよ。
スタートアップに登録してしかもPC付けっぱなしだし。

458 ：デフォルトの名無しさん：04/07/03 13:45

起動時間が全体の作業時間のどれぐらいを占めるか、だよな。
ほとんどの場合はどうでもいい。

459 ：デフォルトの名無しさん：04/07/03 13:57

開発者がそんなこと言ってるから普及しねーんだよ

460 ：デフォルトの名無しさん：04/07/03 16:18

ネイティブのアプリケーションと
バーチャルマシーンのアプリケーションで
起動の比較をしても仕方ないな。
VMの起動に時間が掛かるというのは、
ネイティブアプリケーションで言えば
OSを起動している時間と言うことだし。
一回上がってしまえばそれからは結構早い。

461 ：デフォルトの名無しさん：04/07/03 16:30

なんで起動時間を除外すんだよ
本気で起動時間が遅くても構わないと思ってんなら頭悪すぎるぞ
そんな低脳どもは全てのクラスを起動時にロードしてろよカスが

462 ：デフォルトの名無しさん：04/07/03 16:45

IDEのようなのなら確かに起動時間は気にならないね
でも、こまめに終了するようなたぐいだと気にはなる

が、本当に気になるのは最初の１回だけ
２回目以降はSwing使ったヘビーなものでも全然問題ない

463 ：デフォルトの名無しさん：04/07/03 16:48

別に、起動時間が命のアプリはネイティブで、
起動しっぱなしなのはVMででいじゃないか。
一つの言語で全てをまかなわなきゃならんと言う必要はないよ。

Eclipseのような多様なOSで同じ開発環境を作れるアプリケーションや
サーバサイドで上げっぱなしにするアプリケーションなら最適だろうが、
ちょこちょこ上げたり落としたりするメモ帳みたいなアプリには
向かないということで、べつにいいじゃないか。

464 ：デフォルトの名無しさん：04/07/03 16:50

まぁ、そりゃ起動が早いに越したことはないが、
起動が早い言語は、どうして起動が早いのかを
ちょっと考えた方がよいと思う。

465 ：デフォルトの名無しさん：04/07/03 17:12

>>464
で？
何が言いたいの？

466 ：デフォルトの名無しさん：04/07/03 17:15

OSの起動時にVMも起動されてれば結構速いって事じゃない？
IEとMozillaでApplet貼ってるページを見た時みたいな感じでしょ
IEはブラウザ上げたときに一緒に起動されてるからAppletの
表示が速いけど、Mozillaはアクセスがあってから上げるので
一回止まってしまう感じの

467 ：デフォルトの名無しさん：04/07/03 17:20

起動が早くても、その後もっさりなのは勘弁して欲しいよな…
IEとは言わないがな…

468 ：デフォルトの名無しさん：04/07/03 19:06

>>466
> OSの起動時にVMも起動されてれば結構速いって事じゃない？
だからさあ。されてないでしょ？結局>>464は何が言いたいの？

469 ：デフォルトの名無しさん：04/07/03 19:14

Javaは起動が遅くて糞糞糞
って言いたいんだよ。

470 ：デフォルトの名無しさん：04/07/03 19:25

要するに、MSの言語は、アプリケーションの起動が早いぶん、
OSの起動が遅くなってるって事だろ。

スタートアップにJVM入れとけば同じ事だな。

471 ：デフォルトの名無しさん：04/07/03 19:28

>>470
で、「勝手にスタートアップに登録してんじゃねーよ！」と怒られる、と。
ユーザ様はわがままですから。

472 ：デフォルトの名無しさん：04/07/03 19:52

起動が早い言語は、マルチプラットフォームには向かないって言いたいのでは。

473 ：デフォルトの名無しさん：04/07/03 19:54

んなこたない。Sunの妨害にあって頓挫してしまったが
MSが本気になったらJVMでさえ一瞬で起動するのにな。

474 ：デフォルトの名無しさん：04/07/03 20:05

もちろん、MSべったりの仕様になるわけだがね。

475 ：デフォルトの名無しさん：04/07/03 20:06

MSが本気になったらすべてがOSの一部としてWindowsでしか動かなくなる上、
勝手に起動時に立ち上がってしまい、使うまで止めておくという選択肢が無くなる。

476 ：デフォルトの名無しさん：04/07/03 20:29

MSが支配完了した分野はこうなるんだよねー。

Windowsの利益率は86％，MSの事業セグメント別の収益が明らかに
http://itpro.nikkeibp.co.jp/free/NT/NEWS/20021118/2/

477 ：デフォルトの名無しさん：04/07/03 20:38

大体言語のポータビリティーなんてコンパイラベンダとそのユーザーがその度合いを決定すべきでなのに
Sunがアホみたいにでしゃばるから寂れてしまったんだよな。自業自得だよ。

478 ：デフォルトの名無しさん：04/07/03 20:58

アホみたいにでしゃばってなかったら、今頃もう無かったかもしれないがな。

479 ：デフォルトの名無しさん：04/07/04 00:09

でしゃばって利益を出せないアホ。www

480 ：デフォルトの名無しさん：04/07/04 00:16

>>479
> 大体言語のポータビリティーなんてコンパイラベンダとそのユーザーがその度合いを決定すべき

ひとつの「コンパイラベンダ」が、他を無視できるほど大きくて、ユーザーの環境が他を無視できるほどひとつの環境にかたよっていれば、それでいいね。

481 ：IBM：04/07/04 00:17

>>479
いやぁ、利益出させていただきましたよ。

482 ：デフォルトの名無しさん：04/07/04 00:43

>>459
サーバアプリケーションというものはほとんど再起動を必要としない。
よってサーバサイドで十分に普及しているJavaのことを
「起動時間が(ry」なんてJavaの世界でいうのも(ry

483 ：デフォルトの名無しさん：04/07/04 00:44

>>482
文脈嫁

484 ：デフォルトの名無しさん：04/07/04 00:44

>>482
でも、クライアントサイドでも普及したがってるんだから。

485 ：デフォルトの名無しさん：04/07/04 00:48

これからそれがさらに普及してゆくのも時間の問題。

486 ：デフォルトの名無しさん：04/07/04 01:16

ひたすら長そうだ

487 ：デフォルトの名無しさん：04/07/04 01:35

起動時に、VMも起動させとけ。
これで終了した話題だな。

ってか考えたら分かるだろ。こんな対処方法。

488 ：デフォルトの名無しさん：04/07/04 02:36

考えてわかるのと、実際に実現させるのとはちがう。

489 ：デフォルトの名無しさん：04/07/04 04:09

>>488
立ち上がって、すぐ終了するソフト作ればいいんでねーかい？

490 ：デフォルトの名無しさん：04/07/04 04:13

>>489 終了したらJVMも終了してしまう予感

491 ：デフォルトの名無しさん：04/07/04 04:57

サービスとして起動時から

492 ：デフォルトの名無しさん：04/07/04 05:00

>>490
あれ？
でも、JAVAアプリ立ち上げて、終了して、
それ以降他のJAVAアプリの立ち上げも早くならない？
俺の勘違い？

493 ：デフォルトの名無しさん：04/07/04 05:06

>>492
DLL とかのキャッシュが効いてるのでは？

494 ：デフォルトの名無しさん：04/07/04 05:32

一度起動しておくと、次は結構早く起動するね。
>>493 の言うとおりキャッシュだろうけど。

495 ：デフォルトの名無しさん：04/07/04 07:52

メモリの厳しい状況だと、ひとつアプリ立ち上げてるときは、他のアプリの立ち上げ速いけど、全部おわらすと、やっぱり立ち上げ遅い。

496 ：デフォルトの名無しさん：04/07/04 09:15

Win32APIで済むのにわざわざ別のAPIセット入れなきゃならないなんて迷惑な話だよな。

497 ：デフォルトの名無しさん：04/07/04 09:40

>>496
そー思うなら入れなきゃ良いだけの話だと思われ。

498 ：デフォルトの名無しさん：04/07/04 09:49

とりあえず1.5からはPriJITが導入されて二回目以降のJavaの起動が早くなるのは確実だろう

499 ：デフォルトの名無しさん：04/07/04 10:16

>>497
｢起動が遅い」とかに加えて「わざわざ別のAPIセット入れなきゃならない」って言うのがデメリットの１つだろ ?

500 ：デフォルトの名無しさん：04/07/04 10:19

>>499
>>497

501 ：デフォルトの名無しさん：04/07/04 10:37

>>500
真性のヴァカで、話の流れが読めない君 ?
それとも、単なる嵐さん ?

502 ：デフォルトの名無しさん：04/07/04 10:40

>>499
デメリットが嫌なら、使わなきゃ良いだけ。

503 ：デフォルトの名無しさん：04/07/04 11:06

Java嫌いさん「糞っ糞っ、COBOLとVBのエキスパートである俺が、
　なんで今更Javaの仕事なんてしなきゃならんのだ。
　世の中Javaの案件だらけで激しくむかつく。
　Javaなんて起動遅いし、わざわざ別のAPIセット入れなきゃならんし
　糞だ、糞！」

新人君「Java嫌いさん、ここの設計どうにかなりませんか？
　なんかオブジェクト指向的におかしいんですけど」

Java嫌いさん「お、オブジェクト指向？
　VB風COBOL風に組んでなにが悪いんじゃヴォケ！
　俺は今までそうやって組んできたんじゃ！」

504 ：デフォルトの名無しさん：04/07/04 11:17

Cを最強の言語と信じていたCマンセー君にも該当するのう。

505 ：デフォルトの名無しさん：04/07/04 12:23

>>496
VBもそうだね。

506 ：デフォルトの名無しさん：04/07/04 12:47

WIN32APIでGUI作ると
Javaの１０倍以上時間がかかるぞ。

507 ：デフォルトの名無しさん：04/07/04 13:01

>>496
別に覚える必要がある、という点では、MFCも含まれるのかな。

508 ：デフォルトの名無しさん：04/07/04 13:11

>>506
君ならね。

509 ：デフォルトの名無しさん：04/07/04 14:13

http://www.xlsoft.com/jp/products/jet/index.html
↑
このソフトの体験版使ってみたけど、JVMの起動がむちゃくちゃ早くなったよ。
swingの挙動がサクサクになる。
別に処理速度自体は早くならないけれど、オブジェクト大量生成とか、ガベージ関連はサクサクっぽい。

510 ：デフォルトの名無しさん：04/07/04 14:24

>>508
Win32SDKで、それなりにコントロール配置したウィンドウ出すプログラムを、Javaで記述する場合と同じ時間で書けるのなら、尊敬する。

511 ：デフォルトの名無しさん：04/07/04 18:06

>>510
お前低脳なんだな…。

512 ：デフォルトの名無しさん：04/07/04 18:17

>>511
うん。そうみたい。
低脳だから、WinMainとかWinProcとかWM_COMMANDとか書くより、ActionListener書くの方がめちゃくちゃ速く書ける。

513 ：デフォルトの名無しさん：04/07/04 18:28

>>512
もう分かったから職安へお帰り

514 ：デフォルトの名無しさん：04/07/04 19:29

>>513
WM_COMMAND書けるよりもActionLister使える方が仕事みつけやすいし。
GlobalAcllocなんてやってられん。

515 ：デフォルトの名無しさん：04/07/07 01:19

J2SE5.0でもJDK1．5だべ？
SunOS5.xみたいだな。

516 ：デフォルトの名無しさん：04/07/07 11:00

J2SE5.0という呼称だけはいただけない。次どうすんだよ（ｗ

517 ：デフォルトの名無しさん：04/07/07 11:12

次はJ2SE2005とかだろ

518 ：デフォルトの名無しさん：04/07/07 12:35

>>517 口に出すと現実になりそうで怖すぎ。

519 ：デフォルトの名無しさん：04/07/07 12:36

俺のアプリなんてバージョン0.0.0.329とかだけどな

520 ：デフォルトの名無しさん：04/07/07 12:41

とりあえず、最終的に
java.class.version
java.specification.version
java.version
がどうなるかが気になる。

521 ：デフォルトの名無しさん：04/07/07 13:22

おにたまってHSPをCにするコンバーターを開発してたんだな。
Cを異様に嫌う厨房が手のひらを返して喜んで使いそう(ﾌﾟ

522 ：デフォルトの名無しさん：04/07/07 16:25

JavaWorld廃刊おめでとうございます

523 ：デフォルトの名無しさん：04/07/07 16:27

>>520
その辺は変わらない(変えられない)と思うけどねぇ。

524 ：デフォルトの名無しさん：04/07/07 16:30

>>522
廃刊ってどういうこと？

525 ：デフォルトの名無しさん：04/07/07 16:40

J2SE5.0ってJ2SE1.5のことなんでしょうか？
誰か説明しちくり。

526 ：デフォルトの名無しさん：04/07/07 16:41

Goodbye again, JavaWorld
Daniel H Steinberg (January 13, 2004 7:04AM PT)
URL: http://www.java.net

527 ：デフォルトの名無しさん：04/07/07 16:46

Java Worldって日本の雑誌じゃねーの？

528 ：デフォルトの名無しさん：04/07/07 16:54

JavaWorldといいJava Developerといい、
Javaの雑誌がどんどんなくなっていくな。

529 ：デフォルトの名無しさん：04/07/07 16:55

http://blogs.msdn.com/cambecc/archive/2004/07/06/173253.aspx

530 ：デフォルトの名無しさん：04/07/07 18:13

JavaWorld廃刊、
JavaDeveloper廃刊、
JavaOneカンファレンス実質死亡。
詳しくはマ板へ。

531 ：デフォルトの名無しさん：04/07/07 18:20

MSの圧力

532 ：デフォルトの名無しさん：04/07/07 18:25

単に雑誌が乱立しすぎただけでしょ。
JavaPressとJavaWorldとJavaDeveloperと、他にも何かあったっけか？

Java専門誌でなくてもCマガで初心者向け連載あるし、
Unix系の雑誌では鯖側ソフトのインストール記事とかあるし。

533 ：デフォルトの名無しさん：04/07/07 18:42

というか
なぜそのブログが半年前の記事であることを
誰も突っ込まないのでしょう？
なぜjavaworld本家に何もアナウンスがないことを
誰も突っ込まないのでしょう？

534 ：デフォルトの名無しさん：04/07/07 18:56

なんか動員されて書き込んでるやつらがいるのかな。

535 ：デフォルトの名無しさん：04/07/07 19:36

Cマガかぁ
ひさしく読んでないな

536 ：デフォルトの名無しさん：04/07/08 00:21

>>517
次って言うかなるほどなネーミングだな。
J2SEには一年半後とに0.1づつバージョンをアップデートするというルールを作っていたみたいだが
ここで名前を変えてみたってところか。

537 ：デフォルトの名無しさん：04/07/08 04:53

Solaris2.7 => Solaris7
ってのと同じだろ。
Sunの常套手段。

538 ：デフォルトの名無しさん：04/07/08 05:58

3.5 > 2000 > XP
みたいに、製品だす度にバージョン番号の法則がかわるよりはましかな。

539 ：デフォルトの名無しさん：04/07/08 09:11

バージョン番号じゃなくて商品名だと思うんだけど。
Windows2000 = WindowsNT5.0

540 ：デフォルトの名無しさん：04/07/08 10:07

ああ、それはいい言い方だね。
商品名にバージョン番号が含まれる必要はない、と。
マーケティングに自由を。ユーザーに混乱を。

541 ：デフォルトの名無しさん：04/07/08 13:45

>>540
そうだよ？
Microsoftは初心者を騙すのがうまいから今の地位を築けたんだよ。
>539が何か気に障ったかい？

542 ：デフォルトの名無しさん：04/07/08 16:21

>>541
そっちこそ、なにか気に障った？

543 ：デフォルトの名無しさん：04/07/08 19:27

>>542
？

544 ：デフォルトの名無しさん：04/07/09 00:30

>>538
MetaFrameみたいに1.0→XP→3.0と元に戻されても萎えるが

545 ：デフォルトの名無しさん：04/07/09 09:04

>>544
MS-Officeもそうじゃない?

546 ：デフォルトの名無しさん：04/07/10 18:13

【JavaOne 2004】次期J2SE「Tigerリリース」の正式版はこの夏登場
http://itpro.nikkeibp.co.jp/free/JAV/NEWS/20040629/146507/

J2SE5.0Tigerリリースは，現在ベータ2の段階にあり，
今年夏には正式版が登場する。このリリースでは
「1995年のJava言語登場いらいの言語仕様の変更」が加わる。
特に重要なのはメタデータで，EJB3.0，JAX-RPC2.0，JDBC4.0など
メタデータを取り入れたAPIは，従来に比べずっとプログラムが簡素になる。

　今後のJ2SEのロードマップも示した。今後予定しているJ2SEのリリ
ース番号を1.5から5.0，1.6から6.0へと振り直すとともに，リリース間隔を
18カ月程度に短縮し，新技術を取り入れやすいようにする。

　セッションでは「要注目」の多数の技術を取り上げた。
例えば「Groovy」言語（JSR-241）は，「Java言語よりも動的で
スクリプト言語風の小さなプログラム向けの技術」である。他のスクリ
プト言語，特にPHPと連携するためには，JSR-232が準備中である。

　J2EE5.0（J2EE1.5改め）の概要も紹介した。EJB3.0やJSF（JavaServer Faces）をコア技術として取り込む。J2EE5.0の正式版は，2005年後半に登場する予定である。

547 ：デフォルトの名無しさん：04/07/11 00:11

タイガーは丈夫です

548 ：デフォルトの名無しさん：04/07/11 00:54

タイガースはどうですか？

549 ：デフォルトの名無しさん：04/07/13 13:10

>>532
JWとJDは宣伝っぽいのが多かったからね。
JPはオープンソースの活用が殆どなんで、
生き残ってるんだろう。
俺も一応3種類とも買ってるけど、JP以外は殆ど見返さない。

550 ：デフォルトの名無しさん：04/07/13 13:37

JWは、話題が早すぎて、１年前くらいの特集がタイムリーなんだが・・・
JPはリファレンスばっかりだから、使い分けだな。

551 ：デフォルトの名無しさん：04/07/13 14:53

たしかにJavaPressが実用度ではトップクラスなんだけど
ここんところ酷い内容で買う価値がほとんど無いなぁ

552 ：デフォルトの名無しさん：04/07/13 15:19

ORマッピングの話やら、コンテナとかサーバーサイド技術が、WEB+DB PRESSに食われてるからねぇ。
JWは、最近抽象的な特集ばかりなのが、気になる。うわさ通り持ちネタ放出してるだけ？

553 ：デフォルトの名無しさん：04/07/20 12:53

J2SE5.0が今年の夏にでるって具体的にいつ頃？
もう夏だしそろそろ出ておくれよ真タイガージェット

Genericsが待ち遠しいのだよタイガーアッパーカット

554 ：デフォルトの名無しさん：04/07/20 13:28

>>553
β晩でもつかってなさい。

555 ：デフォルトの名無しさん：04/07/20 13:58

いやだ。
それで既存のコードを実装してバグ出したくない。

556 ：デフォルトの名無しさん：04/07/20 14:07

JDK 5.0 Beta 3 Build 58 age

7/14日に出てたみたい。

557 ：デフォルトの名無しさん：04/07/20 14:08

>>555
「既存のコードを実装して」って具体的にどーゆー事？
既存のソースをコンパイルする事か？

558 ：デフォルトの名無しさん：04/07/20 14:11

いちいち揚げ足をとりおって。
既存1.4コードに1.5コードを追加修正する間際にベータ版固有のバグを(ry
だ

559 ：デフォルトの名無しさん：04/07/20 14:13

>>556
Date Released は 07/19/2004 だけど？

560 ：デフォルトの名無しさん：04/07/20 14:14

>>558
ベータ版固有のバグって具体的には？
リリース版でもバグが全く残ってないなんて保証はないのに？

561 ：デフォルトの名無しさん：04/07/20 14:16

とにかく1.4がリリースしたときのような気分で1.5を使いたいのじゃーーーーー

562 ：デフォルトの名無しさん：04/07/20 14:20

>>561
jar の中とか漁って beta の文字を全部取れば「気分」は出るんじゃないか？

563 ：デフォルトの名無しさん：04/07/20 14:20

廚ウゼェ。
リリース版しか使えない体ならうだうだ言わずおとなしくリリース待ってろよ。

564 ：デフォルトの名無しさん：04/07/20 14:31

>>562
それはあまりにも寒すぎる

565 ：デフォルトの名無しさん：04/07/20 15:09

>>558
どうせ本番リリースの前に本物がリリースされるだろ。
既存のAPIではバグがでる可能性は低いし。切り分けもできるし。

やらない理由は、探せばいくらでもあるものだ。
Tigerきにいったなら、とりあえず、使え。

そして人身御供

566 ：デフォルトの名無しさん：04/07/20 16:12

で、Autodetect のバグは取れたんかいな

567 ：デフォルトの名無しさん：04/07/20 22:32

俺もう使ってる。しかも業務で。
今開発中で完成する頃にはJ2SE5.0もbetaが取れてるだろうという読み。

Map<int, String> とか、すごく気持ちいい。
キャスト氏ね！て感じだね。爽快だよ。

568 ：デフォルトの名無しさん：04/07/20 22:36

>566
さっき試したら直ってたよ。

569 ：デフォルトの名無しさん：04/07/20 22:39

>>567
> Map<int, String>
コンパイルエラーにならんか？

570 ：デフォルトの名無しさん：04/07/20 22:45

プリミティブ型指定できたっけ？

571 ：567：04/07/20 22:59

ごめんホントは
Map<String, String>
でした。

572 ：デフォルトの名無しさん：04/07/20 23:06

ごめんホントは
Map<Object, Object>
でした。

573 ：デフォルトの名無しさん：04/07/22 00:53

>>565
バイト先で使いたいんだがつかわしてくれんよ

574 ：デフォルトの名無しさん：04/07/22 17:52

>>573
雑兵にそんなことされたら、たまらない

575 ：デフォルトの名無しさん：04/07/22 18:18

>>574
雑兵どころか、小間使い

576 ：デフォルトの名無しさん：04/07/28 15:27

JDK 5.0 Beta 3 Build 59
http://java.sun.com/j2se/1.5.0/snapshots/index.jsp

577 ：デフォルトの名無しさん：04/07/28 15:30

>>567
> 今開発中で完成する頃にはJ2SE5.0もbetaが取れてるだろうという読み。
完成する頃には RC の途中だったりして。

578 ：デフォルトの名無しさん：04/07/28 15:38

javaってCで開発してるの？
道理で開発が遅いわけだ。

579 ：デフォルトの名無しさん：04/07/28 16:18

JavaVMはバッファオーバーフロー起こします。C/C++で作られてるから。

580 ：デフォルトの名無しさん：04/07/28 18:01

>>579
バグ報告するから、具体的にどこでバッファオーバーフロー起こすのか教えてくれ。

581 ：デフォルトの名無しさん：04/07/28 18:04

そんなの指摘し始めたらこのスレが埋まってしまうよ。

582 ：デフォルトの名無しさん：04/07/28 18:06

>>581
ではとりあえず、具体的にどこでバッファオーバーフロー起こすのか3箇所挙げてください。

583 ：デフォルトの名無しさん：04/07/28 18:28

SunとNDA結んでいるからSun以外には教えられないな。

584 ：デフォルトの名無しさん：04/07/28 18:44

普通のNDAだったら >>579 書いた時点でアウトなんだが。

585 ：デフォルトの名無しさん：04/07/28 18:55

579は俺じゃないし。

586 ：デフォルトの名無しさん：04/07/28 18:58

ちなみにNDA的には >>581 でもアウトの可能性高いんだけど。

587 ：デフォルトの名無しさん：04/07/28 19:00

夏だねぇ

588 ：デフォルトの名無しさん：04/07/30 16:41

それはそうと、GIF画像生成はどうなるの？

589 ：デフォルトの名無しさん：04/07/30 21:00

>>574
バイト先で勝手にEclipse3.0を使ってみたが
漏れの影響を受けて上司までEclipse3.0を使い始めた。
今までAnt + 秀丸だったという。

590 ：デフォルトの名無しさん：04/07/30 21:23

>>589
Eclipseなんか、システムに関係ない。
話のレベルが違うだろ。
だからバイトには(ry

591 ：デフォルトの名無しさん：04/07/30 21:25

>>590
あなたのレスから、関連性を見出すことができません:)

592 ：デフォルトの名無しさん：04/07/30 21:26

有能なバイト君に嫉妬しているうだつの上がらないリーマンコーダなんだろ。
ほっといてやれよ。

593 ：デフォルトの名無しさん：04/07/30 21:28

>>591
JDK1.5を勝手に使われたら困るっていってるところで、Eclipseを使って・・・と自慢されても、ねぇ。

594 ：デフォルトの名無しさん：04/07/30 21:33

>JDK1.5を勝手に使われたら困るっていってるところで
脳内前提を勝手にでっち上げて反論されても、ねぇ。

595 ：デフォルトの名無しさん：04/07/30 21:39

つーか、仕事なら開発環境勝手に使うのやばいだろ
実績があるとかそういうのまったく関係なしで

596 ：デフォルトの名無しさん：04/07/30 22:10

>>594
過去レスもたどれないのか。

>>595
基本的に関係ないだろ。
Eclipseにしろ、NetBeansにしろ、開発環境はコードに影響与えないし。

597 ：デフォルトの名無しさん：04/07/30 22:11

おまいら、秀丸＋Ant　で開発していた上司を先に晒しあげしないと。

598 ：デフォルトの名無しさん：04/07/30 22:12

>>596
> Eclipseにしろ、NetBeansにしろ、開発環境はコードに影響与えないし。
開発環境統一してるとこだとダメだけどね。

599 ：デフォルトの名無しさん：04/07/30 22:15

>>597
秀丸 + Ant って何か悪いの？

600 ：デフォルトの名無しさん：04/07/30 22:15

>>598
Eclipse使ってるところでNetBeans使うメリットはあまりないけど、NetBeansやらJBuilder使ってるところでEclipse使ってリファクタリングとかはありだと思うけど。
単なるツールだから。

単なるツールを勝手に使えない組織というのももちろんあるけど、それはまた別の話で。

601 ：デフォルトの名無しさん：04/07/30 22:19

>>599
それなりに秀丸カスタマイズして使ってたなら、十分あり。
Ant使わず、バッチファイルでやってたら晒し上げだけど。

602 ：デフォルトの名無しさん：04/07/30 22:22

秀丸 + Mavenだったら尊敬してたのに。

603 ：デフォルトの名無しさん：04/07/30 22:25

>>600
> Eclipse使ってるところでNetBeans使うメリットはあまりないけど、
GUIエディタは NetBeans のが優秀だったりとメリットはあると思うが。

> NetBeansやらJBuilder使ってるところでEclipse使ってリファクタリングとかはありだと思うけど。
自動出力されるコードが統一される保証が無いよーな。
それに二つの開発環境使い分けると単一の開発環境使う時より操作ミスとかが起こりやすいしね。

604 ：デフォルトの名無しさん：04/07/30 23:09

>>603
別に補助になるツールの方では激しく自動出力しないでしょ。
自動出力しても、コメントくらいが違うだけだろうし。
それに、特にリファクタリングだと、操作ミスより手でやったときの変更漏れやミスの方が怖い。

NetBeansのGUIビルダこそ、自動出力コードが著しくEclipse VEと違うし。

というか、オレとしては、開発環境がNetBeansと決まっていたらメモ帳でコード変更するのも許されないのか、という感じをうける。
メモ帳でコード編集していいなら、Eclipseでコード編集してもいいじゃん。

ソフト勝手にインストールしちゃだめな組織もあるだろうけど、それはやっぱり別の話で。

605 ：デフォルトの名無しさん：04/07/30 23:42

まっとうな企業なら勝手にインストールして
好き勝手な開発環境つかうってのはありえん

GUIまともに作るなら今はNetBenasしか選択肢はない
VEがまともになるのはいつのことだろうか

606 ：デフォルトの名無しさん：04/07/31 00:00

>>605
GUIはJBuilderの方がいいらしいけど。
コンポーネント配置の位置がわかりやすいのだけはNetBeansよりVEのほうがいい。

> まっとうな企業なら勝手にインストールして
> 好き勝手な開発環境つかうってのはありえん

規模が大きいところならそうかも知れんけど。
中小ならそうでもないんじゃない？
それに、いまどきEclipse使わせてもらえないような企業がまっとうな技術もってるかっていう話も。

607 ：デフォルトの名無しさん：04/07/31 01:50

>>604
> 自動出力しても、コメントくらいが違うだけだろうし。
> NetBeansのGUIビルダこそ、自動出力コードが著しくEclipse VEと違うし。
矛盾だね。
たかがリファクタリングの自動生成コードであっても
複数の開発環境が自動生成するコードを混ぜると
後で一括処理するときに障害になる可能性が否定できないしねぇ。

> それに、特にリファクタリングだと、操作ミスより手でやったときの変更漏れやミスの方が怖い。
誰も手作業でやれなんて言ってないよ。

> というか、オレとしては、開発環境がNetBeansと決まっていたらメモ帳でコード変更するのも許されないのか、という感じをうける。
コードを自動生成するならメモ帳も使用禁止だろね。

608 ：デフォルトの名無しさん：04/07/31 01:52

>>606
> それに、いまどきEclipse使わせてもらえないような企業がまっとうな技術もってるかっていう話も。
Eclipseを開発環境として選択するのと、技術力とは全く関係ないと思われ。

609 ：デフォルトの名無しさん：04/07/31 04:04

今時テキストエディタで開発してるところは明らかに技術（収集能）力が低いわけだが。

610 ：デフォルトの名無しさん：04/07/31 09:06

>>606
JBuilderもNetBeansもEclipseもJdevもさわったが
JBuilderはGUI開発が分かりやすいだけ
といってもそのわかりやすさは大事なんだけども
あとJDevはJBuilderまんま

NetBeansのいいところは自分で作ったカスタムパネルとかを
フォームにぺたぺた貼り付けるのが容易というところと
pack指定ができること

611 ：デフォルトの名無しさん：04/07/31 10:36

>>609
Eclipse を使わなかったら必ずテキストエディタ使ってるのか？

612 ：デフォルトの名無しさん：04/07/31 12:27

>>607
> たかがリファクタリングの自動生成コードであっても
> 複数の開発環境が自動生成するコードを混ぜると

あの、リファクタリングって知ってます？
クラス名書き換えとか、パッケージの移動とかですよ。
混ぜるとどうのこうのというのは起きないだろ。

それに、何の一括処理するんだよ。

613 ：デフォルトの名無しさん：04/07/31 14:04

>>612
> クラス名書き換えとか、パッケージの移動とかですよ。
それはリファクタリングのごく一部。

> 混ぜるとどうのこうのというのは起きないだろ。
どうしてもというなら会社に損害与えない事が保証できれば使ってもいーんじゃないか？

> それに、何の一括処理するんだよ。
リファクタリング支援機能の一つ、クラス名書き換えも立派な一括処理なんだけどね。

614 ：デフォルトの名無しさん：04/07/31 14:28

>>597
Eclipse使うのも開発効率が良くていいいことだが、
Ant使うなら上等だろ。Antでも十分に開発効率は高いんだし。
Eclipseが重たいという人はほとんどがAntを使っているらしいぞ。

Ant + Emacs みたいな感じでな。

615 ：デフォルトの名無しさん：04/07/31 14:30

>>605
> まっとうな企業なら勝手にインストールして
> 好き勝手な開発環境つかうってのはありえん

なにいっているんだ。

まっとうな大手企業でも、R&D系なら好き勝手にやらせてくれるはずだ。
SoftBankみたいになにもかも制限され、監視されるというのはおかしいし
開発効率が悪化する。

> GUIまともに作るなら今はNetBenasしか選択肢はない
> VEがまともになるのはいつのことだろうか

616 ：デフォルトの名無しさん：04/07/31 14:30

>>613
なんか、言ってることが支離滅裂じゃないの？

別に、リファクタリングのすべてをやらないといけないわけじゃないし。
パッケージ移動やクラス名変更やらがあったときに、Eclipse使ってリファクタリング機能使うのがいいんじゃないの？って言ってるだけなんだけど。
他のリファクタリングでも、そんなにクセのあるコード吐き出したりしないだろ。
それに、クラス名書き換えの一括処理ができなくなるようなコード自動生成ってどんなんだよ。

617 ：デフォルトの名無しさん：04/07/31 14:31

>>609
> 今時テキストエディタで開発してるところは明らかに技術（収集能）力が低いわけだが。
んなこたあない。Emacsはばかにできないぞ。
それとテキストエディタであってもAntを使えばかなりの技術力があるほうだろう。

618 ：デフォルトの名無しさん：04/07/31 14:33

>>607
> >>604
> > 自動出力しても、コメントくらいが違うだけだろうし。
> > NetBeansのGUIビルダこそ、自動出力コードが著しくEclipse VEと違うし。
> 矛盾だね。
> たかがリファクタリングの自動生成コードであっても
> 複数の開発環境が自動生成するコードを混ぜると
> 後で一括処理するときに障害になる可能性が否定できないしねぇ。

CVSとかでちゃんとバージョン管理していないから混乱するんだろ。

619 ：デフォルトの名無しさん：04/07/31 14:37

お前ら口論できれば口実は何でもいいんだろ

620 ：デフォルトの名無しさん：04/07/31 14:41

当たり前じゃないか。
台風で外出もできんのに。

621 ：デフォルトの名無しさん：04/07/31 14:47

>>617
テキストエディタには、Emacsは含めない w

622 ：デフォルトの名無しさん：04/07/31 14:55

>>616
> パッケージ移動やクラス名変更やらがあったときに、Eclipse使ってリファクタリング機能使うのがいいんじゃないの？って言ってるだけなんだけど。
開発環境を統一している職場で、かつ Eclipse を使っていない場合でも
無理やり Eclipse を使ってリファクタリングした方が良いって話でしょ？

623 ：デフォルトの名無しさん：04/07/31 15:07

>>621
ちなみに、テキストエディタに含めない根拠は？

624 ：デフォルトの名無しさん：04/07/31 15:19

>>623
Emacs使ったことないの？

625 ：デフォルトの名無しさん：04/07/31 15:21

Emacsはただのエディタだよ。
IDEとは比べ物にならない。

626 ：デフォルトの名無しさん：04/07/31 15:21

>>624
あるよ。で、テキストエディタに含めない根拠は？

627 ：デフォルトの名無しさん：04/07/31 15:25

>>626
テキストエディタというには、あまりにも高機能。
ちなみに、ここでのテキストエディタは、>>609でのテキストエディタね。

最近スレの流れ読まずに突っ込むヤツいるから。

628 ：デフォルトの名無しさん：04/07/31 15:26

>>625
Emacsは設定次第でIDEともいえると思うが。
何もプラグインの入ってないEclipseと同じだと思う。

629 ：デフォルトの名無しさん：04/07/31 15:27

>>622
無理やりって、別に無理しないとEclipseが使えない低能なら、使わなくていいよ。

630 ：デフォルトの名無しさん：04/07/31 15:29

>>627
なにを持って高機能といってるのか >>609 見てもわからん。
ちなみにjEditはテキストエディタか？秀丸はテキストエディタか？

631 ：デフォルトの名無しさん：04/07/31 15:32

>>630
つまり、行間を読む能力がない、と。

632 ：デフォルトの名無しさん：04/07/31 15:32

>>629
> > 開発環境を統一している職場で、かつ Eclipse を使っていない場合でも
> > 無理やり Eclipse を使ってリファクタリングした方が良いって話でしょ？
> 無理やりって、別に無理しないとEclipseが使えない低能なら、使わなくていいよ。
能力は問題にしてないんだけど。職場のルールは無視しても良い、と？

ところで、最近は Eclipse 使う人間は使わない(使えない、ではない)人間を
低脳よばわりしてストレス解消するのが流行ってるのか？

633 ：デフォルトの名無しさん：04/07/31 15:36

>>631
> つまり、行間を読む能力がない、と。
つまり、相手に行間を読んでいただかなければならないほど文章を書くに不自由している、と。

634 ：デフォルトの名無しさん：04/07/31 15:37

>>632
前から出てるけど、勝手にツールインストールしちゃいけないとかいうのは別の話ね。

で、例えば職場でJavaのコーディングにはJBuilder使いなさいというルールがあったとしたら、メモ帳でソースコードいじるのもだめなの？
Eclipseのインストールが許されてるなら、コードいじるのに部分的にEclipse使ってもいいと思うんだけど。

635 ：デフォルトの名無しさん：04/07/31 15:39

>>633
そうだねぇ。
あんたみたいに読解能力の低い人にちゃんと理解させる文章を書くだけの能力は、オレにはない。

636 ：デフォルトの名無しさん：04/07/31 15:42

>>634
> で、例えば職場でJavaのコーディングにはJBuilder使いなさいというルールがあったとしたら、
> メモ帳でソースコードいじるのもだめなの？
普通は不可。例えば JBuilder の GUIエディタが吐いたコードとか勝手に書き換えられたら困るでしょ。

637 ：デフォルトの名無しさん：04/07/31 15:44

>>635
文章書く能力っつーか、説明する能力とか、論理的思考力も足りなさげ。

638 ：デフォルトの名無しさん：04/07/31 15:49

>>636
いじっちゃだめな部分はいじらなければいいじゃん。
まぁ、どこいじってよくて、どこいじっちゃだめかわからんような奴がたくさんいるような組織だと、ルールとしては指定したツール以外使用禁止になるんだろな。

639 ：デフォルトの名無しさん：04/07/31 15:51

>>637
話の流れとかフインキ(←なぜか変換できない)読めないやつに説明する能力は、ない。

640 ：デフォルトの名無しさん：04/07/31 15:52

>>638
その屁理屈がとおるなら、手動でクラス名を変更してもミスは全く考慮しなくて良いな。

641 ：デフォルトの名無しさん：04/07/31 16:01

>>640
なんか、自分が屁理屈ばっかりいってるから、他も屁理屈に見えるんだね。

じゃあ、GUIじゃなければ、いいんじゃないの？
それに、保護するべき部分をいじってしまうリスクよりも、リファクタリングし損ねるリスクの方が高いと思うんだけど。
っていうか単純に面倒。

642 ：デフォルトの名無しさん：04/07/31 16:02

ミスの可能性を度外視していいなら(以下略)

643 ：デフォルトの名無しさん：04/07/31 16:07

>>642
で、じゃあサーブレットとかPOJOをリファクタリングしたときに、どんな弊害があるの？

644 ：デフォルトの名無しさん：04/07/31 16:07

>>641
> じゃあ、GUIじゃなければ、いいんじゃないの？
自動処理の対象となる可能性のある全てのコードが対象なので、
GUIじゃなければ良いという話ではない。

> それに、保護するべき部分をいじってしまうリスクよりも、リファクタリングし損ねるリスクの方が高いと思うんだけど。
JBuilder にリファクタリング支援機能があるならそれを使えばよいだけでは？

645 ：デフォルトの名無しさん：04/07/31 16:08

あ、サーブレットならweb.xmlの・・・っていうツッコミどころがあるね。
POJOだけに絞ってみようか。

646 ：デフォルトの名無しさん：04/07/31 16:10

>>644
Eclipseと同じことができるならね。

で、自動処理ってなんなのさ。

647 ：デフォルトの名無しさん：04/07/31 16:15

>>646
> で、自動処理ってなんなのさ。
自動処理は自動処理だよ。

JBuilder の GUIエディタが自動生成するコードも、
javadoc コメントの生成支援で出力されるコメントも、
ユーザが JBuilder が出力するコードと決めウチして、
他のフレームワークへの移植を行うのも含めて
あらゆる自動処理全部。

648 ：デフォルトの名無しさん：04/07/31 16:17

> Eclipseと同じことができるならね。
Eclipse 以外のツールを使いこなす事ができない、単なる Eclipse 厨だな。

649 ：デフォルトの名無しさん：04/07/31 16:24

>>620
台風ってことはあんた、関西のほうか？
うち東京は晴れて天気がええぞ

650 ：デフォルトの名無しさん：04/07/31 16:25

>>648
え？
JBuilderってそんなかしこくなってんの？
ま、JBuilderは、使う候補にあがらないし。
NetBeansはEclipseほどのコーディング支援ないし。NetBeans4.0になったとしても。

NetBeansなりJBuilderなりで大枠吐き出して、Eclipseでコーディングというのは、なかなかいいと思うんだが。
自動処理ったって、リファクタリングで影響がでるような自動処理ってなんがあるのさ。

651 ：デフォルトの名無しさん：04/07/31 16:26

>>649
ことごとくイベント中止だ。

652 ：デフォルトの名無しさん：04/07/31 16:27

Eclipse使っている人と、日で丸使っていない人と一緒に開発しても
それほど支障はきたさないが。
むしろ日で丸とかで開発しているひとのソースコードをみるとコードフォーマッタで
整形したくなったり、警告によって出たいらないインポート宣言やいらない変数を
削除したくなってくるがw
ついでにコメント自動生成機能とかもついかしたくなってくるw

653 ：デフォルトの名無しさん：04/07/31 16:28

>>627
べつにAnt使えればいいじゃん。

654 ：デフォルトの名無しさん：04/07/31 16:29

>>632
>
> ところで、最近は Eclipse 使う人間は使わない(使えない、ではない)人間を
> 低脳よばわりしてストレス解消するのが流行ってるのか？

んなこたあないよ。むしろAntやmake使えない人間のほうが低脳なんじゃないの？

655 ：デフォルトの名無しさん：04/07/31 16:30

web.xmlなら、IDEが自動生成したものなんか、XDocletで捨てられるから、気にしない。
XDoclet使わなかったら、web.xmlコンフリクトしまくりで、数人じゃやってられない。

656 ：デフォルトの名無しさん：04/07/31 16:30

>>636
> >>634
> > で、例えば職場でJavaのコーディングにはJBuilder使いなさいというルールがあったとしたら、
> > メモ帳でソースコードいじるのもだめなの？
> 普通は不可。例えば JBuilder の GUIエディタが吐いたコードとか勝手に書き換えられたら困るでしょ。

だからそういうときにCVSのようなバージョン管理ツールを使うんだよ。

657 ：デフォルトの名無しさん：04/07/31 16:30

>>654
makeは使えなくていい、と思う漏れは低能ですか？

658 ：デフォルトの名無しさん：04/07/31 16:32

>>636
> >>634
> > で、例えば職場でJavaのコーディングにはJBuilder使いなさいというルールがあったとしたら、
> > メモ帳でソースコードいじるのもだめなの？
> 普通は不可。例えば JBuilder の GUIエディタが吐いたコードとか勝手に書き換えられたら困るでしょ。

とりあえずさ、テストケース書けよ。
いじったときにテストに失敗するようだったらそのソースコードは捨てるってやりかたで差

659 ：デフォルトの名無しさん：04/07/31 16:33

実はここでやりとりしてるやつって、数週間前にORMスレでやりとりしてたやつとメンバー変わらなかったりして。

660 ：デフォルトの名無しさん：04/07/31 16:35

>>656
普通は CVS にコミットする以前の問題だろ。

661 ：デフォルトの名無しさん：04/07/31 16:39

>>656
微妙に話がずれるね。
テストの話も、たとえばNetBeansの場合、GUIエディタで保護した部分を書き換えると、そのときはテスト通っても、あとでNetBeansで開いたときに元に戻されて、コンパイルエラーになる。

ただ、その部分はNetBeans以外のツールでさわらなければいいだけの話なんだけど。
それを触っちゃったらどうすんのっていう、すごく心配性な人がいる。

662 ：デフォルトの名無しさん：04/07/31 16:40

>>658
テストケースって……
ソースが Eclipse VisualEditor の自動出力フォーマットに合致してるか、なんてのもテストすんの？

663 ：デフォルトの名無しさん：04/07/31 16:51

で、結局リファクタリングで影響が出るような自動処理って、なんがあるの？

664 ：デフォルトの名無しさん：04/07/31 16:52

>>663
で、結局リファクタリングで影響が出ないって事は保証できるの？

665 ：デフォルトの名無しさん：04/07/31 16:56

職場で JBuilder 使え、と言われてるのに別のモン使おうとしてるってケースだから
普通は上から「影響が出ないことを保証しろ」って言われるだろうね。悪魔の証明だけど。

666 ：デフォルトの名無しさん：04/07/31 16:58

>>664
それこそテストケース

667 ：デフォルトの名無しさん：04/07/31 17:01

>>666
影響が出ないことを保証するってのは >>665 が言うとおり悪魔の証明だから、
そもそもテストケースなんぞ書けない。
例えテストケース書いても、** のような場合を想定していない、というのが無限に出てくる。

668 ：デフォルトの名無しさん：04/07/31 17:01

リファクタリングするかしないか、はツール使う使わないは関係ないし。
リファクタリングするんだとしたら、Eclipse使ってやるのが安全だし、と。
JBuilderにないリファクタリングの機能使うんならね。

保証がないからリファクタリングするな、という組織だとガクブルもの。

669 ：デフォルトの名無しさん：04/07/31 17:06

>>638 みたいにミスを度外視していいなら手動でリファクタリングしても全く問題ないな

ちなみに JBuilder にないリファクタリング機能って何？

670 ：デフォルトの名無しさん：04/07/31 17:07

JBuilderしらない。
最近のは使ったことないし。

671 ：デフォルトの名無しさん：04/07/31 17:09

>>598 の流れからいけば、ツール使う使わない以外は関係ないね。

リファクタリングしないって状況を勝手に想定して、
勝手に想像上の組織にガクブルしてんだろーけど。

672 ：デフォルトの名無しさん：04/07/31 17:10

>>667
>>666 はネタだろ。レス番がアレだし。

673 ：デフォルトの名無しさん：04/07/31 17:11

>>671
でも、>>664の言い草だと、そうじゃないとも言い切れないよ。
結局リファクタリングって、「ユニットテストで動作保証した上でのソースコードの効率化」でしょ。

674 ：デフォルトの名無しさん：04/07/31 17:14

>>673
>>664 のは >>665 の省略形だと考えれば、ツール使う使わない以外は関係ないと言い切れる。

675 ：デフォルトの名無しさん：04/07/31 17:23

から、結局、ツール使える組織であれば、便利ならEclipse使えばいいじゃん、と思うんだけど。

676 ：デフォルトの名無しさん：04/07/31 17:24

ところで、JBuilderってEclipseと同じだけのリファクタリングできるの？

677 ：デフォルトの名無しさん：04/07/31 17:28

>>675
> ツール使える組織であれば、
前提が間違ってるよ。>>634 で
> で、例えば職場でJavaのコーディングにはJBuilder使いなさいというルールがあったとしたら、メモ帳でソースコードいじるのもだめなの？
ってしっかり書いてあるから、Java のコーディングには JBuilder 以外使えない。

678 ：デフォルトの名無しさん：04/07/31 17:29

>>677
まぁ、>>634 とは別の話でってんなら使えば良いのでは？

679 ：デフォルトの名無しさん：04/07/31 17:31

>>677
ほとんどの組織では、そんなに厳しいとは思わないんだけど。

っていうか、前提が間違ってるとかじゃなくて、条件決めてEclipse使えばいいじゃん、と。
硬直した組織のことはほっといて。

680 ：デフォルトの名無しさん：04/07/31 17:33

> ほとんどの組織では、そんなに厳しいとは思わないんだけど。
自分の思い込みが正しいとは思わんように。

681 ：デフォルトの名無しさん：04/07/31 17:35

なんか>>679って、Eclipseが時代遅れになってもEclipse以外の開発環境は認めない、
とかゆーアレな人間に硬化しそうな悪寒……

682 ：デフォルトの名無しさん：04/07/31 17:35

>>680
JBuilderと決まったらメモ帳もだめ、っていう組織って多いの？

683 ：デフォルトの名無しさん：04/07/31 17:36

>>681
基本的には単なる Eclipse厨だからねぇ。

684 ：デフォルトの名無しさん：04/07/31 17:37

>>681
おれの意見は>>650にも書いた

> NetBeansなりJBuilderなりで大枠吐き出して、Eclipseでコーディングというのは、なかなかいいと思うんだが。

685 ：デフォルトの名無しさん：04/07/31 17:46

>>684
そりゃ現時点での話でしょ。例えば
・VisualEditorとかが良くなってきたらNetBeansもJBuilderも捨てる。
・そのままEclipseを使い続け、いつのまにかEclipse時代遅れに。
・若手から時代遅れと陰口を叩かれるようになり硬化。
ってのは十分考えられる。

現時点でも思考が硬直しがちに見えるし。

686 ：デフォルトの名無しさん：04/07/31 17:48

>>685
確かに。っつーか Eclipse 厨じゃないってだけで今現在も硬直してるしねぇ。
でもまぁ、普通の人は年とともに柔らかくなるから大丈夫。

687 ：デフォルトの名無しさん：04/07/31 17:48

>>685
なんか、妄想はげしいね。

自動化自動化うるさいやつの方が、硬直してたと思うぞ。
いなくなったみたいだけど。

688 ：デフォルトの名無しさん：04/07/31 17:49

>>686
> 普通の人は年とともに柔らかくなるから大丈夫。

・・・初めて聞く説だ。

689 ：デフォルトの名無しさん：04/07/31 17:53

>>687
ルールを守れってのは至極まっとうな話。

ルールを破るだけの根拠を提示できないのに素直に諦めない態度を
硬直と表現したんだが、なんか間違ってるか？

690 ：デフォルトの名無しさん：04/07/31 17:54

まぁ、彼もアレだけどね。
先に >>665 を言ってればそれで終わったのに。

691 ：デフォルトの名無しさん：04/07/31 17:57

>>689
ルールの意図を把握してれば、効率がよくなる部分ではルール破ってもいいと思ってるだけ。

結局、反論してもちゃんとした答え、ここでは帰ってきてないし。
Eclipseのリファクタリングが問題になる自動化ってなんなの？
すごく気になってるんだけど。

ルール至上主義は、それはそれで硬直化の代表だね。

692 ：デフォルトの名無しさん：04/07/31 17:57

> ルールを破るだけの根拠を提示できないのに素直に諦めない態度を
よーするに若いって事だよね。ｳﾗﾔﾏｽｨ

693 ：デフォルトの名無しさん：04/07/31 18:01

>>691
その場合、問題が無い事を証明する責任は >>691 にある。

> ルール至上主義は、それはそれで硬直化の代表だね。
ルールを破って、損害が出たときに
誰かにケツを拭いて貰わなければいけない事をよく理解出来てない人はそう考えるみたいね。
まぁ、若さの証明みたいなもんだけど。

694 ：デフォルトの名無しさん：04/07/31 18:06

>>693
で、リファクタリングとか、あと単純にコード書くときのtry囲んでくれることとか、そんな便利な機能が使いたくて、コーディングにEclipse使ったくらいで、損害でるの？

ルールの意図を把握して、その意図がくずれなければルール破っていいと思ってるんだけど。

695 ：デフォルトの名無しさん：04/07/31 18:07

> Eclipseのリファクタリングが問題になる
これを許せばリファクタリング以外にも使えるようにしろって話になる。
そのEclipseのリファクタリング以外の機能を使って問題にならない保証は無い。

とか、いくらでも言い様はあるからねぇ。

696 ：デフォルトの名無しさん：04/07/31 18:10

>>694
個別のルールの意図についてなら、一般論で議論しても無駄。

本当はルールを破るよか、ルールを変える事をまず第一に考えるべきなんだけどね。

697 ：デフォルトの名無しさん：04/07/31 18:10

>>695
リファクタリング以外でも、そんなに他に影響があるような機能って、あんまりない気がするけど

でも、サーブレットとかStrutsの開発でXDoclet使ってないときに、XDoclet使わせろ、とかは言うかも。
もちろんプロジェクトの初期段階での話だけど。

698 ：デフォルトの名無しさん：04/07/31 18:11

>>694
損害が出ない事を保証すべき責任を負うのは >>694。他の誰でもない。

699 ：デフォルトの名無しさん：04/07/31 18:12

>>696
というか、ほんとにJBuilderと決まったらメモ帳もだめ、というルールの組織なら、ほかにも変なルールがありそうだから、ルール変える前によその組織に行く。

700 ：デフォルトの名無しさん：04/07/31 18:13

>>699
その前提を持ちだしたのはオマエじゃないのか？

701 ：デフォルトの名無しさん：04/07/31 18:14

>>698
うーん、じゃ、ここでとやかく言われる筋合いもなさそうなんだけど。
記述したコードに持つ責任とおなじ範囲だと思うし。
ようするに、手作業にしろツールにしろ、バグを混入したら責任取れ、ってことでしょ。
全員Eclipse使えっていうわけじゃないし。

702 ：デフォルトの名無しさん：04/07/31 18:17

>>701
バグ混入だけじゃないんだけどね。

例えば Tiger 用のコードに変換して失敗する可能性、
失敗しないけど変換コードを書くのにより労力がかかる可能性、
数えだしたらキリがないぞ。

703 ：デフォルトの名無しさん：04/07/31 18:20

>>702
> 例えば Tiger 用のコードに変換して失敗する可能性、

どこにそんな可能性が・・・・

> 失敗しないけど変換コードを書くのにより労力がかかる可能性

変換コードなんか書く必要ないし。

そりゃ妄想を数えたらキリもなかろう。
できない理由をあげたらキリがない。

704 ：デフォルトの名無しさん：04/07/31 18:22

> できない理由をあげたらキリがない。
だから悪魔の証明だって言ったじゃん。

705 ：デフォルトの名無しさん：04/07/31 18:24

> 変換コードなんか書く必要ないし。
コードの再利用は全く考えない？
それに、全く無いというのを保証する責任はやっぱり>>703にある。

706 ：デフォルトの名無しさん：04/07/31 18:24

>>704
でも、あまりにも見当違いな可能性あげてるんだけど。

707 ：デフォルトの名無しさん：04/07/31 18:26

見当違いでもなんでも、可能性がゼロだということを保証する責任があるのは>>706.

708 ：デフォルトの名無しさん：04/07/31 18:26

>>705
>> 変換コードなんか書く必要ないし。
> コードの再利用は全く考えない？

コードの再利用と変換コードと、なんの関係が？
部分的にEclipse使ってコーディングするのに、再利用性考えるも考えないも、関係ないと思うんだけど。

709 ：デフォルトの名無しさん：04/07/31 18:27

>>707
うん、だから、>>701

710 ：デフォルトの名無しさん：04/07/31 18:28

>>707
っていうか、技術わからん管理職ならまだしも、Javaスレで>>702みたいな可能性がでてくるのが・・・

711 ：デフォルトの名無しさん：04/07/31 18:33

ツールにミスがある可能性がゼロだと保証する必要もないと思われ。
そんな保証が必要なら、どんなツールも使えない。

ツールで弊害があったときに、その対策ができるかどうか、弊害のコントロールができるかどうかが重要だと思われ。
で、Eclipseで部分的にコードを書き換えることの場合、弊害があったとしてもコントロールはできると判断。

712 ：デフォルトの名無しさん：04/07/31 18:47

ツールの善し悪し→水掛け論になるから個々人の好み
Eclipseを知らないで秀丸に走る上司→逝ってよし
チーム開発でのリファクタリング厨→逝ってよし

馴染んだツールでチームメンバと協調する人→GJ

713 ：デフォルトの名無しさん：04/07/31 18:54

関係ないが、Javaはクラス名とファイル名がリンクしてて、クラス名が変わるリファクタリングやるとCVSがいやなことになるので、クラス名のリファクタリングがやりにくい。
そうならないように考えて付けるべきだとは思うけども。

714 ：デフォルトの名無しさん：04/07/31 18:55

> 部分的にEclipse使ってコーディングするのに、再利用性考えるも考えないも、関係ないと思うんだけど。
JBuilder デフォルトのプロジェクトで Eclipse の自動生成コードが
> > 例えば Tiger 用のコードに変換
する時に障害になる可能性がゼロだと言うならともかく、
可能性を考える事すらできないってのはマズいのでは？
特にルール無視して複数のツール使いたいって言うのなら。

しっかし、この人抽象的な話になると付いてこれなくなるね。
プログラマに向いてなさそう。

715 ：デフォルトの名無しさん：04/07/31 19:00

>>711
> ツールにミスがある可能性がゼロだと保証する必要もないと思われ。
ツールにミスがある可能性を云々してるのでなくて、
「違う」というだけですら障害になる可能性もあるって事。
例えば、Swingなプロジェクトで VisualEditor と JBuilder の混ぜて使ったらダメだけど、
この場合、ツールが悪いわけではない。

> で、Eclipseで部分的にコードを書き換えることの場合、弊害があったとしてもコントロールはできると判断。
まぁ、判断したなら自分で責任は取らないとね。

716 ：デフォルトの名無しさん：04/07/31 19:30

>>714
現状EclipseはTigerに対応してないし・・・
Tigerに対応したときにどうこういうなら、それはまた先の話で。

抽象的というか、あんたが見当違いの杞憂な話してるだけ。

717 ：デフォルトの名無しさん：04/07/31 19:53

抽象的な話に弱く、視野が狭く、態度が高慢。
プログラマとしてはかなーり硬直しとるね。

718 ：デフォルトの名無しさん：04/07/31 20:00

>>716
どこに Eclipse が Tiger に対応してる/してない、なんて書いてあるんですか？
Eclipse と Tiger という単語みて脊髄反射しただけ？

719 ：デフォルトの名無しさん：04/07/31 20:42

emacsのJava開発支援機能って何があるんですか？
なんか上の方のレスを見ていると、統合環境だという人が
いるようなんですが。
sshからeclipseのような機能が使えたらいいな、と思って
いたんで、ぜひぜひお願いします！

720 ：デフォルトの名無しさん：04/07/31 20:48

【Meadow】Java開発環境（・∀・）ｲｲ【JDEE】
http://pc5.2ch.net/test/read.cgi/tech/1017214967/

721 ：デフォルトの名無しさん：04/07/31 21:41

>>626
Lispって知ってる？

722 ：デフォルトの名無しさん：04/07/31 22:37

>>718
ようするに、屁理屈か。
じゃあ、EclipseがC#のコードを生成することがないようにも確認しないといけないね。

723 ：デフォルトの名無しさん：04/07/31 23:27

どうでもいいけど、JDKの話しろ。
ProcessBuilder 便利だな、っと。

724 ：デフォルトの名無しさん：04/08/01 00:00

もうあたらしい情報もないしねぇ。

メタデータとJavaDocタグの違いってなに？
@overrideとか、JavaDocタグでやっても同じじゃん、とか思ったりするんだけど。

725 ：デフォルトの名無しさん：04/08/01 00:36

> メタデータとJavaDocタグの違いってなに？
すぐに思いつくのは実行時に reflection api で情報が取れる/取れない。

726 ：デフォルトの名無しさん：04/08/01 01:23

実行時に情報をとるって、具体的にどんなときに使うんかな。
新しい言語仕様で、メタデータがよくわかってない。

727 ：デフォルトの名無しさん：04/08/01 01:35

開発ツールとかアプリサーバとかの
設定を簡単にしたり自動化したりするときのヒントに使える。

728 ：デフォルトの名無しさん：04/08/01 01:38

>>713
CVSの代わりにSubversionを使うと気軽にファイル名を変更できます。

Subversion スレッドその2
http://pc5.2ch.net/test/read.cgi/linux/1078609142/

729 ：デフォルトの名無しさん：04/08/01 02:14

>>728
Subversion素敵だね。
なにより80番443番でいけるところがいい。
NetBeansにもEclipseにも対応プラグインがあるみたいだし。
Javaでやるなら、CVSよりSubversionの方がよさそうだ。

雨がどしゃぶりになって台風キターと思ったら、すぐやんだ。

730 ：デフォルトの名無しさん：04/08/01 07:48

>>724
.NETのパクリです

731 ：デフォルトの名無しさん：04/08/01 23:55

>>681
なんだ？ viやemacs,antが時代遅れだとでもいいたいのかい？

732 ：デフォルトの名無しさん：04/08/01 23:56

>>731
antはもうすぐそうなる。

733 ：デフォルトの名無しさん：04/08/01 23:57

時代遅れ：vi(m), emacs
もうすぐ時代遅れ：java, ant

734 ：デフォルトの名無しさん：04/08/01 23:58

時代はMSBuild

735 ：デフォルトの名無しさん：04/08/01 23:59

でも、Javaの代わりになるものは出てきてないから。

736 ：デフォルトの名無しさん：04/08/02 00:06

>>735
COBOL

737 ：デフォルトの名無しさん：04/08/02 00:07

>>711
> ツールにミスがある可能性がゼロだと保証する必要もないと思われ。
> そんな保証が必要なら、どんなツールも使えない。

Eclipseはオープンソースだし、多くの人によってテストが行われているわけだし
そんじょこらのIDEよかは信頼性があるでしょ。

738 ：デフォルトの名無しさん：04/08/02 00:08

>>737
っていうのは通じないみたいよ。

739 ：デフォルトの名無しさん：04/08/02 00:09

>>732-733
Mavenがあればantは要らないとでも考えておるのか寝？

その考えはCが時代遅れになると言っているのとかわらんぞ。
CがなければOSやVMを動かすには話にならんだろう。

viは即座に設定ファイルを弄るときに重宝するぞ。
特に、ＯＳを初期の何も無い状態からインストールするときに役立つ。

740 ：デフォルトの名無しさん：04/08/02 00:10

>>738
じゃあ、通じないバカにはApacheの信頼性をいくら説明しても通じない訳か。

741 ：デフォルトの名無しさん：04/08/02 00:11

時代遅れ：>>739

742 ：デフォルトの名無しさん：04/08/02 00:11

>>739
> 特に、ＯＳを初期の何も無い状態からインストールするときに役立つ。

最近はCDさしてほっとけばウィンドウマネージャまで普通にインストールしてくれるが。

743 ：デフォルトの名無しさん：04/08/02 00:11

>>712
> ツールの善し悪し→水掛け論になるから個々人の好み
> Eclipseを知らないで秀丸に走る上司→逝ってよし
だから、Eclipseが重たいという理由でEclipseを使わなかった者、
IDEを使うとバカになるからなるべき使わないでAntを使いたいと思っていた者、
など様々な理由でEclipseを使わないものがいるんだって。

だが、それでもEclipseよりも重たいＩＤＥってのもあるがな。

744 ：デフォルトの名無しさん：04/08/02 00:11

>>740 実際通じないから、
Apache -> IBM HTTP server
Eclipse -> IBM Websphere Workbench
という商業上の置き換えがあるんだよ。

745 ：デフォルトの名無しさん：04/08/02 00:12

>>741
サーバ構築もできないバカが言いそうなことだな。

746 ：デフォルトの名無しさん：04/08/02 00:14

>>744
やっぱりな、オープンソースのほうが信用できる。
それにオープンソースのほうが無料で大量のテスタを集めることができる。
オープンソースの信頼性はばかにならない。

747 ：デフォルトの名無しさん：04/08/02 00:20

>>746
君は何の貢献もしてないけどね。ﾌﾟ

748 ：デフォルトの名無しさん：04/08/02 00:24

>>740
実際、5年前はそういう状況だった。
Apacheなんてメーカーの保証もないわけのわからんもん、使えるか、みたいな。

749 ：デフォルトの名無しさん：04/08/02 00:25

>>746
といえるオープンソースのプロダクトは、数えるほどしかない罠。

750 ：デフォルトの名無しさん：04/08/02 00:28

そんじょそこらにIDEなんてない

751 ：デフォルトの名無しさん：04/08/02 00:29

>744
×WebSphere Workbench
○WebSphere Studio

752 ：デフォルトの名無しさん：04/08/02 00:30

>744
× IBM HTTP server
○ IBM HTTP Server

753 ：デフォルトの名無しさん：04/08/02 00:32

>>751
×WebSphere Studio
○WebSphere Studio Workbench

754 ：デフォルトの名無しさん：04/08/02 00:33

×くりーむしちゅー
○くりぃむしちゅー

755 ：デフォルトの名無しさん：04/08/02 00:35

>>753
製品としては
WebSphere Studio Application Developer
と
WebSphere Studio Site Developer

756 ：デフォルトの名無しさん：04/08/02 00:44

>>755 話の流れとしては「オープンソースの看板じゃ相手にしてもらえないので
自社の看板付ける」だから、機能的にEclipseと差がないWorkbenchだろうね。
ISV向けにWorkbenchを使った有償サポートサービスってのがあるんだよ。

ところで、>>755にWSDDもいれてやってくれ。新バージョンでたばっかだし。

757 ：デフォルトの名無しさん：04/08/02 01:01

そろそろみんなスレの名前を思い出してくれまいか

758 ：デフォルトの名無しさん：04/08/02 01:15

生まれは葛飾、柴又。帝釈天で産湯を使い……

759 ：デフォルトの名無しさん：04/08/02 01:33

>>757
雑談スレと書いてあるように見える。

760 ：デフォルトの名無しさん：04/08/02 01:37

>>730
ちがうな。
その機能はドトネト以前からあった

761 ：デフォルトの名無しさん：04/08/02 01:54

>>760
何かと勘違いしていない？
というか、「その機能」ってなにを指してんの？
「ドトネト以前からあった」ものって何のこと？

762 ：デフォルトの名無しさん：04/08/02 02:19

JavaDocタグ？

763 ：デフォルトの名無しさん：04/08/02 02:26

>>11の新機能はすべて.NETのパクリだな。
もうちょっとプライドを持って仕事しなさい。＞惨社員

764 ：デフォルトの名無しさん：04/08/02 02:31

せめてパクられるような機能1つくらいは入れておけば良かったのにな。

765 ：デフォルトの名無しさん：04/08/02 02:33

>>763
ジェネリックは、.NETのパクリじゃないね。

766 ：デフォルトの名無しさん：04/08/02 02:34

パフォーマンスの改善が.NETのパクリっていうのも、なかなかチョンっぽくていいね。

767 ：デフォルトの名無しさん：04/08/02 07:23

>>765
そうだね。パクリじゃない。
パクってたら10倍ましな仕様になってたからな。

768 ：デフォルトの名無しさん：04/08/02 07:38

Genericは仕様が決まったのはC#2.0が出るずっと前だと思うが。

769 ：デフォルトの名無しさん：04/08/02 07:50

→「思う」←

770 ：デフォルトの名無しさん：04/08/02 07:55

別にどっちでもいいんじゃない。使えれば良し。

771 ：デフォルトの名無しさん：04/08/02 07:55

仕様をパクったわけじゃないでしょ。
C#2.0に刺激されただけで。やっと重い腰を上げたというか。

772 ：デフォルトの名無しさん：04/08/02 08:09

Java の方はある程度流れを追える。
どの段階で「仕様が決まった」とするかは知らんけど。

JSR のプロセスはこんなん。
http://www.jcp.org/en/jsr/detail?id=14
Stage　　　　　　　　　　　　 Start　　　　　　　　　　Finish
Proposed Final Draft　　　　27 Jul, 2004
Public Review　　　　　　　　 07 May, 2001　　　　　1 Aug, 2001
Community Draft Ballot　　02 Oct, 2000　　　　　09 Oct, 2000
Community Review　　　　　07 Sep, 2000　　　　　09 Oct, 2000
CAFE　　　　　　　　　　　　　18 May, 1999　　　　　05 Jul, 1999
JSR Approval　　　　　　　　1 May, 1999　　　　　　17 May, 1999

Java Generics の元となった pizza のペーパーが出たのが 1997。
http://pizzacompiler.sourceforge.net/doc/papers.html

773 ：デフォルトの名無しさん：04/08/02 08:53

どっちが先なんてどうでもいい話だ。
問題はJavaのGenericsが糞って事だ。

774 ：デフォルトの名無しさん：04/08/02 09:02

もともとの仕様が糞なんだから、
それを建て増ししようとしたって、高が知れている。
そもそもJavaを使うのをやめたほうがいいと思うよ。

775 ：デフォルトの名無しさん：04/08/02 09:43

>>774
スレ違い。死滅スレいってやれ。

776 ：デフォルトの名無しさん：04/08/02 11:17

別にネタもリリースも無いんだからいいんじゃね

777 ：デフォルトの名無しさん：04/08/02 11:42

JDK 5.0 Beta 3 Build 60
http://java.sun.com/j2se/1.5.0/snapshots/index.jsp

778 ：デフォルトの名無しさん：04/08/02 12:13

>>761
ドトネトもJavaも存在する前からあったったことよ

779 ：デフォルトの名無しさん：04/08/02 12:14

>>763
Javaの仕様を策定しているのはサンシャインではありません。
主にＩＢＭとかが関わっています

780 ：デフォルトの名無しさん：04/08/02 12:27

>>778
だから何が前からあった？

781 ：デフォルトの名無しさん：04/08/02 12:28

分からん奴だな。Javaと.NETじゃ歴史も質も量も桁違いなんだよ。
.NET の検索結果約 388,000,000 件中 1 - 10 件目 (0.25 秒)
Java の検索結果約 69,800,000 件中 1 - 10 件目 (0.17 秒)

782 ：デフォルトの名無しさん：04/08/02 12:30

>>778-781
死滅スレ行ってやれ。

783 ：デフォルトの名無しさん：04/08/02 12:33

>>771
違うだろ、JCPに加入している企業との議論の末に採用してもいいかを判断したんだろ。
しかし型安全性も保証されていない信頼性のDQNなC#のGenericsと一緒にするのはどうかと。
Javaの仕様策定は、M$とはちがって時期尚早なこともせず、
独善的になってまで向こう見ずなことをしないってことだよ。

784 ：デフォルトの名無しさん：04/08/02 12:34

>>783
死滅スレageてやったからそっちでやれ。

785 ：デフォルトの名無しさん：04/08/02 12:36

餌も無いのに誰が食いつくものか

786 ：デフォルトの名無しさん：04/08/02 12:36

>>783
> しかし型安全性も保証されていない信頼性のDQNなC#のGenerics

あんたよその板で突っ込まれて答えられなかった人か？

787 ：デフォルトの名無しさん：04/08/02 12:37

>>783
では、型の取り扱いについてC#とJavaの違い教えて。

788 ：デフォルトの名無しさん：04/08/02 12:53

そして静寂が訪れた

789 ：デフォルトの名無しさん：04/08/02 18:11

>>783
見事にこちらでも撃沈、沈黙だな。
平和なスレになって良かった。
Winで始まるスレなども荒らすなよ。

790 ：デフォルトの名無しさん：04/08/03 09:21

>>789
あんた、荒らさないでくれないか。荒らしの張本人さんよ。
邪魔だからあっちでやってくれないか。

791 ：デフォルトの名無しさん：04/08/06 03:31

文法が変わるようなバージョンアップっていつ以来なのでしょうか？

792 ：デフォルトの名無しさん：04/08/06 04:01

JDK1.1かな？

793 ：デフォルトの名無しさん：04/08/06 04:02

あぁ、でもassert追加されたからJ2SE1.4以来。

794 ：デフォルトの名無しさん：04/08/06 09:49

1.1 -> 1.2 のときも若干文法変わってるけどね。

795 ：デフォルトの名無しさん：04/08/06 19:25

美人だった漏れのJAVAたんがアバタだらけに…

796 ：デフォルトの名無しさん：04/08/06 19:30

Java改造は始まったばかりだ。
次の仕様変更はthrows撤廃とdelegate, propertyの追加だ。

797 ：デフォルトの名無しさん：04/08/06 19:49

propertyは、やるにしてもメタデータでセッターゲッター自動作成になるのではないかと。
文法拡張する必要はないと。
throwsも、検査例外と実行時例外を使い分ければいいだけで。

798 ：デフォルトの名無しさん：04/08/06 20:28

業務系組む側からいえば今の例外のおかげでだいぶ助かる
オートボクシングもちゃんと理解してないと怖いことになるかも、と危惧している

タイプセーフEnumはうまく考えたものだと思う

あと綺麗なプロパティ文法は欲しいね
内部で生成するだけでいいから

799 ：デフォルトの名無しさん：04/08/06 20:58

オートボクシングて、
IntegerとかFloatとかだけをコンパイラが特別扱いして勝手に生成するの？
不公平じゃないか

800 ：デフォルトの名無しさん：04/08/06 21:59

すでにStringだけ不公平

801 ：デフォルトの名無しさん：04/08/06 23:20

enum も不公平。
でも超便利。

802 ：デフォルトの名無しさん：04/08/08 03:51

多重継承とか include なんかもそのうちできるようになるんでしょうか？

803 ：デフォルトの名無しさん：04/08/08 04:16

>>802
マジレスするとjavaは名前空間をimportするし、
プリプロセッサも排除しているのでincludeの意味が無い。
あと、多重継承するくらいならAspectJを使え。

804 ：デフォルトの名無しさん：04/08/08 09:34

ついでだから delegate も搭載してくれ

805 ：デフォルトの名無しさん：04/08/08 10:08

>>802
C#に無い機能は取り入れられないよ。

806 ：デフォルトの名無しさん：04/08/08 12:38

何でテンプレートを早く導入しなかったのか？
今頃になって・・・
もっと早くしていれば、ＳＥなら全クラス数が今の３分の２くらいに
減らせて、スッキリと整理できたのに。
新ＡＰＩを追加する事だけに熱中して、基本部分をおろそかにするから
こうなるんだ。

807 ：デフォルトの名無しさん：04/08/08 12:42

多重継承を導入したら、ＪＡＶＡの根底が崩れてしまうので
ダメ

808 ：デフォルトの名無しさん：04/08/08 14:26

っていうか、多重継承って必要？

何でテンプレートが早く導入されなかったかは、議論が長引いたからだね。

809 ：デフォルトの名無しさん：04/08/08 14:34

多分、多重継承する代わりに委譲かインターフェイスを使えという見解だと思うけど．．．

810 ：デフォルトの名無しさん：04/08/08 14:56

C++とのtemplateとはちょと違う。

811 ：デフォルトの名無しさん：04/08/08 15:07

C++のテンプレートは、新たにクラスを作るためのテンプレートだけど、Genericsはコレクションに型情報を与えるだけ。

812 ：デフォルトの名無しさん：04/08/08 15:10

Javaにも多重継承あるじゃん。実装の多重継承がないだけで。
多重継承入れたら、COBOLの代替としてのJavaという理念が崩れちゃうんじゃないか。
C++みたいに問題を全てプログラマ任せにするか、
問題を制御しようとしてEiffelみたいにやたらと複雑になるか、
どちらにしろ平均的な不勉強な業務系プログラマには使えない代物になる。

813 ：デフォルトの名無しさん：04/08/08 15:30

>>811
違う。ぜんぜん違う。

814 ：デフォルトの名無しさん：04/08/08 15:33

>>812
逆に、インタフェースの概念が思いつかなかったから、安易に多重継承を
導入しただけじゃないかとも思える。Ｃ＋＋は。

815 ：デフォルトの名無しさん：04/08/08 15:50

>>813
全然違う部分の指摘きぼんぬ。

816 ：デフォルトの名無しさん：04/08/08 15:51

>>812
> COBOLの代替としてのJavaという理念

エンタープライズ対応、という部分だけで、あまり言語仕様は関係ない予感。

817 ：デフォルトの名無しさん：04/08/08 15:54

>816
Sunのアーキテクトがどう思ってるかは別として、
COBOLの代替になるには言語仕様( + フレームワーク、ライブラリ)も気楽でないと駄目だろ
世の大半のプログラマの現状を見ると・・・

818 ：デフォルトの名無しさん：04/08/08 15:57

>>817
それは別にCOBOLの代替という理念には関係ない予感。
EoDなんて、最近言い出したわけだし。

819 ：デフォルトの名無しさん：04/08/08 15:58

最近言い出された != 昔はなかった

820 ：デフォルトの名無しさん：04/08/08 16:05

>>815
813ではないが、C++ではコンパイル時にテンプレートのインスタンス化を行うため、
バイナリが異常に大きくなるという問題があり、それを解決しているという点が挙げられるかな。
模造品の方もこれ主張していたはず。

821 ：デフォルトの名無しさん：04/08/08 16:07

>>811
コレクションに型情報は、あくまで主な用途であって
外にも様々な応用ができる。

822 ：デフォルトの名無しさん：04/08/08 16:24

>>820
C++は内部的に新しいクラスを作るためのテンプレートだよね？
それに対して、Genericsの方は、クラスに型情報をもたせるようにしただけ、ということで、全然違うというほどじゃないと思うんだけど。

823 ：デフォルトの名無しさん：04/08/08 16:34

>>820
この解決方法はアボトックでちょっと嫌、
できれば、実行時にテンプレートを展開する方式が良かった。
おかげで、templateが入ってもなーもできん。
カレーライスから、カレールーを取り除いたみたいだ。

824 ：デフォルトの名無しさん：04/08/08 16:52

アボトック？
アボトック？
アボトック？
アボトック？

825 ：デフォルトの名無しさん：04/08/08 16:58

>実行時にテンプレートを展開
しかも無駄だし

826 ：デフォルトの名無しさん：04/08/08 17:28

>>823
templateは入ってないから。

827 ：デフォルトの名無しさん：04/08/08 17:32

>>820
> 813ではないが、C++ではコンパイル時にテンプレートのインスタンス化を行うため、
> バイナリが異常に大きくなるという問題があり、それを解決しているという点が挙げられるかな。

Javaではコンパイル時にテンプレートのインスタンス化ができないんでしょ？
そんなしょぼい仕様でバイナリが大きくならないって主張されてもなあ…。
俺は>>822(=>>811)と同じ意見だよ。

828 ：デフォルトの名無しさん：04/08/08 17:33

付け加えると、JavaのGenericsはｲﾗﾈ。ただのシンタックスシュガーに成り下がってるから。

829 ：デフォルトの名無しさん：04/08/08 17:40

↑お前はインスタンスの参照を全てobject型の変数へ保持しとけ

830 ：デフォルトの名無しさん：04/08/08 17:53

>>829
あほか。んなことするわけないだろ。
お前プログラマーに向いてないよ。

831 ：デフォルトの名無しさん：04/08/08 18:20

コードをあいまいにしてるわけじゃないからなぁ。

832 ：デフォルトの名無しさん：04/08/08 18:21

ま、>>828はシンタックスシュガーっていいたいだけ、ということで。

833 ：デフォルトの名無しさん：04/08/08 18:29

>>827
Javaの場合はいざとなったら Reflection API かバイトコード生成で
実行時にいろんなものを解決する。

C++ は実行時の型情報が貧弱なのでコンパイル時に極力解決しようとする。

本当は両方使えるのがいーんだけどね。

834 ：デフォルトの名無しさん：04/08/08 23:04

>>827
だからテンプレートじゃないってば。
要は生成的プログラミングしたいんだろ？
C++使ってりゃいいじゃん。

JavaVM仕様を踏まえた上で生成的プログラミングを問題なく実装できる
方法があるんなら、俺もJavaに欲しいけども。

835 ：デフォルトの名無しさん：04/08/09 08:18

>>834
> だからテンプレートじゃないってば。
じゃあJavaのGenericsは何をするものだとあなたは思ってるの？

836 ：デフォルトの名無しさん：04/08/09 11:00

稚拙かつ大雑把かつ安易なテンプレートのコンパイル時インスタンス化を
reflect+アルファという基本設計で見事に解決してるGenericsは、
templateの理想進化形と言えるであろう。

837 ：デフォルトの名無しさん：04/08/09 11:19

>>836
配列が扱えないところが理想的ですね。

838 ：デフォルトの名無しさん：04/08/09 11:40

「templateじゃないgenericsだ」って言ってる時点で間違ってる。
C++のtemplateでさえ不満があるのに、そのサブセットなんて使ってられないよ。

839 ：デフォルトの名無しさん：04/08/09 11:56

>>838
具体性のない批判はゴミに等しい。
具体性のない批判を繰り返すやつはカスに等しい。

840 ：デフォルトの名無しさん：04/08/09 11:57

>配列が扱えないところが理想的ですね。
コレクションは無視と・・・

841 ：デフォルトの名無しさん：04/08/09 14:35

とどのつまりは、Javaのgenericsは型チェック以外できないって事
付いててもあんまし意味はなさそうというのが結論ってことで。

842 ：デフォルトの名無しさん：04/08/09 14:45

型強化という方向性が強いのでつかいかたがＣ＋＋とは全く別物かと

843 ：デフォルトの名無しさん：04/08/09 20:21

>>840
配列は使えないからコレクションで、というのも理想的ですね。

844 ：デフォルトの名無しさん：04/08/09 20:23

型チェックに意義を感じない人には、意味はないだろう。
型チェックに意義を感じる人には、大きな意味がある。

型チェックに意義があるかないかというのは、それぞれの環境によるが。

845 ：デフォルトの名無しさん：04/08/09 20:39

俺は意義があると思うね。
文句があるなら使わないか、自分の思うとおりに修正すればいい。
当分勢いが衰えそうにないJavaを使う必要は、何かと出てくるんだからね。

846 ：デフォルトの名無しさん：04/08/09 21:30

型チェックに意義があるかどうかは分野や規模で変わるから議論してもしかたないとして
型チェックに意義があるという人がいて、その人にとってGenericsが有効なのであれば、Genericsには意味がある。

っていうか、TypedEnumやConcurrencyではそういう意見がでないのに、なぜGenericsだけ
「自分は使わないから、意味がない」
という意見がでるのか不思議。

847 ：デフォルトの名無しさん：04/08/09 21:54

>>846
> っていうか、TypedEnumやConcurrencyではそういう意見がでないのに、なぜGenericsだけ
> 「自分は使わないから、意味がない」
> という意見がでるのか不思議。
C++のtemplateを卑下してGenericsが最高！って、宗教の信者みたいなことするからでしょ。
Java厨はすぐ何かを比較対象に持ってきて叩きたがるから。
Javaは良い物なのに何故使ってる人はバカが多いんでしょうか。

848 ：デフォルトの名無しさん：04/08/09 22:01

漏れは今のGenericsでさえ機能が多すぎると思っている

849 ：デフォルトの名無しさん：04/08/09 22:25

>>848
ところで Generics から、どの機能を削るの？

850 ：デフォルトの名無しさん：04/08/09 22:26

全部

851 ：デフォルトの名無しさん：04/08/09 22:30

コレクションへの型指定意外すべて削ってもよかったんじゃね？
Javaの方向性からいけば

852 ：デフォルトの名無しさん：04/08/09 22:42

他に何があるの？

853 ：デフォルトの名無しさん：04/08/09 22:46

Genericsの機能

１．コレクションへの型指定
２．↓続けて書いてください

854 ：デフォルトの名無しさん：04/08/10 00:27

コレクションに限らず、型のパラメータ化。
Java5のAPIを見れば、いろんなとこで使われてるのがわかるよ。

あと、ワイルドカード、上限境界、下限境界あたりを見れば、ハハーンてなるはず。

855 ：デフォルトの名無しさん：04/08/10 01:58

でもそのあたりが激しく使う人の技量に左右される部分だからな
コレクションの型付けだけならまだましだが
現場で監督する方も大変だよ
ＡさんのコードがＢさんによめないとかね

856 ：846：04/08/10 07:14

>>847
納得しますた。
VMを変えないために妥協してる部分もあるのに「理想的」と言ってしまうヤツもいるわけだし。

857 ：デフォルトの名無しさん：04/08/10 16:10

>>854
型のパラメータ化が出来んと、コレクションの型指定も出来んと思うが。
それともコレクションだけ特別扱いしろって事？

858 ：デフォルトの名無しさん：04/08/10 21:43

>>857
確かにコレクションはわかりやすい例だけども、
パラメータ化の恩恵を受けてるのはコレクションクラス群だけではないってこと。
Class<T>とか、ThreadLocal<T>とか。
Enum<T>なんか見てると、GenericsがTypedEnumの実装を助けてることもわかる。

859 ：デフォルトの名無しさん：04/08/10 21:45

new T() ができないこと以外は、特に不満はないのかな？

860 ：デフォルトの名無しさん：04/08/10 21:47

>>855
これは確かに頭痛いとこ。
でもtemplateに比べれば遙かにましだと思う。

861 ：デフォルトの名無しさん：04/08/10 22:23

new T()がやりたけりゃC++使え。

862 ：デフォルトの名無しさん：04/08/11 18:25

>>859
new T() 使うケースって少ないし
いざとなったら Factory 使えば良いだけのような気もするが。

863 ：デフォルトの名無しさん：04/08/11 19:17

>>855
オペレータオーバーロードとかテンプレートとかtypedefとか使うと、えらいことになるね。

864 ：デフォルトの名無しさん：04/08/11 19:48

マクロの無いJavaでtypedefだけ使えても、あんまし嬉しくないよーな。

865 ：デフォルトの名無しさん：04/08/12 00:15

typedefは、うれしくない。
人のソースが全然わからん。文化が違うと。

866 ：デフォルトの名無しさん：04/08/13 03:52

new T()にこだわるやつって、なんでTigerでnew T()が出来ないかわかってないんだろうなぁ

867 ：デフォルトの名無しさん：04/08/13 04:33

>>866
なんで new T() 出来ないの？

868 ：デフォルトの名無しさん：04/08/13 08:28

バイトコードに落ちた時点で、Generics の型情報が失われるから。

869 ：デフォルトの名無しさん：04/08/13 10:25

>>868
完全に失われるわけじゃないんだけどね。

void method(List<String> strlist) はソースが無いと
void method(List strlist) と同等という事になって
method(new ArrayList<Integer>()); とかされてもコンパイルエラーが吐けなくなる。

870 ：：04/08/13 13:21

いつ正式にリリースされるの？

871 ：デフォルトの名無しさん：04/08/13 14:17

俺が知ってる最新の発表では今年の夏。
Sun の連中がいつまでを夏と考えてるのかは知らんし、遅れる可能性もある。

早くリリースして欲しいなら最新ベータ版を落としてバグ報告しまくるとかすれば？

872 ：デフォルトの名無しさん：04/08/13 16:00

>>871
冬になるまでは夏。

873 ：デフォルトの名無しさん：04/08/13 23:21

>>869
C++でもC#でもできるのにね！
……と叩こうと思えば叩けるが、まぁそういうものだと割り切って使うべきだな。

ところで、リフレクションを使ってもTにアクセスすることはできないのかな？

874 ：デフォルトの名無しさん：04/08/14 00:24

>>873
new ArrayList<Object>().getClass()==new ArrayList<String>().getClass()
がtrueなんで無理。

875 ：デフォルトの名無しさん：04/08/14 01:24

>>873
場合によっては java.lang.reflect.Type のサブインターフェース経由で取ったりできる。

876 ：デフォルトの名無しさん：04/08/15 01:38

>>873
Tはそのクラスを使う側が決める物だから、使われる側から
具体的なTの情報が得られるとは思えんが。

877 ：デフォルトの名無しさん：04/08/15 02:53

>>875
どうやるの？
というか、「場合によっては」ってどういう場合？

878 ：デフォルトの名無しさん：04/08/16 01:34

Test<T extends Hoge>
のHogeならreflectionでとれるが、具体的なTの情報は得られんだろ。
メソッドに渡された引数の情報がjava.lang.reflect.Methodからは得られないのと同じで。

879 ：デフォルトの名無しさん：04/08/16 12:40

method(Test<Hoge> testhoge) なら Hoge まで取れるよ。
インスタンスの情報じゃないけど。

880 ：デフォルトの名無しさん：04/08/21 17:04

ところで、拡張forだけはどうしても背中がむずむずする。
1.6馬はSmallTalk風味にしてくれ

List a;
...
a.for(Object o) { .... }

881 ：デフォルトの名無しさん：04/08/21 17:51

文法の拡張が多すぎて難しそうだな

882 ：デフォルトの名無しさん：04/08/21 17:51

おとなしくforeachというキーワード増やしてくれればよかったのに。
予約語増やしたくなかったのんかな

883 ：デフォルトの名無しさん：04/08/21 20:31

for を foreach にしただけで
　foreach (Object o : iterator)
とかするだけだったらイラネ

884 ：デフォルトの名無しさん：04/08/21 22:52

まあ、 1.4 でも、

---
HashMap h = new HashMap();

・・・
h.put( key, value );
・・・

Itrator keys = h.keySet().iterator();

// foreach( keys %h ) {
while( keys.hasNext() ) {
　...
　// ele = $h{$_};
　Object ele = keys.next();
　...
}
---

みたいなコメントの入れ方してたからな。

885 ：デフォルトの名無しさん：04/08/21 23:24

それはアホくさいな。

886 ：デフォルトの名無しさん：04/08/22 01:08

>>884
>Itrator keys = h.keySet().iterator();
>
>// foreach( keys %h ) {
>while( keys.hasNext() ) {

iterator()とwhileの間が空くのって嫌じゃない？↓でどうよ。

for( Itrator keys = h.keySet().iterator();
　　　keys.hasNext();) { // foreach( keys %h )

887 ：デフォルトの名無しさん：04/08/22 01:30

>>886
中途半端に CとPerl を知ってると、いっそ、

// $_
public Object def_val;

// foreach( keys %a )
#define foreach(a) for( Itrator keys = a.keySet().iterator();　keys.hasNext(); def_val = keys.next() )

とかやりたくなる。
(いやこれはまずいか、つうか、このソースどこに置けばいいのよ。)

888 ：デフォルトの名無しさん：04/08/22 02:47

>>886-887
っつか、enhanced for loop で何が不足なのよ？
とか言いつつ 888 をゲットしてみるテスト。

889 ：デフォルトの名無しさん：04/08/22 02:54

まあ、機能的な問題ではなくて、
従来の for の文法からいうと、異質すぎるってことじゃないの。
なんでもまぜりゃいいなら while 文だけで事足りるはず。

while( int i = 0; i < 10 ; ++i ) {
　...
}

でも別に問題ないはずだけど、違和感ありありでしょ。

890 ：デフォルトの名無しさん：04/08/22 03:05

>>889
新しい言語作るならともかく、単に予約語の後付けを嫌っただけでしょ。

enhanced for loop が嫌なら foreach 使えるようにしたプリプロセッサでも使えば良いだけでは？

891 ：デフォルトの名無しさん：04/08/22 10:18

Perlのforeachってforの完全な同義語だから、

foreach ($i = 0; $i < $n; $i++) { ... }
も
for (@a) { ... }
も可能だったなぁ。後者はともかく前者はかなり嫌な感じだ。

892 ：デフォルトの名無しさん：04/08/22 17:16

foreachって、英語に直すとfor eachのことだから、
forでも問題ないと思うけどね。

893 ：デフォルトの名無しさん：04/08/22 17:23

>>891
嫌なら使わなければいいだけ。
perl の嫌な構文は (人によって違うだろうけど) いっぱいあると思うが。

894 ：デフォルトの名無しさん：04/08/22 17:38

まあ、Perl の思想は、書く人の数だけ書き方がある、って発想だから。
やっぱ、そういう点では Perl と比べると、Java　は「お行儀のいい」
言語なのかな（にしようとしてるのかな）。

895 ：デフォルトの名無しさん：04/08/22 18:04

書き方がたくさんあるとメンテが大変だからねえ

896 ：デフォルトの名無しさん：04/08/22 23:02

>>893
> >>891
> 嫌なら使わなければいいだけ。

その安直な考え方が命取りになるのだが。
typedef, 演算子オーバローディングの二の舞のようにな

897 ：デフォルトの名無しさん：04/08/22 23:12

でも、メンテが必要なコードと、使い捨てにするコードというのは
ある程度分ける必要があるのは確かなような気がする。

それを Java でやるのか、
使い捨てにするようなコードは Java で書かずに、
スクリプト言語を組み合わせるようにすべきなのか。

898 ：デフォルトの名無しさん：04/08/22 23:41

>>896
> その安直な考え方が命取りになるのだが。

はぁ ?
perl は >>895 のデメリットを承知の上で、たくさん書き方があった方が書き易いという選択してるだけですが何か ?

まずは、typedef がどう命取りになったのか書いてみてくれ。

899 ：デフォルトの名無しさん：04/08/22 23:47

結局モジュールの再利用が成功しているのは、JavaよりPerl(CPAN)の方なんだよね。
Java：メンテが楽
Perl：再利用し易い

900 ：デフォルトの名無しさん：04/08/22 23:56

>>899
んなぁ～こたあねぇ
Javaのほうがライブラリの整備しやすいし、
Perlは整備されたモノを使わないと正直やってられないという意味合いが強いかと

業務系ならメンテ性大事だし、そうでなくとも場合によってはリファクタリングするっしょ
書きやすいかどうかってのは使い切りが第一として考えるからだろうからね

どっちにしろ言語は大概目的が様々なんで同じ土俵で語れることは少ないがな

901 ：デフォルトの名無しさん：04/08/23 00:12

>>899
CPANで「再利用」されてるもののメジャーなものは、Javaなら標準。

902 ：デフォルトの名無しさん：04/08/23 00:13

>>898
typedefって、宗派が違う人のコードってどんな型かわからないんだけど。

903 ：デフォルトの名無しさん：04/08/23 00:29

>>901
何故メジャーなものだけに限定するのかが分からん。
自分が有利になるように話を展開するのははっきり言って好かんな。

>>900
Javaが全てにおいて他の言語より優れていると本当に感じていますか？
パイプでつなぐこと想定したテキストフィルター書くのにJavaなんて使わんよ。
ちょっと話がずれたが、何でもかんでも「Java最高！Java最高！」って言うのはどうかな。
Algol系しかできない人にとっては最高なんだろうけどね。

904 ：デフォルトの名無しさん：04/08/23 00:34

>>903
> 何故メジャーなものだけに限定するのかが分からん。

さすがに、メジャーじゃないものは標準じゃないものが多いからな。
ってか、なんかひがんでるかひねくれてるようにしか見えんな。
なんか嫌な思い出でもあるのか？

> パイプでつなぐこと想定したテキストフィルター書くのにJavaなんて使わんよ。

どこから「パイプでつなぐこと想定したテキストフィルター」の話が湧いて出たんだか。
自分が有利になるように話を展開するのははっきり言って好かんな。

905 ：デフォルトの名無しさん：04/08/23 00:37

Tigerに関係ない話するなら他所行ってくれ。

906 ：デフォルトの名無しさん：04/08/23 00:51

じゃぁ、delegate ｷﾎﾞﾝﾇ

ところで MS の J# って delegate 使えんの？
delegate 使えないと Windows.Forms.* 使えないよね？

907 ：デフォルトの名無しさん：04/08/23 01:06

>>906
今更 Tiger に更なる心機能を追加するわけが無いし、
2ch でｷﾎﾞﾝﾇしたところで Sun に届くとは思えん。

J# については以下のスレにでも行って聞いてくれ。
http://pc5.2ch.net/test/read.cgi/tech/1034043673/l50

908 ：デフォルトの名無しさん：04/08/23 01:06

s/心機能/新機能/

909 ：デフォルトの名無しさん：04/08/23 01:17

いや、なんつうか、「心機能」って、
「僕らが心から望んでる機能」とか、
「Sunと僕らの心が通じ合って追加された機能」とか、
そんな意味かとオモタ。

910 ：デフォルトの名無しさん：04/08/23 01:20

単なる誤変換っす。まさか「さらなるしんきのう」が「更なる心機能」に
変換されるとは思わなかったので読み直さずにそのまま書き込んじゃった。

911 ：デフォルトの名無しさん：04/08/23 02:50

つまり、ラドクリフには更なる心機能が必要なわけだな。

912 ：デフォルトの名無しさん：04/08/23 02:52

心筋梗塞になりそうですね。

913 ：デフォルトの名無しさん：04/08/23 08:19

>>906
使えるみたい。当初MSはJavaを便利にしようとしてたみたいですね。嗚呼。
http://www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/jpdndevqa/htm/msdn_nielsen_qa.asp

914 ：デフォルトの名無しさん：04/08/23 13:56

>>899
> 結局モジュールの再利用が成功しているのは、JavaよりPerl(CPAN)の方なんだよね。
CPANのJava版ならすでにあるぞ。

JJAR　という奴がな。

それと、このJJAR

Apache Mavenにも採用されている。
自動ダウンロード、自動アップデート機能がちゃんとついている。

915 ：デフォルトの名無しさん：04/08/23 13:57

>>903
アフォか。たとえJavaが最高であってもなくても
JavaがあればSQLを使う必要がないなんていう奴はいねえよタコ。

916 ：デフォルトの名無しさん：04/08/23 14:00

>>909
「心の機能」だよw

スティビーワンダーの曲　「心の愛」を思い出したぞw

917 ：デフォルトの名無しさん：04/08/23 16:46

>>903

>>900の書き込みを見るにJavaにはJavaの利点が、PerlにはPerlの利点が
というように見えるんだがどこをどう脳内変換したんだ？

918 ：デフォルトの名無しさん：04/08/23 16:55

先生！
Groovyはjavaに入りますか？

919 ：デフォルトの名無しさん：04/08/23 17:34

iMona(携帯Javaの2chブラウザ)のソース見たらPerl scriptで
#ifdefプリプロやっててちょっとﾜﾛﾀ

920 ：デフォルトの名無しさん：04/08/23 18:07

SQLっていらねーんじゃねえの？
ただ使ってる奴多いだけで、超クソ言語だろ。

921 ：デフォルトの名無しさん：04/08/23 18:27

>>920
スレ違い。

922 ：デフォルトの名無しさん：04/08/24 02:21

>>918
JSRに入ってるからね。

923 ：デフォルトの名無しさん：04/08/24 09:51

>>920
> SQLっていらねーんじゃねえの？
> ただ使ってる奴多いだけで、超クソ言語だろ。

お前、ろくに仕事ができない学生だろ。
Javaの仕事やるんだったら大抵お世話になるもんだぞ。

924 ：デフォルトの名無しさん：04/08/30 17:26

まだタイガーはでないのか

925 ：デフォルトの名無しさん：04/08/30 19:23

スナップの更新が止まったから、そろそろRC出るんじゃないかなぁ。

926 ：デフォルトの名無しさん：04/08/30 19:37

正式リリースは来年中頃だったっけ？

927 ：デフォルトの名無しさん：04/08/30 19:56

まだ穴で修行してるんだよ。

928 ：デフォルトの名無しさん：04/08/30 21:02

>>924
ヘンシェルに変更しました。
余ったのは対戦車自走砲にでもします。

929 ：デフォルトの名無しさん：04/08/31 11:25

>>926
今年の夏といわれていたので
もうそろそろ出るだろ

930 ：デフォルトの名無しさん：04/08/31 20:49

冬までは夏。

931 ：デフォルトの名無しさん：04/08/31 21:21

北半球が冬なら南半球は夏

932 ：デフォルトの名無しさん：04/08/31 23:45

赤道直下、いつでもいつまでも夏。

933 ：デフォルトの名無しさん：04/09/01 14:22

リリースまだかよ！
俺様をいつまで待たせる気だ！

934 ：デフォルトの名無しさん：04/09/01 14:48

もーう、せっかちなんだから♥

935 ：デフォルトの名無しさん：04/09/01 14:58

Tyger! Tyger! burning bright ・・・

936 ：デフォルトの名無しさん：04/09/02 00:05

java.util.concurrentによって結城浩の
「Java言語によるデザインパターン入門　マルチスレッド編」の実装は
どのようにかわりうるのだろうか。

937 ：デフォルトの名無しさん：04/09/02 04:04

List<? extends T>
って便利すぎる・・・

938 ：デフォルトの名無しさん：04/09/02 13:21

J2SE 5.0 RC 出てまっせー

939 ：デフォルトの名無しさん：04/09/02 13:39

騙されないぞ

940 ：デフォルトの名無しさん：04/09/02 13:42

いやほんと

941 ：デフォルトの名無しさん：04/09/02 13:52

>>938,940

Thanks.

942 ：デフォルトの名無しさん：04/09/02 22:04

J2SE5.0RCｷﾀ━━━(ﾟ∀ﾟ)━━━!!!!!

943 ：ヲチしてるだけなんですが：04/09/03 11:10

正式版５．０っていつでるのでしょうか？
もうそろそろかなと思って、見守ってるのですが．．．

944 ：デフォルトの名無しさん：04/09/03 16:44

Genericsのおかげで、あまりに開発が楽になったので、
見切り採用をしてしまっているのです。
9月半ばから本番稼動が始まるのですが、私はどうなってしまうんでしょうか。

945 ：デフォルトの名無しさん：04/09/03 16:48

>>944
本番稼動直前に致命的な不具合が出て（しかも高負荷でないと再現しない）、
全責任背負わされてあぼーん。

946 ：デフォルトの名無しさん：04/09/03 17:37

>>944
J2SE5のバイナリって、1.4以前で動かせないの？

947 ：デフォルトの名無しさん：04/09/03 18:33

ぶっちゃけ１．４や１．２の実装当初の大量のバグをしってるとなかなかいきなり飛びつくのは無理だなぁ

948 ：デフォルトの名無しさん：04/09/03 19:14

>>944
JDK の x.x.0 台はβみたいなもんだろ。
今までの膨大なバグフィックスのリスト見てる？

949 ：デフォルトの名無しさん：04/09/03 19:35

>>944
一つ言っておきたいのはたとえプロジェクトが崩壊しようとも
バグの調査および報告は怠るなと言うことだ。

950 ：デフォルトの名無しさん：04/09/03 20:48

>>949
ﾏﾝﾄﾞｸｾ

951 ：デフォルトの名無しさん：04/09/03 21:21

どのVM使おうが、テストしないといけないことに変わりはない。

952 ：デフォルトの名無しさん：04/09/03 21:24

>>951
テストは当たり前だが、バグ満載版を使うような学習能力が
無い香具師は困る。目的が実績なら別だが。

953 ：デフォルトの名無しさん：04/09/03 23:59

>>943
リリース・キャンディデート
といったらもうすぐってことだろ。
本番直前ってことだぞ

954 ：デフォルトの名無しさん：04/09/04 01:19

リリース・カンディデート（リリース候補）なので
修正はするが、大きな機能変更はしないバージョンです。

955 ：デフォルトの名無しさん：04/09/04 01:59

正式版が出たらｷﾀｰでこのスレは埋めて、次スレは作らずにJavaスレに合流しよう。

もし次のバージョンを話すための次スレ作るなら、スレタイにバージョン番号を入れるのはやめよう。

【祝】 JDK 1.4 βリリース
http://pc5.2ch.net/test/read.cgi/tech/990949654/

番号入れると↑のスレみたいに途中で放置されちゃう。
継続して使えるように「次期バージョンのJavaについて」とかにしよう。
いい？

956 ：デフォルトの名無しさん：04/09/04 06:21

おい、おまえら
APIとコンパイラとVMの区別くらいできるようになれ。

1.5のコンパイラは
genericsとかが扱えるけど、出てくるバイトコードは一緒。
だから、昔のVMでも動く。

ただし、1.5で登場したAPIを使ってる場合はその分のクラスファイルが必要。

1.5のVMが読み込めるバイトコードは、昔となんら変わっていない。
だから、見た目上は何も変わらないし、違いは素人にはわからない。
でも、実はいろいろなところがチューニングされてんだよ。

わかったか、馬鹿ども

開発は1.5でやって、VMは古いの使えよアホが。

957 ：デフォルトの名無しさん：04/09/04 08:27

>>955
http://pc5.2ch.net/test/read.cgi/tech/1081698555/
でいいじゃん。

958 ：デフォルトの名無しさん：04/09/04 08:32

リリース・カンディデート= リリース候補

うん、最近「ローマ人の物語」を読んでいたお陰で、
意味がしっくりわかる。

959 ：デフォルトの名無しさん：04/09/04 09:27

>>956
ＶＭ古いとEnumが使えないのはなぁ・・・
アレこそが一番Javaにほしかったものだしな
定数をintで扱うという変なＣライクな低レベルなものがのこっていた

960 ：デフォルトの名無しさん：04/09/04 09:49

>>956
内部実装が変わっててNoSuchMethodErrorになるの嫌だし。

961 ：デフォルトの名無しさん：04/09/04 13:52

>>957
いいけどスレタイがなぁ。5.0の次は1.6ではないだろうし。
次にこういうスレ作るときはバージョン番号入れないほうがいいなと。

962 ：デフォルトの名無しさん：04/09/04 15:06

>>956
ちょっと違うぞ。

１　javacオプションの-sourceで1.5を指定したときだけ、
　 J2SE 5.0の文法が使える。

２　javacオプションの-targetで1.4を指定すると、1.4
　　互換のバイトコードを生成する。

３　1.4で作ったバイトコードは、ほぼJ2SE 5.0でも動く
　　（上位互換ね）

４　-target 1.5を指定するとJ2SE 5.0でないと動かない
　　形式のバイトコードが生成される

５　genericsは-target 1.5でないと動かない。

６　J2SE 5.0のデフォルト設定は -source 1.5 -target 1.5だ。

分かりやすく言うと、

genericsを使った段階でJ2SE 5.0でないと動かん。
正直、なんだかなー、と思う。何のためにイレイジャやらなんやら
導入して、パラメータ型をObjectに変換してんだろう。

963 ：デフォルトの名無しさん：04/09/04 22:03

>>961
それにしても、Mustangについてあーだこーだ言いたいなら、スレタイにMustangとか1.6とかSE6とか入るべきだ。

964 ：デフォルトの名無しさん：04/09/05 00:11

迷走の始まり？

965 ：デフォルトの名無しさん：04/09/05 00:14

>>964
いままで迷走してないとでも？

966 ：デフォルトの名無しさん：04/09/05 00:18

>>962
それはSunのjavacがそうであるだけで、Javaの仕様としてはGenerics使ったコードがJ2SE1.4で動くようにできるのでは？
少なくともタテマエでは。

967 ：デフォルトの名無しさん：04/09/05 00:39

>>962
javac -source 1.5 -target 1.4 で作ったバイトコードは1.4のVMでも動くぞ。

>５　genericsは-target 1.5でないと動かない。
で勘違いしていると思われ。

968 ：デフォルトの名無しさん：04/09/05 01:41

>>967
勘違いはおまいなわけで。

-source 1.5 付けた場合は -target 1.4 は使えない。
いつまで古いリリース使ってんだ。

969 ：デフォルトの名無しさん：04/09/05 02:02

ﾏﾀﾞｰ？

970 ：デフォルトの名無しさん：04/09/05 02:48

>>967
いっぺんサンプル作ってコンパイルしてみろ。
javac -source 1.5 -target 1.4 Sample.java

もう速攻でこういわれるぞ。
「javac: リリース 1.5 のソースにはリリース 1.5 のターゲットが必要です。」