[mustang/Java SE 6] ..
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)
225:デフォルトの名無しさん
06/12/23 20:35:14
型推論は個人的にちょっとまった！だな。
変数のスコープが分かりにくくなる形での推論は特に。
var型とかを用意して必ず有効な参照で
初期化しなければならないくらいのルールは欲しい。
可読性対策に問題が出るくらいなら冗長なGenericsのままのがいいす。
226:デフォルトの名無しさん
06/12/23 20:45:53
IDEが自動補完してくれたほうがいいな。
227:デフォルトの名無しさん
06/12/23 20:54:26
> 変数のスコープが分かりにくくなる形での推論は特に
って具体的にどーゆー事かわからん。
228:デフォルトの名無しさん
06/12/23 21:05:19
スクリプト言語みたいに
始めてその名称が使用されたタイミングで
参照型が作られるのはアカンということ。
229:デフォルトの名無しさん
06/12/23 21:22:49
>>224 にある奴とかは、単に変数宣言のシンタックスシュガーなだけでしょ。
スコープがわかりにくくなるんかな？
230:デフォルトの名無しさん
06/12/23 21:29:19
メソッドの頭から眺めるなら大したことじゃないが
スタックトレースからコード追うときはイラっとくるかも
231:デフォルトの名無しさん
06/12/23 21:59:35
スコープが混乱するのって
URLﾘﾝｸ(weblogs.java.net)
の for ループの中で algol構文のシンタックスシュガー使ってる時だけだと思うが。
後は final が付いてたり := があるから変数宣言してんのわかるし。
232:デフォルトの名無しさん
06/12/25 18:39:39
Concurrent API便利なのに使ってる人少なすぎ
233:デフォルトの名無しさん
06/12/25 23:23:49
>>232
話題にならないのはすでに2年以上も前の話だからだろ？
234:デフォルトの名無しさん
06/12/26 16:42:28
マルチスレッドでプログラムしてる人が少ないんだろうな
そしてプログラムで使える人はわかってる人。
というか、次世代じゃなくて現世代だよな。
235:デフォルトの名無しさん
06/12/26 21:00:24
Webアプリだとコンテナとフレームワークの上でガシガシ組むから基本スレッドは意識しないな。
236:デフォルトの名無しさん
06/12/26 21:15:30
Concurrent APIとかフレームワーク作る人が使うもので
フレームワーク使う人が使うものじゃないな
237:デフォルトの名無しさん
06/12/26 22:59:07
>>234
前世代だろ？
238:デフォルトの名無しさん
06/12/26 23:33:19
>>235
こんな、やつがwebアプリ作るからwebアプリって全般的に品質低いんだよ。
たとえば、J2EEは、基本マルチスレッドモデルだからインスタンス変数なんか定義して
リクエストの情報を設定したりなんかすると平気で他人の状態に書き換わったりする。。
strutsみたいなフレームワークを使ってても同様↓
ActionのJavadocより引用
------
リクエストの状態に関連する情報を保持するためにインスタンス変数やスタティック変数を使用してはいけません。
インスタンス変数やスタティック変数は同一のアクションに関してリクエストをまたがってグローバルなリソースを共有したい場合に使用します。
239:238
06/12/26 23:42:30
もっと詳しい解説があった。
とにかく、webだからスレッドなんて関係ないぜ。ってのは、よしてくれ。
URLﾘﾝｸ(www.atmarkit.co.jp)
240:デフォルトの名無しさん
06/12/27 00:06:25
>>232
日本語のサンプルすくないじゃん。
サンプルがないとコードがかけないと思う。
241:デフォルトの名無しさん
06/12/27 01:19:41
>>238
WEBアプリだと自分で明示的にスレッド作ることは
あまり無いっちゅうことじゃないの？
さすがにそのレベルの間違いをする人はそんなにいない・・・
と言いたいところだが、ちらほら見かけた。
StrutsのActionクラスとかにインスタンス変数書きまくって
「テスト通る時と通らない時があります！
FWのバグじゃないですか？」
とかこいてて、いますぐ死ねってまじで思った。
242:デフォルトの名無しさん
06/12/27 05:10:02
何のためにセッションやらリクエストパラメータがあるのかと小一時間>>Webアプリのへたれプログラマ
243:デフォルトの名無しさん
06/12/27 05:17:26
>>241
いやいや、マルチスレッドなのにオブジェクトを使い回すような設計になっているのが悪いんじゃないか。
いまやオブジェクト生成・破棄のコストはそんなに重大ではないんだから、
もっと素直にプログラムできるようなモデルにすべきだった。
244:デフォルトの名無しさん
06/12/27 08:12:03
>>243
設定でシングルスレッドモデルって言ってシングルスレッドで動作させる
ようにもできる。
その上でフレームワークを使うって言ったら結構なメモリを使うであろうことが
容易に想像できるわけだが。
245:デフォルトの名無しさん
06/12/27 12:32:11
もうシングルスレッドモデルはねーぞ
それにインスタンスも複数使われるかもしれないし、ひとつかもしれないという自由度だったはず
Tomcatはひとつだったはずだけど
スレッドプーリングしてるんだよとか基本を教えないでこのメソッドのみで適当に作っといてとしかいわないのも悪い
246:デフォルトの名無しさん
06/12/27 14:22:28
結構なメモリってどんな処理だ？
247:デフォルトの名無しさん
06/12/28 08:29:24
配列のインターフェイスが欲しいな。例えばjava.lang.Array見たいな感じ。
interface Array<T>{
T get(int idx);
void set(T value, int idx);
int getLength();
Array<T> clone();
Class<? extends T> getComponentType();
}
見たいな感じ。で、
String[] hoge = new MyArray<String>();
みたいに配列として使える感じ。逆もありで、
Array<String> array = hoge;
として代入も可能。タイプパラメータがあってればいい感じ。
通常の配列もこのインターフェイスを実装済みでいいかも。
248:デフォルトの名無しさん
06/12/28 08:31:24
>>247
言語仕様的にはできなくは無いだろうけど、JVMレベルでの互換性を
壊すから、まず入ることは無いだろうな。あと、従来の配列はcovariantだが
genericsはcovariantじゃないというのもある
249:デフォルトの名無しさん
06/12/28 11:17:30
>>247
配列じゃないけど indexer っぽいのは >>224 の wish list に入ってたけど。
250:デフォルトの名無しさん
06/12/28 23:45:13
>>247
ここのArray Syntax for Collectionsがあればいいんじゃない？
URLﾘﾝｸ(blogs.sun.com)
251:250
06/12/28 23:46:00
あ、249が言ってるのと同じだった。
252:247
06/12/29 00:47:46
構文のサポートも欲しいところなんですが、
配列を抽象化できるのも魅力かなと。
でもcovariantが・・・なるほどね。。。
BigDecimalの四則演算対応も、できれば何かの特定のインターフェイスを
実装していれば対応できるというのが希望。
それって何て演算子オーバーロード？って言われそうですが・・・
253:デフォルトの名無しさん
06/12/29 01:36:56
ArrayList<Integer> list = {12, 34, 56};
みたいな初期化ができれば、配列の抽象化にこだわる必要はまったくなくなると思う。
コレクションのための配列構文も、[]のオーバーロードみたいなもんだし。
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5369日前に更新/271 KB
担当:undef