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

[mustang/Java SE 6] ..

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};
みたいな初期化ができれば、配列の抽象化にこだわる必要はまったくなくなると思う。
コレクションのための配列構文も、[]のオーバーロードみたいなもんだし。

254:デフォルトの名無しさん
06/12/29 01:44:57
型推論っていうんだっけ？

List<Integer> list = {12,34,56};
は、コンパイルエラー？

255:デフォルトの名無しさん
06/12/29 03:26:09
デフォルトをつけるかどうかだよね。
自分は、それはコンパイルエラーでいいと思う。

256:デフォルトの名無しさん
06/12/29 03:28:09
要するにこんな感じのが欲しい。
URLﾘﾝｸ(d.hatena.ne.jp)

257:デフォルトの名無しさん
06/12/29 10:02:43
>>253
final list = ArrayList.of(1, 2, 3);

でよくね？ >>250 に載ってる
・More factory methods for colllection classes
・Shorthand syntax for declaring local variables
のあわせ技で出来ると思うんだけど。

258:デフォルトの名無しさん
06/12/29 10:23:29
> More factory methods for colllection classes
問題は Map の factory method だよな、と思う。

259:デフォルトの名無しさん
06/12/29 10:32:38
List<Integer> list = Arrays.asList(1, 2, 3);

260:235
06/12/29 12:00:42
>>238
インスタンス使い回すっていうコンテナの構造上の問題は普通に意識するだろ。
マルチスレッド以前の問題だ。

Webアプリでスレッドを用いる必要があるのはデータのインポート＆エクスポートぐらいだと思う。
重い処理をする間、ユーザーを待たせないっつー意味で。

261:デフォルトの名無しさん
06/12/30 13:25:27
java.ioとnioの親和性をもうちょっと頑張って欲しいな

262:デフォルトの名無しさん
06/12/31 02:02:39
親和性って具体的には？

263:デフォルトの名無しさん
06/12/31 02:41:17
Channelはデコレートパターン向きじゃないからね
Buffered*StreamみたいなのBuffer版アダプタを
標準で用意してくれるだけでも嬉しい

264:デフォルトの名無しさん
06/12/31 02:52:32
ああ、しかし、BufferedとByteBufferだと名前が似すぎて間違えるか

265:デフォルトの名無しさん
06/12/31 10:56:51
>>263
BufferedChannel みたいなものが欲しいって事？
ByteBuffer.wrap(new byte[1]); みたいな小さい ByteBuffer 作って
ちょこまか読み書きしてないなら大して必要とも思わないけど。

ってか、java.ioとの親和性とか関係ないような。

266:デフォルトの名無しさん
06/12/31 12:14:45
ByteBufferInputStreamとかStream側にあわせるアダプタだろ

267:デフォルトの名無しさん
06/12/31 13:16:45
> ByteBufferInputStream
要るか？

268:デフォルトの名無しさん
06/12/31 13:34:33
>>267
それが欲しければアプリの中で用意すれば？
ってレベルの需要だろうなぁ

269:デフォルトの名無しさん
06/12/31 13:34:34
場面によりけり。ダイレクトバッファ使ってる場合なら欲しい。

270:デフォルトの名無しさん
06/12/31 13:51:22
writeToメソッドみたいなのがBufferに欲しい

271:デフォルトの名無しさん
06/12/31 14:46:16
>>269
ダイレクトバッファ使ってても、
InputStream や OutputStream のデコレータだったらアドバンテージないんじゃ？

272:デフォルトの名無しさん
06/12/31 14:48:28
>>270
ByteBuffer#get(byte[]) とかあるけど。

273:デフォルトの名無しさん
06/12/31 14:50:18
>>272
それを言うなら ByteBuffer#put(byte[]) じゃないかと。

274:デフォルトの名無しさん
06/12/31 14:52:27
マップファイルを外部にゲロるのに便利そう writeTo

275:デフォルトの名無しさん
06/12/31 14:55:19
>>271
コンポーネント単位で見ればそれもありでは？
nioのが効率はいいんだから、
最適化が必要になった時にnioにあわせていけばいい。

276:デフォルトの名無しさん
06/12/31 14:56:41
便利に使いたいだけなら
NIOUtils.writeTo(WritableByteChannel, ByteBuffer)
みたいなユーティリティメソッドつくっときゃ良いだけのような。

277:デフォルトの名無しさん
06/12/31 15:01:08
>>275
いや、単純に無駄だよねって話。

中途半端にやるとクラスが汚くなるだけだし。
最適化が必要になりそうならアプリ側で入出力処理を抽象化しておきゃ良いんだし。

278:デフォルトの名無しさん
06/12/31 15:06:00
>>277
内部で Channel 使った ChannelInputStream とか ChannelOutputStream で最適化する時
read(ByteBuffer) とか write(ByteBuffer) があると便利なんだよ！

すげーアホ臭いな。そんだったら最初から Channel 使えば良いし。

279:デフォルトの名無しさん
06/12/31 15:07:05
> NIOUtils.writeTo(WritableByteChannel, ByteBuffer)
要るか？

280:デフォルトの名無しさん
06/12/31 15:07:07
ん？Servletにnioを適用するための記事とか普通に出回ってるが

281:デフォルトの名無しさん
07/01/05 02:17:08
6.0でCommons Modelerを使用してPOJOを登録したんだがjconsoleのmbeanタグ
で表示されないのは既出ですか？

282:デフォルトの名無しさん
07/01/10 21:20:03
DOMとコレクションフレームワークの親和性をあげてほしいなぁ。

283:デフォルトの名無しさん
07/01/11 01:52:34
Closure の人(?) が面白いアイデアを書いてる。
URLﾘﾝｸ(gafter.blogspot.com)

なんか、javac弄って遊ぶプロジェクトらしい？
URLﾘﾝｸ(ksl.dev.java.net)
URLﾘﾝｸ(blogs.sun.com)

>>224 の一番最後の人が property を試しに実装してみたらしい。
URLﾘﾝｸ(weblogs.java.net)

protperty 慎重派の人も居るらしい。
URLﾘﾝｸ(weblogs.java.net)

アプリ書く人と、ライブラリ（Swingコンポーネントとか）書く人の違いなんだろか？

284:デフォルトの名無しさん
07/01/11 19:27:09
propertyってどんな機能を指してるのかよくわかんないんだけど

object.x = "hoge" を object.setX(String str)
String str = object.x を object.getX()

にmappingする機能でおｋ？

ObjectPascal とかだと直接フィールドを参照するか、メソッドを指定するかとか出来るけど
そーゆー事も考えられてるのかな？

フィールド指定を可能にすることで無駄なsetter,getterの記述が不要になることが
propertyを導入する最大の利点だと考えてるのでそーゆーのが考慮されてないといまいちだなぁ

285:デフォルトの名無しさん
07/01/11 20:03:56
>>284
> propertyってどんな機能を指してるのかよくわかんないんだけど
それ自体も議論の対象っぽい。
getterやsetterの呼び出しのシンタックスシュガーだけじゃなくて
暗黙的なフィールドやgetterやsetterの宣言のシンタックスシュガーまで含んでたり。
例えば、public property int hoge; って書くと、暗黙のうちに
private int hoge;
public void setHoge(int h){ hoge = h; }
public int getHoge(){ return hoge; }
が自動生成されるとか。
java.lang.Class に getProperty みたいなメソッドを追加したいって人も居るし。
JavaBeans の場合は firePropertyChange よんだりも！ってのもあるかもしんないし。
他にも色々あるんじゃない？

>>283 で紹介されてる実装だと、property つけて宣言しないと
シンタックスシュガーでセッターゲッターにアクセスできなかったりする。

286:デフォルトの名無しさん
07/01/11 20:22:31
> フィールド指定を可能にすることで無駄なsetter,getterの記述が不要になることが
でも、これって 5文字ぐらい節約できるってだけなんだよねぇ……

287:デフォルトの名無しさん
07/01/11 22:05:40
>>286
いやいや違う、漏れが言いたいのは

//フィールドの定義
private int fieldX = 0;

//値をセットするときに必要な特殊処理
public void setX(int x){
　this.fieldX=x;
　this.logic();
}

//プロパティの定義でgetterはそのまま使って、setterはメソッドを使う
property int x read fieldX write setX;

イメージ的にはこんな感じ。ほぼObjectPascalなんだけどさ。
フィールドの定義は省略して、暗黙的に定義してくれるとなおよさげ。

288:デフォルトの名無しさん
07/01/11 22:43:37
>>287
その辺はどー転ぶかわかんない。property 自体却下される可能性もあるし。
とりあえず >>283 のプロトタイプだとできない。

> property int x read fieldX write setX;
この構文だと、Java ではフィールド名と同じメソッド名付けられるから
fieldX って名前のフィールドに加えてメソッドまであったらどーすんだろ、とか
setX 以外の名前が指定できると、現在既にあって setX を期待してる
フレームワークが困りそうだなぁ、と思った。

289:デフォルトの名無しさん
07/01/12 23:43:12
URLﾘﾝｸ(jcp.org)
Eclipse FoundationがJCPメンバーとして参加することに
なったらしい。ちょっと前にEclipse代表のMike Milinkovichが
JSR277とJSR291の進行に激怒してたからなんかやるだろうなとは思ってたけど。
JSR291に反対票投じたRedhatも先月推進派に転じたみたいだし、さらに今度の
Eclipseの票も加えて1/16～22にあるJSR291の投票をのりきりたいんだろうね。

290:デフォルトの名無しさん
07/01/16 01:46:34
>>287
setXxx、getXxxっていうのをプロパティとみなす仕様は変えれないと思うよ。
IDEのプロパティエディタやらJSPのELやら、既存のツールやライブラリが使えなくなる。

291:デフォルトの名無しさん
07/01/16 05:09:43
Java6の話はどこですればいいのかな？

292:デフォルトの名無しさん
07/01/16 19:56:31
>>291
現世代Javaの動向 1
ｽﾚﾘﾝｸ(tech板)l50

293:デフォルトの名無しさん
07/01/18 08:02:25
AjaxでハイブリッドP2P型を作成しようと思っているのですが、
これを作るにはJ2SE,J2EE,J2MEの内、どれが相応しいのでしょうか？
次世代Javaに詳しい方教えて下さい。

294:デフォルトの名無しさん
07/01/18 08:06:11
mustang で普通に起動した JVM に jconsole からアタッチできるようになったという
記事を見て jconsole を使おうとしたんだけど、起動後に "JConsole: Output" っていう
ウィンドウが開いて

java.lang.UnsatisfiedLinkError: no attach in java.library.path

というエラーが表示されるし、ローカルプロセスに接続しようとしても
「接続に失敗しました」となってしまいます。

うまく JVM にアタッチするにはどうしたらいいんでしょうか？
Windows XP, JDK 1.6.0 を使っています。

295:デフォルトの名無しさん
07/01/18 19:15:17
>>293
構成が今一良く分からない。Webサーバ＋P2PでUIがブラウザなわけかい？
J2EEのServlet（Jettyあたり）を落としてきて、残りはSEでガリガリ書きなさいな。

296:293
07/01/19 07:57:58
>>295
P2Pでコミュニティとファイル共有システムを作って、ソフトウェアで提供しようとしているので、
中継ノードでピュアP2P型にするか、中央サーバーでハイブリッドP2P型にするかのどっちかになるのですが、
それぞれJ2SE,J2EE,J2MEのうち、何が相応しいのでしょうか？
教えて下さいませ。

297:デフォルトの名無しさん
07/01/19 10:32:49
>>296
まず、J2SE,J2EE,J2MEが何かぐらいは調べて置いたほうがいいだろ。
それとスレ違い。

298:デフォルトの名無しさん
07/01/19 15:30:45
JDK7 build06
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)

個人的にはまだぱっとした新機能ないなぁ

299:デフォルトの名無しさん
07/01/19 20:33:11
Java6の役目はその機能ではなく、1.4.2を古いものとし、
Generics環境へのGOサインを導き出してくれることにある。
Java7もXML構文とか登場してまた汚れる（ｗ）から
Java7のデビューはJava8のリリースからとなる。

300:デフォルトの名無しさん
07/01/19 23:12:57
Genericは結構なんだけど旧形式のコレクションも@deprecatedにしないで
共存させといて問題ないと思うのだが。これのせいで１．４からの移行が進みにくい。

301:デフォルトの名無しさん
07/01/19 23:15:09
5.1が出ないってことは、最近のJREはアーキの急遽対応がないんだな。
6は載らなかった機能が一杯あるから枝が付くとなんとなく思ってるが

302:デフォルトの名無しさん
07/01/20 01:27:40
6はおまけっぽいのがてんこもりだからね。

303:デフォルトの名無しさん
07/01/20 01:29:35
>>300
どういうこと？

304:デフォルトの名無しさん
07/01/20 01:55:04
普通に「互換性あれば簡単に乗り換えれるのに」って意味じゃないの？

305:デフォルトの名無しさん
07/01/20 02:22:19
コレクションは互換性のために残されたレガシーコレクションとはあるが
非推奨だなんて注釈もdocタグも無いはずなんだが。

306:デフォルトの名無しさん
07/01/20 02:28:02
> 6は載らなかった機能が一杯あるから枝が付くとなんとなく思ってるが
1.5.1 とか 1.6.1 とか出さないって言ってなかったっけ？

307:デフォルトの名無しさん
07/01/20 03:06:14
ああこれのことね。無視すればいいけど、うちは何も考えずに<Object>つけてるぞイミねぇ

注:　ArrayListDemo.java　の操作は、未チェックまたは安全ではありません。
注:　詳細については、-Xlint:unchecked　オプションを指定して再コンパイルしてください。

308:デフォルトの名無しさん
07/01/20 03:17:36
無視したいなら@SuppressWarnings("unchecked")でいいじゃん

309:デフォルトの名無しさん
07/01/20 06:46:59
>>307
<?>の方がよくねぇ？

310:デフォルトの名無しさん
07/01/20 13:18:36
例外にもジェネリクス対応して欲しいな。
型パラメータが付いたThrowableのサブクラスを作りたい。

例えば、
class IORuntimeException<IOException> extends RuntimeException{
}
のように定義して、
catch(IORuntimeException e){
throw e.getCause(); //<--IOExceptionをスロー
}
と使えると最高。

311:デフォルトの名無しさん
07/01/20 15:38:32
RuntimeExceptionが何故IOExceptionを投げるんだ・・・

312:デフォルトの名無しさん
07/01/20 15:49:49
IOExceptionをRuntimeExceptionでラップしたいんだろ。

313:デフォルトの名無しさん
07/01/20 16:06:04
>>310
Closure で例外を透過的に使うために、ってんで検討はされてるけど、
>>310 みたいな気持ち悪い奴じゃない。

314:デフォルトの名無しさん
07/01/20 16:31:14
Neal Gafter's blog
Thoughts about the future of the Java Programming Language.

URLﾘﾝｸ(gafter.blogspot.com)

315:310
07/01/21 01:49:23
キモくてスマン。
単純にチェック例外を実行時例外でラップしたいだけ。

例外にジェネリクスが使えると、色々面白そうだけど。

class Hoge<T>{
　　void piyo() throws WrapperException<T>{
　　　　...//色々
　　}

　　void fuga() throws T{
　　　　try{
　　　　　　piyo();
　　　　}cathc(ExceptionWrapper<T> e){
　　　　　　throw e.getCause();
　　　　}
　　}
}

316:デフォルトの名無しさん
07/01/21 02:15:50
> void piyo() throws WrapperException<T>
> }cathc(ExceptionWrapper<T> e){
……。

ってか、普通に考えて ExceptionWrapper<InvocationTargetException> と
ExceptionWrapper<IllegalAccessException> が実行時に同じクラスに
成り下がりそうで拙いよね……

まぁ、ある意味では「色々面白そう」だけど。

317:デフォルトの名無しさん
07/01/21 11:26:48
>>300
問題ないはずだけど

>>308
は旧式のライブラリとの境目で使う
事実上JPAでも必須だけど

>>309
明示的にするなら<Object>のほうがいいとおもう
ただ、これを使ってる時点でGenericsの恩恵ゼロだけどね
従来のライブラリ葉変更せずに使う場合>>308を接合部分につかってラッピングするべし

次ページ