[mustang/Java SE 6] 次世代Javaの動向 4 [dolphin]

[mustang/Java SE 6] ..

2:デフォルトの名無しさん
06/11/20 13:40:07
ふーん、WinFXがあるのにね

3:デフォルトの名無しさん
06/11/20 14:11:39
前スレの話題
複素数を扱う前に実数を扱うプリミティブ型がなくちゃ

4:デフォルトの名無しさん
06/11/20 16:54:57
>>3
無限精度ってこと？

5:デフォルトの名無しさん
06/11/20 17:53:26
>>3
BigDecimalでいいよ。
あれをプリミティブにしてもねえ

6:デフォルトの名無しさん
06/11/20 17:55:33
Complexはプリミティブにする必要性を感じない。

conjugate()やabs(),arg(),getReal(),getImaginary(),innerProduct(),

とかいうメソッドがあったとして、これらもいちいち演算子で表現
することになったらどうする気だ。

7:デフォルトの名無しさん
06/11/20 18:39:17
Stringみたいに
Complex z = "1+2i";
と宣言できるだけでいいな。

8:デフォルトの名無しさん
06/11/20 18:40:34
全くですｗｗ
数値演算に特化したサポートはスマンが我慢してもらえると助かります・・・
複素数なんて日常つかわねえっす

9:デフォルトの名無しさん
06/11/20 18:41:15
>>7
それくらいなら
Complex z = Complex.valueOf("1+2i");
でいいんじゃないの？

10:
06/11/21 00:16:58
mustangのjavaw.exeって60～70秒に一度くらい規則正しくCPU負荷がすごく高くなりませんか？ワーカースレッドとか負荷の高い計算がない場合でも必ず起こってるようなきがします。

11:デフォルトの名無しさん
06/11/21 00:30:08
>>10
つ　sun.rmi.dgc.server.gcInterval　、sun.rmi.dgc.client.gcInterval

12:デフォルトの名無しさん
06/11/21 00:38:32
>>11
ガベージコレクトしてるんですか。
しかしTigerでは気にならなかったレベルだったような気がします｡簡単なアウトラインエディタを作ってるんですが、文字入力や日本語変換とかが1分に一回規則正しく瞬間的に遅くなってしまいます｡以前は気にならなかったのに。

13:12
06/11/21 00:39:27
自分のパソコンがPenⅢの733MHZだから遅くて気になるのかな｡

14:デフォルトの名無しさん
06/11/21 03:05:40
>>7
じゃ、今早速作れ。
構文解析は負担がかかるが。
とりあえずはメソッドを演算子代わりにすることから
始めないことには

15:デフォルトの名無しさん
06/11/21 03:07:25
>>9
その程度の簡単なものであればいいが
\int\~\infty_{\infty}\frac{\sin x}[\cos \frac{dx}{dt}]
みたいなものだととんでもなく負担が増大する。

16:デフォルトの名無しさん
06/11/21 09:02:49
複素数は虚数単位がＩかＪかで殺し合いが起きるので却下すます

17:デフォルトの名無しさん
06/11/21 09:10:27
Vector v = {1, 2, 3};

Matrix A = {
　　　　{1, 2, 3},
　　　　{4, 5, 6},
　　　　{7, 8, 9},
　　};

18:デフォルトの名無しさん
06/11/21 12:35:50
>>16
うむ。それもそうだ。
複素数を却下するのではなく、String表記法
について慎重に検討するまでは却下する。

が正しい。＠

19:デフォルトの名無しさん
06/11/21 12:37:39
>>17
見たからにただの配列と変わらんな。

シンタックスシュガーとして
導入したとでもいうのかね。

だが、行列の演算子はどうする。
行列の積は*でいいのか？
それとも、行列の個々の要素同士の積こそが*であって
行列の積は*で表現すべきではないか？

ベクトルの内積演算子、外積演算子はどうする。

20:デフォルトの名無しさん
06/11/21 20:57:09
Java SE 6 っていつ出るの？
11月上旬っていう記事を見たんだが、まだだよねぇ？
URLﾘﾝｸ(journal.mycom.co.jp)

21:デフォルトの名無しさん
06/11/21 21:25:07
今、RC

22:デフォルトの名無しさん
06/11/21 21:34:22
>>20
おまえは>>1すら読めないのか

23:デフォルトの名無しさん
06/11/22 08:28:56
>>20
November と December を勘違いでもしたんじゃねーか？
と思わなくも無い。大地ﾀｿだし。

そこの記事ちゃんと読むと、記事の日付が 11/1 になってるのに
> Java SE 6のリリースまで1カ月強となった。
とか出てきて変だし。

24:デフォルトの名無しさん
06/11/22 18:06:26
いや、当初は11月初頭リリースって予定だったと思ったが・・・。

25:デフォルトの名無しさん
06/11/23 02:52:35
>>19
そんなあなたに Fortress

26:デフォルトの名無しさん
06/11/23 12:39:02
次のバージョンではGenericsを完全にしてほしい。

27:デフォルトの名無しさん
06/11/23 12:43:18
完全てどういうことだ

28:デフォルトの名無しさん
06/11/23 13:56:59
C++Template化とかほざいたら>>26をしばきたたこうぜ。

29:デフォルトの名無しさん
06/11/23 13:57:16
public class A<E> {
　　E[] e = new E[5];
}
ができるように。

30:デフォルトの名無しさん
06/11/23 16:07:03
>>29
erasure だけを使ってる限りは無理だろうね。

31:デフォルトの名無しさん
06/11/23 18:42:09
erasureによるGenericsは、
全ての型で使える１つのコードを生成するだけでよいという利点
があるんだけど。
キャッシュの当たり率やメモリ消費量的には有利なはず。

C#のGenericsを採用した時点で、JITコンパイラは一部のコードを
C++のテンプレートのように型毎に生成する必要が出てくるからなぁ。

32:デフォルトの名無しさん
06/11/24 15:35:44
>>29
そもそも、配列でそんなもんを使う価値が理解できない。
配列自体おかしな仕様なんだから。
List使え。

33:デフォルトの名無しさん
06/11/24 15:36:18
>>31
Java GenericsはC#のGenericsとは違うからな。

34:デフォルトの名無しさん
06/11/24 16:35:44
> 配列自体おかしな仕様なんだから。
どの辺が？

35:デフォルトの名無しさん
06/11/24 16:36:56
ということは、>>29は、利便性とデメリットを検討した上で
排除された記法っぽいな。
俺も>>29が出来てもそんなメリットとも感じないし。

36:デフォルトの名無しさん
06/11/24 20:31:36
>>34
まず一つあげてみようか。
配列型を引数にとるとその引数である
配列の要素にまでfinalを指定できないことがあげられるね。
簡単に言うと配列は型安全性が完全に保証されていないこと。
配列の配列を他の配列の配列の型に代入できたりとか。
あと、配列型は継承できないこととか。

37:デフォルトの名無しさん
06/11/24 20:49:21
>配列の要素にまでfinalを指定できないことがあげられるね。
コンパイル時、個々の要素毎でなく配列全体一括で不変にできるようにしようって話なら
adding_generics の時にも一旦出てたし、JSR 308 とかでもやろうとしてたりとかしてるね。
URLﾘﾝｸ(jcp.org)

> 簡単に言うと配列は型安全性が完全に保証されていないこと。
よくわからんけど、これは List も同じでは？

> あと、配列型は継承できないこととか。
配列を継承したいケースって、どんな時？
toString() 弄りたいとかはわからんでもないが、他の解決法あるし……

38:デフォルトの名無しさん
06/11/24 21:01:25
>>37
一番上に関しては List でもコンパイル時にはチェックできないし。
Collections.unmodifiableList() とか使えば実行時にはチェックされるけど。

39:デフォルトの名無しさん
06/11/24 21:05:59
>>37
36じゃないが、「配列は型安全性が完全に保証されていない」ってのは
下のコードは実行時例外が出るのにコンパイルが通るって話だろう。
ジェネリックな List だとコンパイルが通らない。

String[] ss = new String[] { "abc" };
Object[] os = ss;
os[0] = new Integer(123);

40:デフォルトの名無しさん
06/11/24 21:17:18
>>39
コンパイル時の型安全だけに限ってるのか。
実行時は List の方が緩くなるし、どっちもどっちだと思うけどね。

Collections.checkedList() もあるけど、
Class が必要になるから、必ずしも使えるとは限らんし。

41:デフォルトの名無しさん
06/11/24 23:20:57
>>38
それを配列にできないから配列は糞仕様だっていってるんだろ。
いちいりListに変換しないといけないからな

42:デフォルトの名無しさん
06/11/24 23:22:40
Developer Worksで配列はCovariantじゃないってのがあったな。

配列をGenericsで扱うと、思い通りにいかないとかってやつ。
今その話が発端になっているのかな？

たしかにあれはキモイ。だから配列は極力つかわないほうが
綺麗になるってことかな。配列とGenericsとの併用は避けるべきだともいえそうだね。

43:デフォルトの名無しさん
06/11/24 23:26:37
>>37
> > 簡単に言うと配列は型安全性が完全に保証されていないこと。
> よくわからんけど、これは List も同じでは？

そこでGenericsと、既に出たけれどもCollectionsクラスのアンモディファイアブルを
使う。配列だとListほど思い通りにいくわけでもないな。
配列はListよりパフォーマンスがよくてコード量が短いという
程度のメリットしかないな。

> > あと、配列型は継承できないこととか。
> 配列を継承したいケースって、どんな時？

そんなケースはまれだと思うが、

ある型Aを配列で扱いたいとき、
Aを継承したBも配列で扱いたい。
そんなとき、B[]はA[]を継承できるかっていうと
そうでも無いって奴だな。

そうなったらAArrayやBArrayというクラスを別途
作って対応するしかないって奴だ。

44:デフォルトの名無しさん
06/11/24 23:33:52
配列もプリミティブ型同様、
Javaの中で妥協して作られたモノだと見てもいいな。

しかしprintf(String a, Object...)は
実は正体がprintf(String a, Object[] b)というからな

これもいつしか

public <E> PrintStream printf(String a List<E> )

なメソッドがオーバーロードされるんだろうか

45:デフォルトの名無しさん
06/11/25 00:03:05
>>42
いや、generics は covariant じゃないから、型安全が保持されてるって書いてあったような。

> 配列とGenericsとの併用は避けるべきだともいえそうだね。
配列と Generics は相性も悪いしね。 >>29 みたいのができないし。

46:デフォルトの名無しさん
06/11/25 00:10:13
>>43
> そんなとき、B[]はA[]を継承できるかっていうと
それって、どーゆー時に必要になる？

47:デフォルトの名無しさん
06/11/25 00:35:27
例えばSortedSetを継承してTreeSetを作りたい、
みたいなときじゃないかな。

結局配列型を継承せず
配列型を集約するわけだが

48:デフォルトの名無しさん
06/11/25 00:42:00
>例えばSortedSetを継承してTreeSetを作りたい
Sorted配列を継承してTree配列作る？
配列に対して、そーゆー発想は無かったなぁ。

49:デフォルトの名無しさん
06/11/25 02:25:17
そして配列に失望するのであった。

配列は非オブジェクト指向である。

50:デフォルトの名無しさん
06/11/25 02:29:47
構文糖衣を許して、[]=っていうメソッドを定義できるようにするしかない。

51:デフォルトの名無しさん
06/11/25 03:09:59
>>48
普通はしない
ってか、Tree配列ってなんだよ

52:デフォルトの名無しさん
06/11/25 03:35:37
>>45
でも配列使うAPIも結構多いんだよね。
何しろGenericsができるまでは要素の型を指定できたの配列だけだし。

53:デフォルトの名無しさん
06/11/25 09:12:57
Number[] nums = new Double[2];
nums[0] = new Double(1.0); //OK
//nums[1] = new Integer(1000); //ArrayStoreException
Double[] dd = (Double[])nums;//OK

Number[] num2 = new Number[2];
num2[0] = new Double(1.0); //OK
num2[1] = new Integer(1000); //OK
num2[1] = new Double(0.01); //OK
Double[] ddd = (Double[])num2;//ClassCastException

54:デフォルトの名無しさん
06/11/25 09:47:30
>>39
それで「型安全が完全に保証されていない」ってんなら、極端な話すれば、

List<String> l = new ArrayList<String>();
Vector<String> v = (Vector<String>)l;
は、コンパイルが通るから、
「参照型の変数は型安全が完全に保証されていない」
とかいう変な話になっちゃうような気もする。

55:デフォルトの名無しさん
06/11/25 12:42:16
>>54
それはキャストしてるだけでしょ。
型安全ってのはキャストなしでコンパイルが通ったら
実行時にも型に関する例外が出ないことだよ。

56:デフォルトの名無しさん
06/11/25 13:12:16
>>54
それはキャストが型安全じゃない事を示しただけ。

そりゃ、キャストは型安全じゃないわな。

57:デフォルトの名無しさん
06/11/25 14:32:17
ArrayListのコードの一部だけど何か奇怪だね。

private transient E[] elementData;（92行）
this.elementData = (E[])new Object[initialCapacity];（113行）

58:デフォルトの名無しさん
06/11/25 15:12:10
そりゃ、erasureだからnew E[initialCapacity];はできんでしょ。

59:デフォルトの名無しさん
06/11/25 15:23:13
配列は変な仕様だが、
配列がないとCollectionFrameworkもつくれないわけか・・・

60:デフォルトの名無しさん
06/11/25 15:28:51
>>59
配列が covariant じゃなかったら 1.4 で Collection#toArray（Object[]）の
使い勝手が滅茶苦茶悪くなるし。極端に変な仕様だとも思わんが。

61:デフォルトの名無しさん
06/11/25 19:03:57
>>60
まあその辺はトレードオフだわな
配列がcovariantなおかげで便利な部分があるのも確かだし
一方で型安全では無いとか配列の要素への代入時にチェックが入って遅くなる(可能性がある)
とか、covariantなために発生する問題もある
型安全かつ利便性をそれなりに保つためには、Java Genericsが採用したワイルドカードの
ような機能がJVMレベルであれば良かったんだろうけど、今更言っても後の祭りだしね

62:デフォルトの名無しさん
06/11/25 21:01:45
>>59
っJNI

63:デフォルトの名無しさん
06/11/25 21:46:16
>59 つcons

64:デフォルトの名無しさん
06/11/25 23:09:16
ところで

covariantの意味はなんたるか

統計学用語で
varianseが分散
covarianseが共分散
ってのはわかるんだが

65:デフォルトの名無しさん
06/11/25 23:09:49
スペルミスだ

variance
covariance
の間違い

66:デフォルトの名無しさん
06/11/25 23:11:35
おっとよく見ると

URLﾘﾝｸ(www2.alc.co.jp)

# covariant
【形】《数学》共変｛きょうへん｝の
# covariant components
共変成分｛きょうへんせいぶん｝
# covariant derivative
《数学》共変微分｛きょうへんびぶん｝、共変導関数｛きょうへんどうかんすう｝
# covariant differential
共変微分｛きょうへんびぶん｝
# covariant differentiation
《数学》共変微分｛きょうへんびぶん｝
# covariant equation
共変方程式｛きょうへんほうていしき｝
# covariant functor
共変関手｛きょうへんかんしゅ｝
# covariant gage
共変｛きょうへん｝ゲージ

67:デフォルトの名無しさん
06/11/25 23:13:54
ベクトル解析は三次元までしかしらないので
covariantとかtensor(テンソル)とかいわれても
わからん。

n次元空間とかn次元超平面とかクォータニンとか全然ピンと来ない

68:デフォルトの名無しさん
06/11/26 00:58:36
>>64
プログラミング言語関係の用語のcovariance・contravariance
は、共変・反変と訳することが多い。varianceの訳語は
聞いたことが無いので、よくわからない

で、covarianceの意味だがここで言われてる文脈では
ある型AとBとパラメータ型Tについて、
A <: B => T<A> <: T<B> ( A <: B は AがBのサブタイプであるという意味)
が成立するとき、Tはcovariantであると言う。
で、Javaの配列に関して考えてみると
A <: B => A[] <: B[]
がJava言語仕様で決まっているからJavaの配列はcovariantなわけだ
一方、Java Genericsでは上記の命題が成立しないのでJava Genericsの
Generic型はcovriantでは無いというわけ

69:デフォルトの名無しさん
06/11/26 03:16:26
お前ら、何でJava使ってるんだ。
もういいから、違う言語使えよ。

70:64 じゃないが
06/11/26 03:19:04
>>68
なるほどーすげぇよく分かったよ。ｻﾝｸｽｺ

71:デフォルトの名無しさん
06/11/26 10:21:31
A <: B => T<A> <: T<B> ( A <: B は AがBのサブタイプであるという意味)
この行を読もうとして変態言語のパーサの気分がよくわかった。
等幅フォントにしたら読みやすくなった。

72:デフォルトの名無しさん
06/11/26 12:49:03
>>69
じゃ、オマエのおすすめの言語あげてみそ

73:デフォルトの名無しさん
06/11/26 13:08:53
>>69じゃないけど、MathematicaだとJ/Linkや.NET/Linkで
Javaや.NETと連携できるみたいだね。
面倒な計算はMathematicaのエンジンにやらせて、
結果だけJavaで表示って方法じゃダメか？
Mathematicaしか調べてないけど、他の製品にもこういうのあるんじゃない？

74:デフォルトの名無しさん
06/11/27 01:52:43
それが普通の人の発想だと思おうよ

75:デフォルトの名無しさん
06/11/27 02:20:17
>>73
ドトネトとの連携が>>69とどういう繋がりがあるんだかわからないが
数値計算のためにわざわざドトネトを使う価値ってものが
どういうものか説明しないことには意図が伝わらないな

76:デフォルトの名無しさん
06/11/27 04:31:53
>>75
いや、>>73の論旨を読めてないでしょう。
JavaOnlyで行わず数値演算は、Mathmatica(あれも一種の言語だよな)
何かに任せ連携を取るということもあるという話。であって
数値演算に、Java、.NET等の汎用言語を「使わない」選択肢について語ってるのが>>73

77:デフォルトの名無しさん
06/11/27 08:07:07
Mathmaticaってそんな一般的？
大学の端末には確かに入ってるけど・・

78:デフォルトの名無しさん
06/11/27 15:36:34
本気で数値計算やるなら大抵持ってる希ガス
つーか他の製品知らない

79:デフォルトの名無しさん
06/11/27 15:53:39
>>76
Mathematicaの話をするならドトネトの話は関係ない

80:デフォルトの名無しさん
06/11/27 15:53:57
>>78
MATLABのほうが断然使いやすいんだが

81:デフォルトの名無しさん
06/11/27 20:35:23
MATLAB,Mathematicaは、理系で大学生以上なら一般的に知ってると思う
他の言語とのインターフェースは知らなかったよ。

82:デフォルトの名無しさん
06/11/27 23:52:44
MATLABは大学でも
特定の研究室に関わらないと知らないと思うぞ。

あと、高いしな。

FortranやC/C++のほうが知名度が高いだろう。

83:デフォルトの名無しさん
06/11/29 20:30:40
昔、Javaにポインタを導入しろとか言ってたやつがいたなｗ

84:デフォルトの名無しさん
06/11/29 22:24:09
ぬるぽ

85:デフォルトの名無しさん
06/11/29 23:26:25
>>82
CやJavaを使える生徒が減ったという理由でMATLABが必修になりつつある情報科があるんだよなw
まず教授がCやJavaを使えないって話かもしれんがw

86:デフォルトの名無しさん
06/11/30 01:18:03
>>83
C#見て小躍りしたんだろうなぁ
>>84
うん。ガッ

87:デフォルトの名無しさん
06/11/30 01:43:40
大学生は生徒とは呼ばない。学生と呼ぶ。
生徒は中高生のことを指す。

88:デフォルトの名無しさん
06/11/30 20:26:03
++java

89:デフォルトの名無しさん
06/12/01 09:48:41
Java#

90:デフォルトの名無しさん
06/12/02 07:44:53
#java++

91:デフォルトの名無しさん
06/12/02 10:42:01
Java SE 6 まだ～？

92:デフォルトの名無しさん
06/12/02 13:37:01
#import <java.lang.System>

93:デフォルトの名無しさん
06/12/04 12:24:19
JDK7 build03
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(www.java.net)

Changelogの多さからして本格稼働した様子。

94:デフォルトの名無しさん
06/12/10 10:42:44
次世代Java == C#

95:デフォルトの名無しさん
06/12/10 14:05:39
流石に言語機能としてはまだC#のほうが上かな。
さすがDelphi作者が作っただけはある。
Java 7からはプロパティやクロージャも検討されるから
2009年には若干C#より柔軟になる。

96:デフォルトの名無しさん
06/12/10 15:43:40
そーいや、クロージャの話はいろいろ出てきたけどプロパティの話はあんましみないね。

97:デフォルトの名無しさん
06/12/10 19:22:49
リリースまだかよ。
12月も1/3過ぎちゃうぞ。

98:デフォルトの名無しさん
06/12/10 23:09:53
なんか、最近ようやく継続の存在意義を知った

99:デフォルトの名無しさん
06/12/11 20:13:17
リリースされたよ。JDK6。

100:デフォルトの名無しさん
06/12/11 20:33:55
ランゲージパックは無し？
てか5.0のupdate10をちらっとみたけどこっちのがマニアックに凄いな
selectが内部でepollで実装されてるってことはゲーム用途でもいけそう

101:デフォルトの名無しさん
06/12/11 21:36:15
>>100
ランゲージパックなんていままでもなかったと思うが。

102:デフォルトの名無しさん
06/12/11 21:43:47
そうだっけか。ドキュメントやらNBやらと違ってそのまま使えばいいのか。

103:デフォルトの名無しさん
06/12/11 21:50:39
静かなリリース

104:デフォルトの名無しさん
06/12/11 22:31:28
まだりりきゃんでしょ。

105:デフォルトの名無しさん
06/12/11 22:32:50
>>102
前から、JDKの日本語ダウンロードページなんかは前からあるけど、
ダウンロード方法なんかが訳されてるだけで中身は一緒だったな。

106:デフォルトの名無しさん
06/12/11 23:17:34
翻訳は URLﾘﾝｸ(jdk-api-ja.dev.java.net) でやってるよん。
早く日本語のAPIリファレンス欲しい人は手伝ってみれば良いかも？

107:デフォルトの名無しさん
06/12/12 09:59:49
静かなリリースsage

108:デフォルトの名無しさん
06/12/12 12:00:47
おおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおお！！

ついにリリースされたか！

気が付くのが遅かった！

早速ダウソ！

109:デフォルトの名無しさん
06/12/12 17:09:24
ダウンロードにNetBeans5.5バンドルのがあるけど、
日本語版NetBeans5.5って正式リリースされてたっけ？

110:デフォルトの名無しさん
06/12/12 18:04:31
>>109
JDK6にバンドルされているのは英語版。日本語版は12/14の予定。

いまDLできるJDK6のVMだけど、NetBeansの製品情報で見ると 1.6.0-b105と表示される。
これって本当に正式版なのかな？

111:109
06/12/12 18:26:18
>>110
thx
JDK5のときも1.5.0_0*-b0*みたいに表示されてたから、たぶん正式版だと思う。

112:デフォルトの名無しさん
06/12/12 18:39:36
build 番号 105 なのか(w

113:デフォルトの名無しさん
06/12/12 19:13:07
JDK6入れてJava2Dのデモプログラム動かしてみたけど、
起動時の画面の動きが怪しいね。

114:デフォルトの名無しさん
06/12/12 19:22:25
さいしょはみんな bはベータのbだと思うよな。

115:デフォルトの名無しさん
06/12/12 19:33:26
weeklyビルドを追っていたら混乱するはずがないです。

>>113
どう怪しいのか詳しく。

116:デフォルトの名無しさん
06/12/12 20:53:04
SwingSet2のスプラッシュスクリーンのウィンドウの形が、
影つきの非矩形でびっくりした。

着実にGUIも進歩しているなぁ

117:デフォルトの名無しさん
06/12/12 21:23:32
あら、RhinoはMapをプロパティ風に使えないのか？
これからはJavaアプリ間で使いまわすスクリプトも流行るだろうし研究しなきゃ

118:デフォルトの名無しさん
06/12/12 21:37:35
>>115
メインの画面が出る直前に、起動時のプログレスダイアログが左端に動く

119:１１８
06/12/12 21:38:30
×左端
○左上

120:デフォルトの名無しさん
06/12/12 21:55:54
パフォーマンスが改善したって聞いたけど、ほとんど感じない…
ペン３、1GHZじゃ恩恵なし？

121:デフォルトの名無しさん
06/12/13 00:30:37
VMの起動が早くなった
ような気がする…

122:デフォルトの名無しさん
06/12/13 01:05:22
nbの検索が糞遅くなった気が・・・5.0だからか？

123:デフォルトの名無しさん
06/12/13 01:30:32
結局、SystemTrayから開けるメニューはAWTのPopupだけか。

124:デフォルトの名無しさん
06/12/13 01:56:28
>>121
確かに5.0よりやや早いのを確認
VM起動前にスプラッシュ出せるようになったのも重いアンチウイルスソフト使ってる人にはうれしいかもね

125:デフォルトの名無しさん
06/12/13 08:54:49
jarファイルのアイコンが変わったね

126:デフォルトの名無しさん
06/12/13 09:08:58
>>117
java.util.Mapの要素をプロパティ風に参照したいってこと？
それなら少なくともそのままやるのは無理っぽい

js> importPackage(java.util)
js> var m = new HashMap()
js> m
{}
js> m.foo = "foo"
js: "<stdin>", line 5: Java class "java.util.HashMap" has no public instance fie
ld or method named "foo".
js: "<stdin>", line 5: org.mozilla.javascript.EvaluatorException: Java class "ja
va.util.HashMap" has no public instance field or method named "foo". (<stdin>#5)

Pnuts使うのがいいんじゃないかなあ

> import java.util.*
null
> m = new HashMap()
{}
> m.foo = "foo"
"foo"
> m.foo
"foo"

127:デフォルトの名無しさん
06/12/13 16:44:55
何このIronPythonのパクリ(嘲笑

128:デフォルトの名無しさん
06/12/13 16:48:02
何を指しているのだろう。

129:デフォルトの名無しさん
06/12/13 16:58:14
Borlandが作り
MSが真似をして
Javaが起源を主張する

130:デフォルトの名無しさん
06/12/13 23:13:03
古い歴史を持つ Rhino や Pnuts が、
どのようにすればごく最近(2003-2004)作成された IronPython を模倣出来るんだろう．．．

最近、歴史を学ばない半島人がオリジナルにパクリを主張することが多くて困る

131:デフォルトの名無しさん
06/12/14 01:13:19
PnutsなんてJavaのごく初期から数少ないJava製スクリプト言語だったよな。
しかも日本人作なんで驚いたもんだ。

132:デフォルトの名無しさん
06/12/15 04:27:57
Java SE 7.0 のスライド、らしい。
URLﾘﾝｸ(blogs.sun.com)

なんか BigDecimal で四則演算が使えてるっぽいサンプルとか、
JavaBeansのプロパティが -> で参照できてるっぽいサンプルとかがある。

Closure の構文みるに、8月の段階で提案されてた構文っぽいので
他の言語機能も構文変わったりするのかも。
それと個人的には Java SE 7.0 って機能てんこ盛りすぎに思えるので
いくつかの機能は次のバージョンに持ち越される可能性もあるんじゃないかと心配したり。
ざっとみただけでも、コンパイルエラーになりそうなサンプルが 2つほどあったり……

133:デフォルトの名無しさん
06/12/15 07:05:51
プロパティはいらん。機能そのものじゃなくて構文がダメ。
Genericsの略式インスタンスもnew()の方はキモ過ぎる。
インタフェースのデフォルト実装クラスがあるってことだろ。
friend class構文とかと同じキモさ。

134:デフォルトの名無しさん
06/12/15 07:15:41
要はC# 3.0のパクリなんだろ。(ｹﾞﾗ

135:デフォルトの名無しさん
06/12/15 07:46:34
>>133
> インタフェースのデフォルト実装クラスがあるってことだろ。
そうとも限らないんだけどね。
gosling御大も別のアプローチをブログに書いてたりするし。

その辺の話は、こっちみると良いかも。
URLﾘﾝｸ(weblogs.java.net)

136:デフォルトの名無しさん
06/12/15 11:15:49
つーか、 -> はやめて欲しい。純粋にキモい。ふつーにドットにしろよ。

137:デフォルトの名無しさん
06/12/15 13:07:39
ドットは止めて欲しい。フィールドアクセスと区別つかんし
Groovy みたくフィールドアクセスを明示する場合に
foo.@bar なんて構文使うのもアレだし。

138:デフォルトの名無しさん
06/12/15 20:32:17
>>135
おお、　:=　はいいな・・・

139:デフォルトの名無しさん
06/12/15 22:52:45
>>132
Javaも拡張しすぎてC++と同じ道を歩みそうな予感…
ところで、みんなの職場では5.0は浸透している？
うちの職場はまだ1.3...orz

140:デフォルトの名無しさん
06/12/15 23:00:45
うちは今年度からようやく1.4

141:デフォルトの名無しさん
06/12/15 23:09:30
ちょ・・・1.3てwww
去年から1.5だな。さっさと1.6にしたいが流石に時期尚早

142:デフォルトの名無しさん
06/12/15 23:18:55
OutOfMemoryとかJMXとかの強化だけでも６に移行する価値がある。
今回はバグつぶしに金掛けてるし、実用レベルまで叩かれるのも早いかと。

143:デフォルトの名無しさん
06/12/15 23:43:34
ある程度バグはあるが、weeklyに追いかけてきたから
どれくらいのものかは肌で感じてるし安心感は強いな
イザとなったら自分で改変もできるし

144:デフォルトの名無しさん
06/12/15 23:51:49
たまたま覗いたら JDK7 b04 が出てた。
URLﾘﾝｸ(download.java.net)

そろそろ JDK7 も本格始動？

145:デフォルトの名無しさん
06/12/16 00:00:48
XML構文より先にヒアドキュメントを実装して欲しい。

146:デフォルトの名無しさん
06/12/16 00:58:28
１月から開発するNetBeans Platformベースのデスクトップアプリで
JDK6を使ってみる。「WindowsVistaに対応してます」の一言で
クライアントのOKが出た。JDK6でなければならない理由はないんだけど、
何より俺が使ってみたいのだ。

147:デフォルトの名無しさん
06/12/16 01:00:31
おめでとうｗ

148:デフォルトの名無しさん
06/12/16 20:31:10
>145

同意

149:デフォルトの名無しさん
06/12/16 22:13:48
別にここでするレスじゃないかも知れんが
共用体が欲しいなあとなんとなしに思ってたけど
nioのByteBufferが既にそれっぽいことに今更気づいた。

150:デフォルトの名無しさん
06/12/16 23:59:17
>>146
デスクトップアプリで６を使うのはいいと思うけど、EclipseRCPにしてもNetBeansPlatformにしても
へんなのをかますと余計にめんどくさいだけだと思うんだが
重くなりやすいし、バグがあったとしても回避しにくい

普通にSwingベースのほうが開発効率がいい
まぁNetBeansPlatformはSwingベースで開発できる分まだ楽か

151:デフォルトの名無しさん
06/12/17 00:01:20
150が何いってんのか誰か教えて。

152:デフォルトの名無しさん
06/12/17 00:23:59
君にはまだ早い

153:デフォルトの名無しさん
06/12/17 00:28:01
今度こそ本当にJavaでデスクトップアプリ開発が流行るんですかね？

154:デフォルトの名無しさん
06/12/17 00:31:35
流行るってかモチベーションの問題だろ
5.0で既に十分なポテンシャル持ってたのに作らなかった。
事実やる気全開のV2Cは今や非Win用2chブラウザの重鎮だし。

155:デフォルトの名無しさん
06/12/17 00:35:59
・グループレイアウトが標準実装された
　これによってGUIコンポーネント配置が容易に（絶対座標系のレイアウトやVBなどより楽になった）

・VMの起動速度大幅アップ＆VM起動前にスプラッシュ表示可能
　クライアント用途ではVM立ち上げ直しが多いから有効

リッチクライアント用途ではすでに普及してると思うが、クライアントサーバのように2層式が
まだ弱いのが今後大幅に改善されるかもしれない

たしかNetBeansでGUIコンポーネントとDBをつなげるやつ開発してたよね
JPA,JDBC4、RowSetなどでこの辺実装できるはずだけどどれ使うんだろ

postgreSQLだけRowSet動かないのもなぁ
postgreSQLはJDBCドライバすててるのかな
Oracleのように実装してもらわないと改善されない予感
OracleはOracleで基本がなってないのだが、JDBC4で強制的にLOBまわり改善されるのが面白い

156:デフォルトの名無しさん
06/12/17 00:38:22
>>154
V2Cいいんだけど参照のこったままになるの改善してほしいな
ひとつも開いてなくてもあきメモリーがなしってひどす

157:デフォルトの名無しさん
06/12/17 00:59:46
>>155
RowSetって使ってるとこあるの？
JDBC4.0は何故かRowSetに肩入れしてるけど
JPAとレイヤーも被ってると思うんだよなぁ

158:デフォルトの名無しさん
06/12/17 01:08:15
>>132
あくまで提案か。
実装するにはヤバイのが多いな。
BigDecimalの演算子だが
divide使うとき、MathContextの値はどうするのだろうか。
二つのBigDecimalオブジェクトのMathContextの値が異なれば
誤差が片方のMathContextの制度を基準にして除算を
することになると思うが、そうしたくない場合には
結局BigDecimal#divide(BigDecimal, MathContext)を使うことになるんだろうな。

その辺り、どう解決するのだろうか。

159:デフォルトの名無しさん
06/12/17 01:18:13
とはいえ、いまだに大量に要る浮動小数点を金額計算に使うやつらをとめれるのは大きいか

だってnewするの面倒だもんと聞いたときには何の冗談かと

あとしらないで1.05とか掛け算したんだけど、なんかコンパイルエラーが出るんですが、doubleにしたらエラー消えたからOKだとおもったとか

こんなのが業務プログラム経験10年とかでベテランですといってごろごろいるんだが
そのたびにぶちきれてる俺はいやなやつと思われてるっぽい

160:デフォルトの名無しさん
06/12/17 01:20:41
その手の奴はダメ出ししまくって修正させると「さすが大先生」とか卑屈になるんだよな
正直どうにかして首に追い込めないかとか考えてしまう。

161:デフォルトの名無しさん
06/12/17 01:23:39
javaのジェネリクスのしょぼさがなぁ。
C++のテンプレートと同じことが出来なきゃ先は無いだろ。

162:デフォルトの名無しさん
06/12/17 01:29:11
>>160
今のところ5.0導入してから半分くらいはついていけないのを確認

5.0ではListに入れる型がわかるので結合時のエラーが減りますね！とかenum便利ですね！とかwktkしてる人もいれば
なんで5.0つかうんだよとうつろなやつもいて、非常に適正がわかりやすい

>>161
目的が違うんだからいいんじゃね？C++と同じだったら逆にぶちきれるだろ

163:デフォルトの名無しさん
06/12/17 01:31:31
Javaにboostみたいなのが出てくるのも考えモノだな。

164:デフォルトの名無しさん
06/12/17 01:32:22
templateが害悪だからGenericsになったわけだが。

165:デフォルトの名無しさん
06/12/17 01:33:10
>>159
BigDecimal,BigInteger用のシンタックスシュガーが導入されれば何とかならんかね・・・
しかし・・・・丸めとかの規定ないの？仕様に。

166:デフォルトの名無しさん
06/12/17 01:40:34
123.45B とか 999999B で型推論？精度が違う場合は警告とし、左のほうに合わせる。

167:デフォルトの名無しさん
06/12/17 02:10:27
>>164
ジェネリクスが今の形になってるのはただ単純に互換性を保つためだけの理由からだよ。
だいたいタイプパラメーターにnew出来ないってありえねーよ。

168:デフォルトの名無しさん
06/12/17 02:17:31
ありえるからJavaは普通に普及してるんだけど。

169:デフォルトの名無しさん
06/12/17 02:34:32
>>167
無制限に型パラメータで new するのは C# でもできないし。

170:デフォルトの名無しさん
06/12/17 02:37:58
防御的コピーしたい場合を考えるとコピーコンストラクタくらいは使えてもよかったかな。

171:デフォルトの名無しさん
06/12/17 02:45:01
>>170
つ「スペルミスなんだけど、気付いた時には既に修正不能だったという逸話が有名な Cloneable」

172:デフォルトの名無しさん
06/12/17 03:03:58
でもスペルミスが指摘されたのはβ時代。
何が遅すぎるのやら。

173:デフォルトの名無しさん
06/12/17 03:05:23
あ、これのことね。
URLﾘﾝｸ(bugs.sun.com)

174:デフォルトの名無しさん
06/12/17 03:25:14
>>167
互換性が大事だと一番分かっているのはC++だろｗ

175:デフォルトの名無しさん
06/12/17 03:39:45
creat・・・・

176:デフォルトの名無しさん
06/12/17 12:05:10
近い未来・・・、JavaがJavaでなくなる日が訪れる。

177:デフォルトの名無しさん
06/12/17 12:19:03
>>139
5.0で浸透している。
やはりGenericsとアノテーションは重宝する。
JUnitもアノテーションに対応したことだし。
Generics
>>141

178:デフォルトの名無しさん
06/12/17 17:28:19
>>156
うちのV2Cはなったことないな。
ヒープサイズの問題でないなら本スレにバグレポした方がいい。

179:デフォルトの名無しさん
06/12/17 18:40:37
DolphinといえばSwing Application Frameworkが気になる。
URLﾘﾝｸ(developers.sun.com)

180:デフォルトの名無しさん
06/12/18 00:30:49
>>155
> リッチクライアント用途ではすでに普及してると思うが、クライアントサーバのように2層式が
> まだ弱いのが今後大幅に改善されるかもしれない

あれかServlet/JSPとの連携が弱いってやつな。
たしかに俺も思った。弱いって言うか扱いにくい。
RMIでないといけないから。

StrutsやJSFがSwingと合体すれば使いやすいのだが。

181:デフォルトの名無しさん
06/12/18 00:40:29
いや、ふつうに2層式だからクライアントとDBとの接続
RMIでもWebServiceでもいいけどそれらのもってきた値とコンポーネントとの関連付けが今は手動になっちまう

＞StrutsやJSFがSwingと合体すれば使いやすいのだが。
これはありえないだろ
前2つよりSwingのほうが圧倒的に使いやすいし

182:デフォルトの名無しさん
06/12/18 00:46:12
JSFのSwing化はJSF登場時からすでに検討課題だから。
てかSwingコンポーネントひとつひとつが<input>タグ化すればいいだけの気もする。
バリデータとコンバータがフレームワーク毎にあることのがメンドイ？

183:デフォルトの名無しさん
06/12/18 00:52:02
各種イベントがどうしようもねぇな、WEBページベースだと

184:デフォルトの名無しさん
06/12/18 01:19:56
>>159
> とはいえ、いまだに大量に要る浮動小数点を金額計算に使うやつらをとめれるのは大きいか
> だってnewするの面倒だもんと聞いたときには何の冗談かと

valueOf()を使えと言っておけ
と思ったが10進2進変換誤差の問題があるから new BigDecimal(String, MathContext)しかないな。

にしてもBigDecimal.valueOf(String) 欲しいモノだ。

185:デフォルトの名無しさん
06/12/18 01:21:54
ValueOfableの出番だな

186:デフォルトの名無しさん
06/12/18 01:23:03
>>181
> 前2つよりSwingのほうが圧倒的に使いやすいし

Swingだと、
HTMLやXSL + XMLで書かれたページと連携するのが
不便なのだが。

187:デフォルトの名無しさん
06/12/18 01:24:17
JSF, Struts, tapestry, Seasar2 + Ajax

これをSwingと連携する方法が・・

188:デフォルトの名無しさん
06/12/18 01:25:15
レスポンスで必要なのはXMLだけだろ。
Webフレームワーク側がXML+XSLTに移行すれば皆幸せ。

189:デフォルトの名無しさん
06/12/18 01:53:43
>>188
そういうこと
通信自体はJAXB/JAX-WSが6からクライアントに来たことによってかなりよくなった
後はそのバインドされたコンポーネントだけ

190:デフォルトの名無しさん
06/12/18 03:07:51
Strutsはどうでもいいけど、JSFみたいに画面遷移を管理する仕組みがSwingにも欲しい。
Visual Web Packの画面遷移エディタみたいにSwingでも画面遷移管理。

191:デフォルトの名無しさん
06/12/18 18:16:52
さすがのJavaも98/Me非対応になったかｗ

192:デフォルトの名無しさん
06/12/18 22:38:49
VRAMとかもついてけないんだろうか。
そういやMMOするのも一苦労だったな、あの頃は。

193:デフォルトの名無しさん
06/12/19 23:55:07
>>190
このボタンをおしたら２つフレームを出して、ボタンの乗っているカードレイアウトのページを切り替えて・・・とか
そういうのもあるからページベースで考えるというのは無理がある

それに画面遷移の一元管理なんてべつにむずかしくはないだろ

194:デフォルトの名無しさん
06/12/20 08:39:04
>>193
JSFのページ遷移でいいんだよ。
画面遷移エディタで俯瞰で見れるのが欲しい。

195:デフォルトの名無しさん
06/12/20 20:54:04
最近思うんだがMSの.Netでいいんじゃないかと。
Java EE + ウェブコンテナ + ジャカルタ + オープンソース系の技術
これらの寄せ集めもいいが、この統一感が無い感じこれらの技術よりと
結局は同等のことが出来るMSで統一するのが一番楽に思えてきたんだよ…

若いっていいよな…

196:デフォルトの名無しさん
06/12/20 20:57:11
>>195
今はＰＣサーバの能力あがったから大丈夫かもしれんが、ちょいと前まではスケーラビリティの問題がでかかったんだよね

197:デフォルトの名無しさん
06/12/20 22:34:55
>>195
Java EEのJSF+EJB3でだいたいいけるよ。

198:デフォルトの名無しさん
06/12/20 23:31:45
>>195氏のためにNetBeans Visual Web Packを試してみるか。

199:デフォルトの名無しさん
06/12/21 00:21:31
>>199
JSCとほぼ同じだが、いい感じで統一感がでてると思うね。

200:デフォルトの名無しさん
06/12/21 00:34:44
>>195
俺も昔そう感じていた時期もあったが、
バージョンアップによる互換性のなさに嫌気がして、
その世界から抜け出した。
いまでも.NETで互換性の問題が出ているようだし
判断は間違ってなかったと思ってる。
もちろん、100%PureMSの生み出すパワーは魅力的なのは否定しないがね。

201:デフォルトの名無しさん
06/12/21 00:37:14
仕事で使うのが未だに1.4だらけな件…

202:198
06/12/21 01:07:05
うん、画面遷移も楽そうだった。SessionBean1とか作られてるんだがTomcatだけで動いてるのが何か不安ｗ

203:デフォルトの名無しさん
06/12/21 07:25:51
Javaが良いのは、MSの（API解説）文章よりも
SUNの文章の方が優れていたからじゃないかと思ってる。
Java周辺（SUN/IBM周辺）の技術文章（や本）で統一感があれば
MSのサービスなんか目じゃなくなるんだろうな…

204:デフォルトの名無しさん
06/12/21 07:29:48
技術の相互互換性の問題とバージョンアップの後方互換性の問題のようだね。
足腰が不安定なオープン形の技術よりも、長期間手厚くサポートされ最後まで存続する
技術（ソフト・サービス）はMSの方だと思う。
だけど、現状で融通が利くのは>>195の指摘する限りだ。

205:デフォルトの名無しさん
06/12/21 09:19:40
昔は「MS」という名前を見ただけで発狂するJava使いが多かったが、冷静に語れる時代になったんだなあ。

206:デフォルトの名無しさん
06/12/21 11:26:19
>>205
そんな奴はJava界にとっても害悪でしかないからなあ。消えてもらって結構。
思う存分Googleでもマンセーしてればいい。

207:デフォルトの名無しさん
06/12/21 11:34:31
>>204
そうかなぁ？
MSも技術的には不安定だと思うね。
元VB使いなんだが、2.0から使ってて、バージョンアップの度に、移植に手間がかかったり、
クライアントの環境によっては動かない事があるなど、
いい思い出はない。

208:デフォルトの名無しさん
06/12/21 11:41:42
>>205
元々MS嫌いな奴らがいて、
彼らがJavaに飛びついただけ。
単純に言語的な魅力を感じて、Java使いになった人もいるわけで。
今は後者が増えたのだろう。

209:デフォルトの名無しさん
06/12/21 12:03:45
>>195
それが統一感がないと感じるのか。

それならJakarta を外してSun純正にすれば？

210:デフォルトの名無しさん
06/12/21 13:45:21
色々な開発方法が利用できることが良いとみるか悪いとみるかだな。

ASP.NETは型にはまれば楽チンだが、ちょっと型から外れることを行うときは、
一から自分でお膳立てしないといけなくて面倒なこともあるよ。

211:デフォルトの名無しさん
06/12/21 19:23:28
>>209
そういうことじゃないと思うよ。

212:デフォルトの名無しさん
06/12/21 19:26:00
>>210
そういうのところ（ニッチ市場ともいうか）以外は全部MSになってしまうってことなんだね。
Javaの出番は結局大規模上層のところなのかなぁ

213:デフォルトの名無しさん
06/12/21 20:17:53
>>212
どうしてそういうレスになるんだ？
日本語理解できてる？

214:デフォルトの名無しさん
06/12/21 23:07:37
Railsの興隆とかも、結局MSが作ってきたオールインワンなプロダクトの
フリー版が出てきたよ！ってだけの意味しかないと思うんだが、
何であんなにみんな寄ってたかってあがめたてるのか謎だわ。

まぁ、Rubyの言語的に優れたところを認めるのにはやぶさかではないが。

215:デフォルトの名無しさん
06/12/21 23:13:36
Railsの場合は宣伝パワーかねぇ。

216:デフォルトの名無しさん
06/12/21 23:34:21
JavaDocは中々優れたツールなんだけど
皆あんまり真面目に書かないんだよな

事前条件の提示とかフェイルファストとかスレッドセーフとか
確かにSunのドキュメントは細かく書かれてて戸惑いが少ない。
驚き最小限の法則に基づけばこの姿勢は大切。

217:デフォルトの名無しさん
06/12/22 02:31:53
Macが売れ出してWindowsあぼーんでJavaが大活躍。
そんな未来が、君には見えないのか？

218:デフォルトの名無しさん
06/12/22 05:17:12
それをいったらRubyにも同じ未来が！
Javaは、Macでデスクトップでの可能性が見れたという部分は大有りだがな。

GPL化されたJVMをプレインストールしてPC売り出す勇気のある会社はねえんかね

219:デフォルトの名無しさん
06/12/22 13:18:36
GPL化されてなくてもプリインストールされてるけど、なんか問題あるか？

220:デフォルトの名無しさん
06/12/22 15:17:14
>>216
自分はちゃんとjavadocコメント入れてるよ、というかうちのチームは入れないと深夜に呼ばれて質問されても文句言えないって教わってきたからだけど。

221:デフォルトの名無しさん
06/12/22 15:19:58
>>220
いいチームだな
ドキュメントコメントいれておけば補完時に説明出るしね
別途用意したドキュメントとは別次元

publicなメソッド等にはドキュメントコメントがないとコンパイルエラーでてもいいと思うんだ

222:デフォルトの名無しさん
06/12/22 16:26:51
>>216
書いてるよ。Eclipseのプラグインを
使わないと真面目に書く気起きないだろうけど

223:デフォルトの名無しさん
06/12/22 19:35:11
>>216
書いてるよ。
でも中国人の中国語が文字化けしてるよ。

224:デフォルトの名無しさん
06/12/22 22:18:32
Sun の中の人のブログ
URLﾘﾝｸ(blogs.sun.com)
で、言語拡張のリストっぽいのが出てる。
closure のリンク先見るに、>>132 よりはこっちのが新しいっぽい？

>>132 と比べると BigDecimal の四則演算が見当たらない。
代わりに C# のインデクサっぽいのが入ってたりする。

ついでに、closure の最新っぽい草案
URLﾘﾝｸ(www.javac.info)

もひとつついでに、>>135 で触れてる gosling案とかを実装してみたらしい。
URLﾘﾝｸ(weblogs.java.net)

次ページ