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

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 05/09 23:17 / Filesize : 271 KB / Number-of Response : 965
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

1 名前：デフォルトの名無しさん mailto:sage [2006/11/20(月) 10:38:16 ]: 前スレ

[mustang] 次世代Javaの動向 3 [dolphin]
pc8.2ch.net/test/read.cgi/tech/1157227790/

次世代Javaの動向　２
pc8.2ch.net/test/read.cgi/tech/1147881822/

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

2006年12月にMustang Java SE 6がリリース予定

Mustangの掲げる主な目標は以下の点にある。
* 互換性と安定性および品質の向上
* Easy of Developmentの実現
* WebサービスおよびXMLサポート機能の拡張
* リソース管理や診断機能の強化
* デスクトップ環境の強化

Java SE 6 じゃじゃ馬ならし
www.javainthebox.net/laboratory/JavaSE6/
76 名前：デフォルトの名無しさん mailto:sage [2006/11/27(月) 04:31:53 ]: >>75
いや、>>73の論旨を読めてないでしょう。
JavaOnlyで行わず数値演算は、Mathmatica(あれも一種の言語だよな)
何かに任せ連携を取るということもあるという話。であって
数値演算に、Java、.NET等の汎用言語を「使わない」選択肢について語ってるのが>>73
77 名前：デフォルトの名無しさん mailto:sage [2006/11/27(月) 08:07:07 ]: Mathmaticaってそんな一般的？
大学の端末には確かに入ってるけど・・
78 名前：デフォルトの名無しさん mailto:sage [2006/11/27(月) 15:36:34 ]: 本気で数値計算やるなら大抵持ってる希ガス
つーか他の製品知らない
79 名前：デフォルトの名無しさん mailto:sage [2006/11/27(月) 15:53:39 ]: >>76
Mathematicaの話をするならドトネトの話は関係ない
80 名前：デフォルトの名無しさん mailto:sage [2006/11/27(月) 15:53:57 ]: >>78
MATLABのほうが断然使いやすいんだが
81 名前：デフォルトの名無しさん mailto:sage [2006/11/27(月) 20:35:23 ]: MATLAB,Mathematicaは、理系で大学生以上なら一般的に知ってると思う
他の言語とのインターフェースは知らなかったよ。
82 名前：デフォルトの名無しさん mailto:sage [2006/11/27(月) 23:52:44 ]: MATLABは大学でも
特定の研究室に関わらないと知らないと思うぞ。

あと、高いしな。

FortranやC/C++のほうが知名度が高いだろう。
83 名前：デフォルトの名無しさん [2006/11/29(水) 20:30:40 ]: 昔、Javaにポインタを導入しろとか言ってたやつがいたなｗ
84 名前：デフォルトの名無しさん mailto:sage [2006/11/29(水) 22:24:09 ]: ぬるぽ
85 名前：デフォルトの名無しさん mailto:sage [2006/11/29(水) 23:26:25 ]: >>82
CやJavaを使える生徒が減ったという理由でMATLABが必修になりつつある情報科があるんだよなw
まず教授がCやJavaを使えないって話かもしれんがw
86 名前：デフォルトの名無しさん mailto:sage [2006/11/30(木) 01:18:03 ]: >>83
C#見て小躍りしたんだろうなぁ
>>84
うん。ガッ
87 名前：デフォルトの名無しさん mailto:sage [2006/11/30(木) 01:43:40 ]: 大学生は生徒とは呼ばない。学生と呼ぶ。
生徒は中高生のことを指す。
88 名前：デフォルトの名無しさん mailto:sage [2006/11/30(木) 20:26:03 ]: ++java
89 名前：デフォルトの名無しさん mailto:sage [2006/12/01(金) 09:48:41 ]: Java#
90 名前：デフォルトの名無しさん mailto:sage [2006/12/02(土) 07:44:53 ]: #java++
91 名前：デフォルトの名無しさん mailto:sage [2006/12/02(土) 10:42:01 ]: Java SE 6 まだ～？
92 名前：デフォルトの名無しさん mailto:sage [2006/12/02(土) 13:37:01 ]: #import <java.lang.System>
93 名前：デフォルトの名無しさん mailto:sage [2006/12/04(月) 12:24:19 ]: JDK7 build03
ttp://download.java.net/jdk7/binaries/
ttp://www.java.net/download/jdk7/changes/jdk7-b03.html

Changelogの多さからして本格稼働した様子。
94 名前：デフォルトの名無しさん [2006/12/10(日) 10:42:44 ]: 次世代Java == C#
95 名前：デフォルトの名無しさん mailto:sage [2006/12/10(日) 14:05:39 ]: 流石に言語機能としてはまだC#のほうが上かな。
さすがDelphi作者が作っただけはある。
Java 7からはプロパティやクロージャも検討されるから
2009年には若干C#より柔軟になる。
96 名前：デフォルトの名無しさん mailto:sage [2006/12/10(日) 15:43:40 ]: そーいや、クロージャの話はいろいろ出てきたけどプロパティの話はあんましみないね。
97 名前：デフォルトの名無しさん [2006/12/10(日) 19:22:49 ]: リリースまだかよ。
12月も1/3過ぎちゃうぞ。
98 名前：デフォルトの名無しさん mailto:sage [2006/12/10(日) 23:09:53 ]: なんか、最近ようやく継続の存在意義を知った
99 名前：デフォルトの名無しさん mailto:sage [2006/12/11(月) 20:13:17 ]: リリースされたよ。JDK6。
100 名前：デフォルトの名無しさん mailto:sage [2006/12/11(月) 20:33:55 ]: ランゲージパックは無し？
てか5.0のupdate10をちらっとみたけどこっちのがマニアックに凄いな
selectが内部でepollで実装されてるってことはゲーム用途でもいけそう
101 名前：デフォルトの名無しさん mailto:sage [2006/12/11(月) 21:36:15 ]: >>100
ランゲージパックなんていままでもなかったと思うが。
102 名前：デフォルトの名無しさん mailto:sage [2006/12/11(月) 21:43:47 ]: そうだっけか。ドキュメントやらNBやらと違ってそのまま使えばいいのか。
103 名前：デフォルトの名無しさん mailto:sage [2006/12/11(月) 21:50:39 ]: 静かなリリース
104 名前：デフォルトの名無しさん mailto:sage [2006/12/11(月) 22:31:28 ]: まだりりきゃんでしょ。
105 名前：デフォルトの名無しさん mailto:sage [2006/12/11(月) 22:32:50 ]: >>102
前から、JDKの日本語ダウンロードページなんかは前からあるけど、
ダウンロード方法なんかが訳されてるだけで中身は一緒だったな。
106 名前：デフォルトの名無しさん mailto:sage [2006/12/11(月) 23:17:34 ]: 翻訳は https://jdk-api-ja.dev.java.net/ja/index.html でやってるよん。
早く日本語のAPIリファレンス欲しい人は手伝ってみれば良いかも？
107 名前：デフォルトの名無しさん mailto:sage [2006/12/12(火) 09:59:49 ]: 静かなリリースsage
108 名前：デフォルトの名無しさん mailto:sage [2006/12/12(火) 12:00:47 ]: おおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおお！！

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

気が付くのが遅かった！

早速ダウソ！
109 名前：デフォルトの名無しさん mailto:sage [2006/12/12(火) 17:09:24 ]: ダウンロードにNetBeans5.5バンドルのがあるけど、
日本語版NetBeans5.5って正式リリースされてたっけ？
110 名前：デフォルトの名無しさん mailto:sage [2006/12/12(火) 18:04:31 ]: >>109
JDK6にバンドルされているのは英語版。日本語版は12/14の予定。

いまDLできるJDK6のVMだけど、NetBeansの製品情報で見ると 1.6.0-b105と表示される。
これって本当に正式版なのかな？
111 名前：109 mailto:sage [2006/12/12(火) 18:26:18 ]: >>110
thx
JDK5のときも1.5.0_0*-b0*みたいに表示されてたから、たぶん正式版だと思う。
112 名前：デフォルトの名無しさん mailto:sage [2006/12/12(火) 18:39:36 ]: build 番号 105 なのか(w
113 名前：デフォルトの名無しさん mailto:sage [2006/12/12(火) 19:13:07 ]: JDK6入れてJava2Dのデモプログラム動かしてみたけど、
起動時の画面の動きが怪しいね。
114 名前：デフォルトの名無しさん mailto:sage [2006/12/12(火) 19:22:25 ]: さいしょはみんな bはベータのbだと思うよな。
115 名前：デフォルトの名無しさん mailto:sage [2006/12/12(火) 19:33:26 ]: weeklyビルドを追っていたら混乱するはずがないです。

>>113
どう怪しいのか詳しく。
116 名前：デフォルトの名無しさん mailto:sage [2006/12/12(火) 20:53:04 ]: SwingSet2のスプラッシュスクリーンのウィンドウの形が、
影つきの非矩形でびっくりした。

着実にGUIも進歩しているなぁ
117 名前：デフォルトの名無しさん mailto:sage [2006/12/12(火) 21:23:32 ]: あら、RhinoはMapをプロパティ風に使えないのか？
これからはJavaアプリ間で使いまわすスクリプトも流行るだろうし研究しなきゃ
118 名前：デフォルトの名無しさん mailto:sage [2006/12/12(火) 21:37:35 ]: >>115
メインの画面が出る直前に、起動時のプログレスダイアログが左端に動く
119 名前：１１８ mailto:sage [2006/12/12(火) 21:38:30 ]: ×左端
○左上
120 名前：デフォルトの名無しさん [2006/12/12(火) 21:55:54 ]: パフォーマンスが改善したって聞いたけど、ほとんど感じない…
ペン３、1GHZじゃ恩恵なし？
121 名前：デフォルトの名無しさん mailto:sage [2006/12/13(水) 00:30:37 ]: VMの起動が早くなった
ような気がする…
122 名前：デフォルトの名無しさん mailto:sage [2006/12/13(水) 01:05:22 ]: nbの検索が糞遅くなった気が・・・5.0だからか？
123 名前：デフォルトの名無しさん mailto:sage [2006/12/13(水) 01:30:32 ]: 結局、SystemTrayから開けるメニューはAWTのPopupだけか。
124 名前：デフォルトの名無しさん [2006/12/13(水) 01:56:28 ]: >>121
確かに5.0よりやや早いのを確認
VM起動前にスプラッシュ出せるようになったのも重いアンチウイルスソフト使ってる人にはうれしいかもね
125 名前：デフォルトの名無しさん [2006/12/13(水) 08:54:49 ]: jarファイルのアイコンが変わったね
126 名前：デフォルトの名無しさん mailto:sage [2006/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 名前：デフォルトの名無しさん [2006/12/13(水) 16:44:55 ]: 何このIronPythonのパクリ(嘲笑
128 名前：デフォルトの名無しさん mailto:sage [2006/12/13(水) 16:48:02 ]: 何を指しているのだろう。
129 名前：デフォルトの名無しさん mailto:sage [2006/12/13(水) 16:58:14 ]: Borlandが作り
MSが真似をして
Javaが起源を主張する
130 名前：デフォルトの名無しさん mailto:sage [2006/12/13(水) 23:13:03 ]: 古い歴史を持つ Rhino や Pnuts が、
どのようにすればごく最近(2003-2004)作成された IronPython を模倣出来るんだろう．．．

最近、歴史を学ばない半島人がオリジナルにパクリを主張することが多くて困る
131 名前：デフォルトの名無しさん mailto:sage [2006/12/14(木) 01:13:19 ]: PnutsなんてJavaのごく初期から数少ないJava製スクリプト言語だったよな。
しかも日本人作なんで驚いたもんだ。
132 名前：デフォルトの名無しさん mailto:sage [2006/12/15(金) 04:27:57 ]: Java SE 7.0 のスライド、らしい。
blogs.sun.com/dannycoward/resource/Java7Overview_Prague_JUG.pdf

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

Closure の構文みるに、8月の段階で提案されてた構文っぽいので
他の言語機能も構文変わったりするのかも。
それと個人的には Java SE 7.0 って機能てんこ盛りすぎに思えるので
いくつかの機能は次のバージョンに持ち越される可能性もあるんじゃないかと心配したり。
ざっとみただけでも、コンパイルエラーになりそうなサンプルが 2つほどあったり……
133 名前：デフォルトの名無しさん mailto:sage [2006/12/15(金) 07:05:51 ]: プロパティはいらん。機能そのものじゃなくて構文がダメ。
Genericsの略式インスタンスもnew()の方はキモ過ぎる。
インタフェースのデフォルト実装クラスがあるってことだろ。
friend class構文とかと同じキモさ。
134 名前：デフォルトの名無しさん [2006/12/15(金) 07:15:41 ]: 要はC# 3.0のパクリなんだろ。(ｹﾞﾗ
135 名前：デフォルトの名無しさん mailto:sage [2006/12/15(金) 07:46:34 ]: >>133
> インタフェースのデフォルト実装クラスがあるってことだろ。
そうとも限らないんだけどね。
gosling御大も別のアプローチをブログに書いてたりするし。

その辺の話は、こっちみると良いかも。
weblogs.java.net/blog/forax/archive/2006/12/dry_dont_repeat.html
136 名前：デフォルトの名無しさん mailto:sage [2006/12/15(金) 11:15:49 ]: つーか、 -> はやめて欲しい。純粋にキモい。ふつーにドットにしろよ。
137 名前：デフォルトの名無しさん mailto:sage [2006/12/15(金) 13:07:39 ]: ドットは止めて欲しい。フィールドアクセスと区別つかんし
Groovy みたくフィールドアクセスを明示する場合に
foo.@bar なんて構文使うのもアレだし。
138 名前：デフォルトの名無しさん mailto:sage [2006/12/15(金) 20:32:17 ]: >>135
おお、　:=　はいいな・・・
139 名前：デフォルトの名無しさん [2006/12/15(金) 22:52:45 ]: >>132
Javaも拡張しすぎてC++と同じ道を歩みそうな予感…
ところで、みんなの職場では5.0は浸透している？
うちの職場はまだ1.3...orz
140 名前：デフォルトの名無しさん mailto:sage [2006/12/15(金) 23:00:45 ]: うちは今年度からようやく1.4
141 名前：デフォルトの名無しさん mailto:sage [2006/12/15(金) 23:09:30 ]: ちょ・・・1.3てwww
去年から1.5だな。さっさと1.6にしたいが流石に時期尚早
142 名前：デフォルトの名無しさん mailto:sage [2006/12/15(金) 23:18:55 ]: OutOfMemoryとかJMXとかの強化だけでも６に移行する価値がある。
今回はバグつぶしに金掛けてるし、実用レベルまで叩かれるのも早いかと。
143 名前：デフォルトの名無しさん mailto:sage [2006/12/15(金) 23:43:34 ]: ある程度バグはあるが、weeklyに追いかけてきたから
どれくらいのものかは肌で感じてるし安心感は強いな
イザとなったら自分で改変もできるし
144 名前：デフォルトの名無しさん mailto:sage [2006/12/15(金) 23:51:49 ]: たまたま覗いたら JDK7 b04 が出てた。
download.java.net/jdk7/changes/jdk7-b04.html

そろそろ JDK7 も本格始動？
145 名前：デフォルトの名無しさん mailto:sage [2006/12/16(土) 00:00:48 ]: XML構文より先にヒアドキュメントを実装して欲しい。
146 名前：デフォルトの名無しさん mailto:sage [2006/12/16(土) 00:58:28 ]: １月から開発するNetBeans Platformベースのデスクトップアプリで
JDK6を使ってみる。「WindowsVistaに対応してます」の一言で
クライアントのOKが出た。JDK6でなければならない理由はないんだけど、
何より俺が使ってみたいのだ。
147 名前：デフォルトの名無しさん mailto:sage [2006/12/16(土) 01:00:31 ]: おめでとうｗ
148 名前：デフォルトの名無しさん mailto:sage [2006/12/16(土) 20:31:10 ]: >145

同意
149 名前：デフォルトの名無しさん mailto:sage [2006/12/16(土) 22:13:48 ]: 別にここでするレスじゃないかも知れんが
共用体が欲しいなあとなんとなしに思ってたけど
nioのByteBufferが既にそれっぽいことに今更気づいた。
150 名前：デフォルトの名無しさん mailto:sage [2006/12/16(土) 23:59:17 ]: >>146
デスクトップアプリで６を使うのはいいと思うけど、EclipseRCPにしてもNetBeansPlatformにしても
へんなのをかますと余計にめんどくさいだけだと思うんだが
重くなりやすいし、バグがあったとしても回避しにくい

普通にSwingベースのほうが開発効率がいい
まぁNetBeansPlatformはSwingベースで開発できる分まだ楽か
151 名前：デフォルトの名無しさん mailto:sage [2006/12/17(日) 00:01:20 ]: 150が何いってんのか誰か教えて。
152 名前：デフォルトの名無しさん [2006/12/17(日) 00:23:59 ]: 君にはまだ早い
153 名前：デフォルトの名無しさん [2006/12/17(日) 00:28:01 ]: 今度こそ本当にJavaでデスクトップアプリ開発が流行るんですかね？
154 名前：デフォルトの名無しさん mailto:sage [2006/12/17(日) 00:31:35 ]: 流行るってかモチベーションの問題だろ
5.0で既に十分なポテンシャル持ってたのに作らなかった。
事実やる気全開のV2Cは今や非Win用2chブラウザの重鎮だし。
155 名前：デフォルトの名無しさん mailto:sage [2006/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 名前：デフォルトの名無しさん mailto:sage [2006/12/17(日) 00:38:22 ]: >>154
V2Cいいんだけど参照のこったままになるの改善してほしいな
ひとつも開いてなくてもあきメモリーがなしってひどす
157 名前：デフォルトの名無しさん mailto:sage [2006/12/17(日) 00:59:46 ]: >>155
RowSetって使ってるとこあるの？
JDBC4.0は何故かRowSetに肩入れしてるけど
JPAとレイヤーも被ってると思うんだよなぁ
158 名前：デフォルトの名無しさん mailto:sage [2006/12/17(日) 01:08:15 ]: >>132
あくまで提案か。
実装するにはヤバイのが多いな。
BigDecimalの演算子だが
divide使うとき、MathContextの値はどうするのだろうか。
二つのBigDecimalオブジェクトのMathContextの値が異なれば
誤差が片方のMathContextの制度を基準にして除算を
することになると思うが、そうしたくない場合には
結局BigDecimal#divide(BigDecimal, MathContext)を使うことになるんだろうな。

その辺り、どう解決するのだろうか。
159 名前：デフォルトの名無しさん mailto:sage [2006/12/17(日) 01:18:13 ]: とはいえ、いまだに大量に要る浮動小数点を金額計算に使うやつらをとめれるのは大きいか

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

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

こんなのが業務プログラム経験10年とかでベテランですといってごろごろいるんだが
そのたびにぶちきれてる俺はいやなやつと思われてるっぽい
160 名前：デフォルトの名無しさん mailto:sage [2006/12/17(日) 01:20:41 ]: その手の奴はダメ出ししまくって修正させると「さすが大先生」とか卑屈になるんだよな
正直どうにかして首に追い込めないかとか考えてしまう。
161 名前：デフォルトの名無しさん [2006/12/17(日) 01:23:39 ]: javaのジェネリクスのしょぼさがなぁ。
C++のテンプレートと同じことが出来なきゃ先は無いだろ。
162 名前：デフォルトの名無しさん mailto:sage [2006/12/17(日) 01:29:11 ]: >>160
今のところ5.0導入してから半分くらいはついていけないのを確認

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

>>161
目的が違うんだからいいんじゃね？C++と同じだったら逆にぶちきれるだろ
163 名前：デフォルトの名無しさん mailto:sage [2006/12/17(日) 01:31:31 ]: Javaにboostみたいなのが出てくるのも考えモノだな。
164 名前：デフォルトの名無しさん mailto:sage [2006/12/17(日) 01:32:22 ]: templateが害悪だからGenericsになったわけだが。
165 名前：デフォルトの名無しさん mailto:sage [2006/12/17(日) 01:33:10 ]: >>159
BigDecimal,BigInteger用のシンタックスシュガーが導入されれば何とかならんかね・・・
しかし・・・・丸めとかの規定ないの？仕様に。
166 名前：デフォルトの名無しさん mailto:sage [2006/12/17(日) 01:40:34 ]: 123.45B とか 999999B で型推論？精度が違う場合は警告とし、左のほうに合わせる。
167 名前：デフォルトの名無しさん mailto:sage [2006/12/17(日) 02:10:27 ]: >>164
ジェネリクスが今の形になってるのはただ単純に互換性を保つためだけの理由からだよ。
だいたいタイプパラメーターにnew出来ないってありえねーよ。
168 名前：デフォルトの名無しさん mailto:sage [2006/12/17(日) 02:17:31 ]: ありえるからJavaは普通に普及してるんだけど。
169 名前：デフォルトの名無しさん mailto:sage [2006/12/17(日) 02:34:32 ]: >>167
無制限に型パラメータで new するのは C# でもできないし。
170 名前：デフォルトの名無しさん mailto:sage [2006/12/17(日) 02:37:58 ]: 防御的コピーしたい場合を考えるとコピーコンストラクタくらいは使えてもよかったかな。
171 名前：デフォルトの名無しさん mailto:sage [2006/12/17(日) 02:45:01 ]: >>170
つ「スペルミスなんだけど、気付いた時には既に修正不能だったという逸話が有名な Cloneable」
172 名前：デフォルトの名無しさん mailto:sage [2006/12/17(日) 03:03:58 ]: でもスペルミスが指摘されたのはβ時代。
何が遅すぎるのやら。
173 名前：デフォルトの名無しさん mailto:sage [2006/12/17(日) 03:05:23 ]: あ、これのことね。
bugs.sun.com/bugdatabase/view_bug.do?bug_id=1234712
174 名前：デフォルトの名無しさん mailto:sage [2006/12/17(日) 03:25:14 ]: >>167
互換性が大事だと一番分かっているのはC++だろｗ
175 名前：デフォルトの名無しさん mailto:sage [2006/12/17(日) 03:39:45 ]: creat・・・・
176 名前：デフォルトの名無しさん mailto:sage [2006/12/17(日) 12:05:10 ]: 近い未来・・・、JavaがJavaでなくなる日が訪れる。
177 名前：デフォルトの名無しさん mailto:sage [2006/12/17(日) 12:19:03 ]: >>139
5.0で浸透している。
やはりGenericsとアノテーションは重宝する。
JUnitもアノテーションに対応したことだし。
Generics
>>141
178 名前：デフォルトの名無しさん mailto:sage [2006/12/17(日) 17:28:19 ]: >>156
うちのV2Cはなったことないな。
ヒープサイズの問題でないなら本スレにバグレポした方がいい。
179 名前：デフォルトの名無しさん [2006/12/17(日) 18:40:37 ]: DolphinといえばSwing Application Frameworkが気になる。
ttp://developers.sun.com/learning/javaoneonline/2006/desktop/TS-3399.pdf
180 名前：デフォルトの名無しさん mailto:sage [2006/12/18(月) 00:30:49 ]: >>155
> リッチクライアント用途ではすでに普及してると思うが、クライアントサーバのように2層式が
> まだ弱いのが今後大幅に改善されるかもしれない

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

StrutsやJSFがSwingと合体すれば使いやすいのだが。
181 名前：デフォルトの名無しさん mailto:sage [2006/12/18(月) 00:40:29 ]: いや、ふつうに2層式だからクライアントとDBとの接続
RMIでもWebServiceでもいいけどそれらのもってきた値とコンポーネントとの関連付けが今は手動になっちまう

＞StrutsやJSFがSwingと合体すれば使いやすいのだが。
これはありえないだろ
前2つよりSwingのほうが圧倒的に使いやすいし
182 名前：デフォルトの名無しさん mailto:sage [2006/12/18(月) 00:46:12 ]: JSFのSwing化はJSF登場時からすでに検討課題だから。
てかSwingコンポーネントひとつひとつが<input>タグ化すればいいだけの気もする。
バリデータとコンバータがフレームワーク毎にあることのがメンドイ？
183 名前：デフォルトの名無しさん mailto:sage [2006/12/18(月) 00:52:02 ]: 各種イベントがどうしようもねぇな、WEBページベースだと
184 名前：デフォルトの名無しさん mailto:sage [2006/12/18(月) 01:19:56 ]: >>159
> とはいえ、いまだに大量に要る浮動小数点を金額計算に使うやつらをとめれるのは大きいか
> だってnewするの面倒だもんと聞いたときには何の冗談かと

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

にしてもBigDecimal.valueOf(String) 欲しいモノだ。
185 名前：デフォルトの名無しさん mailto:sage [2006/12/18(月) 01:21:54 ]: ValueOfableの出番だな
186 名前：デフォルトの名無しさん mailto:sage [2006/12/18(月) 01:23:03 ]: >>181
> 前2つよりSwingのほうが圧倒的に使いやすいし

Swingだと、
HTMLやXSL + XMLで書かれたページと連携するのが
不便なのだが。
187 名前：デフォルトの名無しさん mailto:sage [2006/12/18(月) 01:24:17 ]: JSF, Struts, tapestry, Seasar2 + Ajax

これをSwingと連携する方法が・・
188 名前：デフォルトの名無しさん mailto:sage [2006/12/18(月) 01:25:15 ]: レスポンスで必要なのはXMLだけだろ。
Webフレームワーク側がXML+XSLTに移行すれば皆幸せ。
189 名前：デフォルトの名無しさん mailto:sage [2006/12/18(月) 01:53:43 ]: >>188
そういうこと
通信自体はJAXB/JAX-WSが6からクライアントに来たことによってかなりよくなった
後はそのバインドされたコンポーネントだけ
190 名前：デフォルトの名無しさん [2006/12/18(月) 03:07:51 ]: Strutsはどうでもいいけど、JSFみたいに画面遷移を管理する仕組みがSwingにも欲しい。
Visual Web Packの画面遷移エディタみたいにSwingでも画面遷移管理。
191 名前：デフォルトの名無しさん mailto:sage [2006/12/18(月) 18:16:52 ]: さすがのJavaも98/Me非対応になったかｗ
192 名前：デフォルトの名無しさん mailto:sage [2006/12/18(月) 22:38:49 ]: VRAMとかもついてけないんだろうか。
そういやMMOするのも一苦労だったな、あの頃は。
193 名前：デフォルトの名無しさん mailto:sage [2006/12/19(火) 23:55:07 ]: >>190
このボタンをおしたら２つフレームを出して、ボタンの乗っているカードレイアウトのページを切り替えて・・・とか
そういうのもあるからページベースで考えるというのは無理がある

それに画面遷移の一元管理なんてべつにむずかしくはないだろ
194 名前：デフォルトの名無しさん mailto:sage [2006/12/20(水) 08:39:04 ]: >>193
JSFのページ遷移でいいんだよ。
画面遷移エディタで俯瞰で見れるのが欲しい。
195 名前：デフォルトの名無しさん mailto:sage [2006/12/20(水) 20:54:04 ]: 最近思うんだがMSの.Netでいいんじゃないかと。
Java EE + ウェブコンテナ + ジャカルタ + オープンソース系の技術
これらの寄せ集めもいいが、この統一感が無い感じこれらの技術よりと
結局は同等のことが出来るMSで統一するのが一番楽に思えてきたんだよ…

若いっていいよな…
196 名前：デフォルトの名無しさん mailto:sage [2006/12/20(水) 20:57:11 ]: >>195
今はＰＣサーバの能力あがったから大丈夫かもしれんが、ちょいと前まではスケーラビリティの問題がでかかったんだよね
197 名前：デフォルトの名無しさん mailto:sage [2006/12/20(水) 22:34:55 ]: >>195
Java EEのJSF+EJB3でだいたいいけるよ。
198 名前：デフォルトの名無しさん mailto:sage [2006/12/20(水) 23:31:45 ]: >>195氏のためにNetBeans Visual Web Packを試してみるか。
199 名前：デフォルトの名無しさん [2006/12/21(木) 00:21:31 ]: >>199
JSCとほぼ同じだが、いい感じで統一感がでてると思うね。
200 名前：デフォルトの名無しさん [2006/12/21(木) 00:34:44 ]: >>195
俺も昔そう感じていた時期もあったが、
バージョンアップによる互換性のなさに嫌気がして、
その世界から抜け出した。
いまでも.NETで互換性の問題が出ているようだし
判断は間違ってなかったと思ってる。
もちろん、100%PureMSの生み出すパワーは魅力的なのは否定しないがね。
201 名前：デフォルトの名無しさん mailto:sage [2006/12/21(木) 00:37:14 ]: 仕事で使うのが未だに1.4だらけな件…
202 名前：198 mailto:sage [2006/12/21(木) 01:07:05 ]: うん、画面遷移も楽そうだった。SessionBean1とか作られてるんだがTomcatだけで動いてるのが何か不安ｗ
203 名前：デフォルトの名無しさん mailto:sage [2006/12/21(木) 07:25:51 ]: Javaが良いのは、MSの（API解説）文章よりも
SUNの文章の方が優れていたからじゃないかと思ってる。
Java周辺（SUN/IBM周辺）の技術文章（や本）で統一感があれば
MSのサービスなんか目じゃなくなるんだろうな…
204 名前：デフォルトの名無しさん mailto:sage [2006/12/21(木) 07:29:48 ]: 技術の相互互換性の問題とバージョンアップの後方互換性の問題のようだね。
足腰が不安定なオープン形の技術よりも、長期間手厚くサポートされ最後まで存続する
技術（ソフト・サービス）はMSの方だと思う。
だけど、現状で融通が利くのは>>195の指摘する限りだ。
205 名前：デフォルトの名無しさん mailto:sage [2006/12/21(木) 09:19:40 ]: 昔は「MS」という名前を見ただけで発狂するJava使いが多かったが、冷静に語れる時代になったんだなあ。
206 名前：デフォルトの名無しさん mailto:sage [2006/12/21(木) 11:26:19 ]: >>205
そんな奴はJava界にとっても害悪でしかないからなあ。消えてもらって結構。
思う存分Googleでもマンセーしてればいい。
207 名前：デフォルトの名無しさん [2006/12/21(木) 11:34:31 ]: >>204
そうかなぁ？
MSも技術的には不安定だと思うね。
元VB使いなんだが、2.0から使ってて、バージョンアップの度に、移植に手間がかかったり、
クライアントの環境によっては動かない事があるなど、
いい思い出はない。
208 名前：デフォルトの名無しさん [2006/12/21(木) 11:41:42 ]: >>205
元々MS嫌いな奴らがいて、
彼らがJavaに飛びついただけ。
単純に言語的な魅力を感じて、Java使いになった人もいるわけで。
今は後者が増えたのだろう。
209 名前：デフォルトの名無しさん mailto:sage [2006/12/21(木) 12:03:45 ]: >>195
それが統一感がないと感じるのか。

それならJakarta を外してSun純正にすれば？
210 名前：デフォルトの名無しさん mailto:sage [2006/12/21(木) 13:45:21 ]: 色々な開発方法が利用できることが良いとみるか悪いとみるかだな。

ASP.NETは型にはまれば楽チンだが、ちょっと型から外れることを行うときは、
一から自分でお膳立てしないといけなくて面倒なこともあるよ。
211 名前：デフォルトの名無しさん mailto:sage [2006/12/21(木) 19:23:28 ]: >>209
そういうことじゃないと思うよ。
212 名前：デフォルトの名無しさん mailto:sage [2006/12/21(木) 19:26:00 ]: >>210
そういうのところ（ニッチ市場ともいうか）以外は全部MSになってしまうってことなんだね。
Javaの出番は結局大規模上層のところなのかなぁ
213 名前：デフォルトの名無しさん mailto:sage [2006/12/21(木) 20:17:53 ]: >>212
どうしてそういうレスになるんだ？
日本語理解できてる？
214 名前：デフォルトの名無しさん mailto:sage [2006/12/21(木) 23:07:37 ]: Railsの興隆とかも、結局MSが作ってきたオールインワンなプロダクトの
フリー版が出てきたよ！ってだけの意味しかないと思うんだが、
何であんなにみんな寄ってたかってあがめたてるのか謎だわ。

まぁ、Rubyの言語的に優れたところを認めるのにはやぶさかではないが。
215 名前：デフォルトの名無しさん mailto:sage [2006/12/21(木) 23:13:36 ]: Railsの場合は宣伝パワーかねぇ。
216 名前：デフォルトの名無しさん mailto:sage [2006/12/21(木) 23:34:21 ]: JavaDocは中々優れたツールなんだけど
皆あんまり真面目に書かないんだよな

事前条件の提示とかフェイルファストとかスレッドセーフとか
確かにSunのドキュメントは細かく書かれてて戸惑いが少ない。
驚き最小限の法則に基づけばこの姿勢は大切。
217 名前：デフォルトの名無しさん mailto:sage [2006/12/22(金) 02:31:53 ]: Macが売れ出してWindowsあぼーんでJavaが大活躍。
そんな未来が、君には見えないのか？
218 名前：デフォルトの名無しさん mailto:sage [2006/12/22(金) 05:17:12 ]: それをいったらRubyにも同じ未来が！
Javaは、Macでデスクトップでの可能性が見れたという部分は大有りだがな。

GPL化されたJVMをプレインストールしてPC売り出す勇気のある会社はねえんかね
219 名前：デフォルトの名無しさん mailto:sage [2006/12/22(金) 13:18:36 ]: GPL化されてなくてもプリインストールされてるけど、なんか問題あるか？
220 名前：デフォルトの名無しさん mailto:sage [2006/12/22(金) 15:17:14 ]: >>216
自分はちゃんとjavadocコメント入れてるよ、というかうちのチームは入れないと深夜に呼ばれて質問されても文句言えないって教わってきたからだけど。
221 名前：デフォルトの名無しさん mailto:sage [2006/12/22(金) 15:19:58 ]: >>220
いいチームだな
ドキュメントコメントいれておけば補完時に説明出るしね
別途用意したドキュメントとは別次元

publicなメソッド等にはドキュメントコメントがないとコンパイルエラーでてもいいと思うんだ
222 名前：デフォルトの名無しさん mailto:sage [2006/12/22(金) 16:26:51 ]: >>216
書いてるよ。Eclipseのプラグインを
使わないと真面目に書く気起きないだろうけど
223 名前：デフォルトの名無しさん mailto:sage [2006/12/22(金) 19:35:11 ]: >>216
書いてるよ。
でも中国人の中国語が文字化けしてるよ。
224 名前：デフォルトの名無しさん mailto:sage [2006/12/22(金) 22:18:32 ]: Sun の中の人のブログ
blogs.sun.com/ahe/entry/java_se_7_wish_list
で、言語拡張のリストっぽいのが出てる。
closure のリンク先見るに、>>132 よりはこっちのが新しいっぽい？

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

ついでに、closure の最新っぽい草案
www.javac.info/closures-v04.html

もひとつついでに、>>135 で触れてる gosling案とかを実装してみたらしい。
weblogs.java.net/blog/forax/archive/2006/12/call_me_santa.html
225 名前：デフォルトの名無しさん [2006/12/23(土) 20:35:14 ]: 型推論は個人的にちょっとまった！だな。
変数のスコープが分かりにくくなる形での推論は特に。

var型とかを用意して必ず有効な参照で
初期化しなければならないくらいのルールは欲しい。
可読性対策に問題が出るくらいなら冗長なGenericsのままのがいいす。
226 名前：デフォルトの名無しさん mailto:sage [2006/12/23(土) 20:45:53 ]: IDEが自動補完してくれたほうがいいな。
227 名前：デフォルトの名無しさん mailto:sage [2006/12/23(土) 20:54:26 ]: > 変数のスコープが分かりにくくなる形での推論は特に
って具体的にどーゆー事かわからん。
228 名前：デフォルトの名無しさん mailto:sage [2006/12/23(土) 21:05:19 ]: スクリプト言語みたいに
始めてその名称が使用されたタイミングで
参照型が作られるのはアカンということ。
229 名前：デフォルトの名無しさん mailto:sage [2006/12/23(土) 21:22:49 ]: >>224 にある奴とかは、単に変数宣言のシンタックスシュガーなだけでしょ。
スコープがわかりにくくなるんかな？
230 名前：デフォルトの名無しさん mailto:sage [2006/12/23(土) 21:29:19 ]: メソッドの頭から眺めるなら大したことじゃないが
スタックトレースからコード追うときはイラっとくるかも
231 名前：デフォルトの名無しさん mailto:sage [2006/12/23(土) 21:59:35 ]: スコープが混乱するのって
weblogs.java.net/blog/forax/archive/2006/12/call_me_santa.html
の for ループの中で algol構文のシンタックスシュガー使ってる時だけだと思うが。
後は final が付いてたり := があるから変数宣言してんのわかるし。
232 名前：デフォルトの名無しさん mailto:sage [2006/12/25(月) 18:39:39 ]: Concurrent API便利なのに使ってる人少なすぎ
233 名前：デフォルトの名無しさん mailto:sage [2006/12/25(月) 23:23:49 ]: >>232
話題にならないのはすでに2年以上も前の話だからだろ？
234 名前：デフォルトの名無しさん mailto:sage [2006/12/26(火) 16:42:28 ]: マルチスレッドでプログラムしてる人が少ないんだろうな
そしてプログラムで使える人はわかってる人。

というか、次世代じゃなくて現世代だよな。
235 名前：デフォルトの名無しさん mailto:sage [2006/12/26(火) 21:00:24 ]: Webアプリだとコンテナとフレームワークの上でガシガシ組むから基本スレッドは意識しないな。
236 名前：デフォルトの名無しさん mailto:sage [2006/12/26(火) 21:15:30 ]: Concurrent APIとかフレームワーク作る人が使うもので
フレームワーク使う人が使うものじゃないな
237 名前：デフォルトの名無しさん mailto:sage [2006/12/26(火) 22:59:07 ]: >>234
前世代だろ？
238 名前：デフォルトの名無しさん mailto:sage [2006/12/26(火) 23:33:19 ]: >>235
こんな、やつがwebアプリ作るからwebアプリって全般的に品質低いんだよ。

たとえば、J2EEは、基本マルチスレッドモデルだからインスタンス変数なんか定義して
リクエストの情報を設定したりなんかすると平気で他人の状態に書き換わったりする。。

strutsみたいなフレームワークを使ってても同様↓

ActionのJavadocより引用
------
リクエストの状態に関連する情報を保持するためにインスタンス変数やスタティック変数を使用してはいけません。
インスタンス変数やスタティック変数は同一のアクションに関してリクエストをまたがってグローバルなリソースを共有したい場合に使用します。
239 名前：238 mailto:sage [2006/12/26(火) 23:42:30 ]: もっと詳しい解説があった。
とにかく、webだからスレッドなんて関係ないぜ。ってのは、よしてくれ。

www.atmarkit.co.jp/fjava/rensai2/webopt04/webopt04.html
240 名前：デフォルトの名無しさん mailto:sage [2006/12/27(水) 00:06:25 ]: >>232
日本語のサンプルすくないじゃん。
サンプルがないとコードがかけないと思う。
241 名前：デフォルトの名無しさん mailto:sage [2006/12/27(水) 01:19:41 ]: >>238
WEBアプリだと自分で明示的にスレッド作ることは
あまり無いっちゅうことじゃないの？

さすがにそのレベルの間違いをする人はそんなにいない・・・
と言いたいところだが、ちらほら見かけた。
StrutsのActionクラスとかにインスタンス変数書きまくって
「テスト通る時と通らない時があります！
　FWのバグじゃないですか？」
とかこいてて、いますぐ死ねってまじで思った。
242 名前：デフォルトの名無しさん mailto:sage [2006/12/27(水) 05:10:02 ]: 何のためにセッションやらリクエストパラメータがあるのかと小一時間>>Webアプリのへたれプログラマ
243 名前：デフォルトの名無しさん mailto:sage [2006/12/27(水) 05:17:26 ]: >>241
いやいや、マルチスレッドなのにオブジェクトを使い回すような設計になっているのが悪いんじゃないか。
いまやオブジェクト生成・破棄のコストはそんなに重大ではないんだから、
もっと素直にプログラムできるようなモデルにすべきだった。
244 名前：デフォルトの名無しさん mailto:sage [2006/12/27(水) 08:12:03 ]: >>243
設定でシングルスレッドモデルって言ってシングルスレッドで動作させる
ようにもできる。
その上でフレームワークを使うって言ったら結構なメモリを使うであろうことが
容易に想像できるわけだが。
245 名前：デフォルトの名無しさん mailto:sage [2006/12/27(水) 12:32:11 ]: もうシングルスレッドモデルはねーぞ
それにインスタンスも複数使われるかもしれないし、ひとつかもしれないという自由度だったはず
Tomcatはひとつだったはずだけど

スレッドプーリングしてるんだよとか基本を教えないでこのメソッドのみで適当に作っといてとしかいわないのも悪い
246 名前：デフォルトの名無しさん mailto:sage [2006/12/27(水) 14:22:28 ]: 結構なメモリってどんな処理だ？
247 名前：デフォルトの名無しさん mailto:sage [2006/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 名前：デフォルトの名無しさん mailto:sage [2006/12/28(木) 08:31:24 ]: >>247
言語仕様的にはできなくは無いだろうけど、JVMレベルでの互換性を
壊すから、まず入ることは無いだろうな。あと、従来の配列はcovariantだが
genericsはcovariantじゃないというのもある
249 名前：デフォルトの名無しさん mailto:sage [2006/12/28(木) 11:17:30 ]: >>247
配列じゃないけど indexer っぽいのは >>224 の wish list に入ってたけど。
250 名前：デフォルトの名無しさん mailto:sage [2006/12/28(木) 23:45:13 ]: >>247
ここのArray Syntax for Collectionsがあればいいんじゃない？
blogs.sun.com/ahe/entry/java_se_7_wish_list
251 名前：250 mailto:sage [2006/12/28(木) 23:46:00 ]: あ、249が言ってるのと同じだった。
252 名前：247 mailto:sage [2006/12/29(金) 00:47:46 ]: 構文のサポートも欲しいところなんですが、
配列を抽象化できるのも魅力かなと。
でもcovariantが・・・なるほどね。。。

BigDecimalの四則演算対応も、できれば何かの特定のインターフェイスを
実装していれば対応できるというのが希望。
それって何て演算子オーバーロード？って言われそうですが・・・
253 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 01:36:56 ]: ArrayList<Integer> list = {12, 34, 56};
みたいな初期化ができれば、配列の抽象化にこだわる必要はまったくなくなると思う。
コレクションのための配列構文も、[]のオーバーロードみたいなもんだし。
254 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 01:44:57 ]: 型推論っていうんだっけ？

List<Integer> list = {12,34,56};
は、コンパイルエラー？
255 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 03:26:09 ]: デフォルトをつけるかどうかだよね。
自分は、それはコンパイルエラーでいいと思う。
256 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 03:28:09 ]: 要するにこんな感じのが欲しい。
d.hatena.ne.jp/nowokay/20061218
257 名前：デフォルトの名無しさん mailto:sage [2006/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 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 10:23:29 ]: > More factory methods for colllection classes
問題は Map の factory method だよな、と思う。
259 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 10:32:38 ]: List<Integer> list = Arrays.asList(1, 2, 3);
260 名前：235 mailto:sage [2006/12/29(金) 12:00:42 ]: >>238
インスタンス使い回すっていうコンテナの構造上の問題は普通に意識するだろ。
マルチスレッド以前の問題だ。

Webアプリでスレッドを用いる必要があるのはデータのインポート＆エクスポートぐらいだと思う。
重い処理をする間、ユーザーを待たせないっつー意味で。
261 名前：デフォルトの名無しさん mailto:sage [2006/12/30(土) 13:25:27 ]: java.ioとnioの親和性をもうちょっと頑張って欲しいな
262 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 02:02:39 ]: 親和性って具体的には？
263 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 02:41:17 ]: Channelはデコレートパターン向きじゃないからね
Buffered*StreamみたいなのBuffer版アダプタを
標準で用意してくれるだけでも嬉しい
264 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 02:52:32 ]: ああ、しかし、BufferedとByteBufferだと名前が似すぎて間違えるか
265 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 10:56:51 ]: >>263
BufferedChannel みたいなものが欲しいって事？
ByteBuffer.wrap(new byte[1]); みたいな小さい ByteBuffer 作って
ちょこまか読み書きしてないなら大して必要とも思わないけど。

ってか、java.ioとの親和性とか関係ないような。
266 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 12:14:45 ]: ByteBufferInputStreamとかStream側にあわせるアダプタだろ
267 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 13:16:45 ]: > ByteBufferInputStream
要るか？
268 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 13:34:33 ]: >>267
それが欲しければアプリの中で用意すれば？
ってレベルの需要だろうなぁ
269 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 13:34:34 ]: 場面によりけり。ダイレクトバッファ使ってる場合なら欲しい。
270 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 13:51:22 ]: writeToメソッドみたいなのがBufferに欲しい
271 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 14:46:16 ]: >>269
ダイレクトバッファ使ってても、
InputStream や OutputStream のデコレータだったらアドバンテージないんじゃ？
272 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 14:48:28 ]: >>270
ByteBuffer#get(byte[]) とかあるけど。
273 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 14:50:18 ]: >>272
それを言うなら ByteBuffer#put(byte[]) じゃないかと。
274 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 14:52:27 ]: マップファイルを外部にゲロるのに便利そう writeTo
275 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 14:55:19 ]: >>271
コンポーネント単位で見ればそれもありでは？
nioのが効率はいいんだから、
最適化が必要になった時にnioにあわせていけばいい。
276 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 14:56:41 ]: 便利に使いたいだけなら
NIOUtils.writeTo(WritableByteChannel, ByteBuffer)
みたいなユーティリティメソッドつくっときゃ良いだけのような。
277 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 15:01:08 ]: >>275
いや、単純に無駄だよねって話。

中途半端にやるとクラスが汚くなるだけだし。
最適化が必要になりそうならアプリ側で入出力処理を抽象化しておきゃ良いんだし。
278 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 15:06:00 ]: >>277
内部で Channel 使った ChannelInputStream とか ChannelOutputStream で最適化する時
read(ByteBuffer) とか write(ByteBuffer) があると便利なんだよ！

すげーアホ臭いな。そんだったら最初から Channel 使えば良いし。
279 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 15:07:05 ]: > NIOUtils.writeTo(WritableByteChannel, ByteBuffer)
要るか？
280 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 15:07:07 ]: ん？Servletにnioを適用するための記事とか普通に出回ってるが
281 名前：デフォルトの名無しさん [2007/01/05(金) 02:17:08 ]: 6.0でCommons Modelerを使用してPOJOを登録したんだがjconsoleのmbeanタグ
で表示されないのは既出ですか？
282 名前：デフォルトの名無しさん mailto:sage [2007/01/10(水) 21:20:03 ]: DOMとコレクションフレームワークの親和性をあげてほしいなぁ。
283 名前：デフォルトの名無しさん mailto:sage [2007/01/11(木) 01:52:34 ]: Closure の人(?) が面白いアイデアを書いてる。
gafter.blogspot.com/2007/01/methodnamesinpieces.html

なんか、javac弄って遊ぶプロジェクトらしい？
https://ksl.dev.java.net/
blogs.sun.com/ahe/entry/ksl_answers

>>224 の一番最後の人が property を試しに実装してみたらしい。
weblogs.java.net/blog/forax/archive/2007/01/a_property_prop_1.html

protperty 慎重派の人も居るらしい。
weblogs.java.net/blog/hansmuller/archive/2007/01/property_syntax.html

アプリ書く人と、ライブラリ（Swingコンポーネントとか）書く人の違いなんだろか？
284 名前：デフォルトの名無しさん mailto:sage [2007/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 名前：デフォルトの名無しさん mailto:sage [2007/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 名前：デフォルトの名無しさん mailto:sage [2007/01/11(木) 20:22:31 ]: > フィールド指定を可能にすることで無駄なsetter,getterの記述が不要になることが
でも、これって 5文字ぐらい節約できるってだけなんだよねぇ……
287 名前：デフォルトの名無しさん mailto:sage [2007/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 名前：デフォルトの名無しさん mailto:sage [2007/01/11(木) 22:43:37 ]: >>287
その辺はどー転ぶかわかんない。property 自体却下される可能性もあるし。
とりあえず >>283 のプロトタイプだとできない。

> property int x read fieldX write setX;
この構文だと、Java ではフィールド名と同じメソッド名付けられるから
fieldX って名前のフィールドに加えてメソッドまであったらどーすんだろ、とか
setX 以外の名前が指定できると、現在既にあって setX を期待してる
フレームワークが困りそうだなぁ、と思った。
289 名前：デフォルトの名無しさん mailto:sage [2007/01/12(金) 23:43:12 ]: jcp.org/en/participation/members/E
Eclipse FoundationがJCPメンバーとして参加することに
なったらしい。ちょっと前にEclipse代表のMike Milinkovichが
JSR277とJSR291の進行に激怒してたからなんかやるだろうなとは思ってたけど。
JSR291に反対票投じたRedhatも先月推進派に転じたみたいだし、さらに今度の
Eclipseの票も加えて1/16～22にあるJSR291の投票をのりきりたいんだろうね。
290 名前：デフォルトの名無しさん mailto:sage [2007/01/16(火) 01:46:34 ]: >>287
setXxx、getXxxっていうのをプロパティとみなす仕様は変えれないと思うよ。
IDEのプロパティエディタやらJSPのELやら、既存のツールやライブラリが使えなくなる。
291 名前：デフォルトの名無しさん mailto:sage [2007/01/16(火) 05:09:43 ]: Java6の話はどこですればいいのかな？
292 名前：デフォルトの名無しさん mailto:sage [2007/01/16(火) 19:56:31 ]: >>291
現世代Javaの動向 1
pc10.2ch.net/test/read.cgi/tech/1150286189/l50
293 名前：デフォルトの名無しさん mailto:age [2007/01/18(木) 08:02:25 ]: AjaxでハイブリッドP2P型を作成しようと思っているのですが、
これを作るにはJ2SE,J2EE,J2MEの内、どれが相応しいのでしょうか？
次世代Javaに詳しい方教えて下さい。
294 名前：デフォルトの名無しさん [2007/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 名前：デフォルトの名無しさん mailto:sage [2007/01/18(木) 19:15:17 ]: >>293
構成が今一良く分からない。Webサーバ＋P2PでUIがブラウザなわけかい？
J2EEのServlet（Jettyあたり）を落としてきて、残りはSEでガリガリ書きなさいな。
296 名前：293 mailto:sage [2007/01/19(金) 07:57:58 ]: >>295
P2Pでコミュニティとファイル共有システムを作って、ソフトウェアで提供しようとしているので、
中継ノードでピュアP2P型にするか、中央サーバーでハイブリッドP2P型にするかのどっちかになるのですが、
それぞれJ2SE,J2EE,J2MEのうち、何が相応しいのでしょうか？
教えて下さいませ。
297 名前：デフォルトの名無しさん mailto:sage [2007/01/19(金) 10:32:49 ]: >>296
まず、J2SE,J2EE,J2MEが何かぐらいは調べて置いたほうがいいだろ。
それとスレ違い。
298 名前：デフォルトの名無しさん mailto:sage [2007/01/19(金) 15:30:45 ]: JDK7 build06
download.java.net/jdk7/changes/jdk7-b06.html
download.java.net/jdk7/binaries/

個人的にはまだぱっとした新機能ないなぁ
299 名前：デフォルトの名無しさん mailto:sage [2007/01/19(金) 20:33:11 ]: Java6の役目はその機能ではなく、1.4.2を古いものとし、
Generics環境へのGOサインを導き出してくれることにある。
Java7もXML構文とか登場してまた汚れる（ｗ）から
Java7のデビューはJava8のリリースからとなる。
300 名前：デフォルトの名無しさん mailto:sage [2007/01/19(金) 23:12:57 ]: Genericは結構なんだけど旧形式のコレクションも@deprecatedにしないで
共存させといて問題ないと思うのだが。これのせいで１．４からの移行が進みにくい。
301 名前：デフォルトの名無しさん mailto:sage [2007/01/19(金) 23:15:09 ]: 5.1が出ないってことは、最近のJREはアーキの急遽対応がないんだな。
6は載らなかった機能が一杯あるから枝が付くとなんとなく思ってるが
302 名前：デフォルトの名無しさん mailto:sage [2007/01/20(土) 01:27:40 ]: 6はおまけっぽいのがてんこもりだからね。
303 名前：デフォルトの名無しさん mailto:sage [2007/01/20(土) 01:29:35 ]: >>300
どういうこと？
304 名前：デフォルトの名無しさん mailto:sage [2007/01/20(土) 01:55:04 ]: 普通に「互換性あれば簡単に乗り換えれるのに」って意味じゃないの？
305 名前：デフォルトの名無しさん mailto:sage [2007/01/20(土) 02:22:19 ]: コレクションは互換性のために残されたレガシーコレクションとはあるが
非推奨だなんて注釈もdocタグも無いはずなんだが。
306 名前：デフォルトの名無しさん mailto:sage [2007/01/20(土) 02:28:02 ]: > 6は載らなかった機能が一杯あるから枝が付くとなんとなく思ってるが
1.5.1 とか 1.6.1 とか出さないって言ってなかったっけ？
307 名前：デフォルトの名無しさん mailto:sage [2007/01/20(土) 03:06:14 ]: ああこれのことね。無視すればいいけど、うちは何も考えずに<Object>つけてるぞイミねぇ

注: ArrayListDemo.java の操作は、未チェックまたは安全ではありません。
注: 詳細については、-Xlint:unchecked オプションを指定して再コンパイルしてください。
308 名前：デフォルトの名無しさん mailto:sage [2007/01/20(土) 03:17:36 ]: 無視したいなら@SuppressWarnings("unchecked")でいいじゃん
309 名前：デフォルトの名無しさん mailto:sage [2007/01/20(土) 06:46:59 ]: >>307
<?>の方がよくねぇ？
310 名前：デフォルトの名無しさん mailto:sage [2007/01/20(土) 13:18:36 ]: 例外にもジェネリクス対応して欲しいな。
型パラメータが付いたThrowableのサブクラスを作りたい。

例えば、
class IORuntimeException<IOException> extends RuntimeException{
}
のように定義して、
catch(IORuntimeException e){
throw e.getCause(); //<--IOExceptionをスロー
}
と使えると最高。
311 名前：デフォルトの名無しさん mailto:sage [2007/01/20(土) 15:38:32 ]: RuntimeExceptionが何故IOExceptionを投げるんだ・・・
312 名前：デフォルトの名無しさん mailto:sage [2007/01/20(土) 15:49:49 ]: IOExceptionをRuntimeExceptionでラップしたいんだろ。
313 名前：デフォルトの名無しさん mailto:sage [2007/01/20(土) 16:06:04 ]: >>310
Closure で例外を透過的に使うために、ってんで検討はされてるけど、
>>310 みたいな気持ち悪い奴じゃない。
314 名前：デフォルトの名無しさん mailto:sage [2007/01/20(土) 16:31:14 ]: Neal Gafter's blog
Thoughts about the future of the Java Programming Language.

ttp://gafter.blogspot.com/index.html
315 名前：310 mailto:sage [2007/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 名前：デフォルトの名無しさん mailto:sage [2007/01/21(日) 02:15:50 ]: > void piyo() throws WrapperException<T>
> }cathc(ExceptionWrapper<T> e){
……。

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

まぁ、ある意味では「色々面白そう」だけど。
317 名前：デフォルトの名無しさん mailto:sage [2007/01/21(日) 11:26:48 ]: >>300
問題ないはずだけど

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

>>309
明示的にするなら<Object>のほうがいいとおもう
ただ、これを使ってる時点でGenericsの恩恵ゼロだけどね
従来のライブラリ葉変更せずに使う場合>>308を接合部分につかってラッピングするべし
318 名前：デフォルトの名無しさん mailto:sage [2007/01/23(火) 10:31:36 ]: 突然だけど将来的にSEとEEにApache FOPも追加してくれんかな？

そうすると標準ライブラリだけでXML何でもあり状態で便利なんだが。

EEは需要ありそうだが・・・

ただでさえjdk6は標準ライブラリだけで近代的なブラウザが書ける奇抜な言語だぜｗ
319 名前：デフォルトの名無しさん mailto:sage [2007/01/23(火) 15:43:59 ]: 安藤幸央のランダウン[32]
Java SE 6へ移行する理由と移行をとどまる5つの理由
www.atmarkit.co.jp/fjava/column/andoh/andoh32.html
320 名前：デフォルトの名無しさん mailto:sage [2007/01/23(火) 18:04:30 ]: >>319
Itanium 1、2がサポートされなくなったのか。
Itanium おしまいだな。
321 名前：デフォルトの名無しさん mailto:sage [2007/01/23(火) 21:53:16 ]: >>319
なんか、細かいミスというか認識不足が多すぎる気がするよ。
Java SE 7は、もうDolphinとは呼ばれてないはずだし。
322 名前：デフォルトの名無しさん mailto:sage [2007/01/23(火) 21:59:45 ]: というか、JDKとJava2SE/JavaSEが混同されすぎ。
323 名前：デフォルトの名無しさん mailto:sage [2007/01/24(水) 18:06:01 ]: >>319
正式リリースされている 6系の話題は、現行スレでお願いします。
324 名前：デフォルトの名無しさん mailto:sage [2007/01/24(水) 19:59:04 ]: java.comがjre6を頒布するのはいつごろの予定なの？
325 名前：デフォルトの名無しさん mailto:sage [2007/02/02(金) 17:04:58 ]: JDK7 build07
download.java.net/jdk7/changes/jdk7-b07.html
download.java.net/jdk7/binaries/

やはりまだnew featureよりバグフィックスが目立つ
326 名前：デフォルトの名無しさん mailto:sage [2007/02/02(金) 18:15:15 ]: >>322
いまならJava SE

JDKは開発キットだからな(JREに対しての)
327 名前：デフォルトの名無しさん mailto:sage [2007/02/02(金) 18:16:33 ]: >>319
> 1.3.1以前のバージョンはEnd of Life、サポート終了の扱いです。

なるほど。古いことは気にしなくて良いとは
気が楽だ

法務省のJavaアプリが古いJVMに
しか対応していなかった問題も解決されると願う
328 名前：デフォルトの名無しさん mailto:sage [2007/02/02(金) 19:20:14 ]: 1.4も1.4.2までいったから多少長かったけど、今からだとサポート期間短いよね
2世代前のものだから当たり前だが
329 名前：デフォルトの名無しさん mailto:sage [2007/02/03(土) 08:40:58 ]: >>327
MOJ乙
330 名前：デフォルトの名無しさん mailto:sage [2007/02/08(木) 21:18:56 ]: Closures for the Java Programming Language (v0.5)
ttp://www.javac.info/closures-v05.html

{int,int=>int} plus = {int x, int y => x+y};

うーん、もすこしメソッドと同じような文法にならなかったのかな・・・
331 名前：デフォルトの名無しさん mailto:sage [2007/02/09(金) 02:06:03 ]: >>330
新しいのは
・nominal version が消えた。
・ユーザ定義のループ定義が草案入り。
ぐらいか。

より良い構文を考え付いたなら、
そっち方面の人のブログにでもコメントしとけば？
332 名前：デフォルトの名無しさん mailto:sage [2007/02/09(金) 02:06:58 ]: >>329
MOJ?

何それ？
333 名前：デフォルトの名無しさん mailto:sage [2007/02/09(金) 09:01:30 ]: ぐぐると一番最初にくる省庁の英語略称
そこの担当者
334 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 14:59:27 ]: Java++
335 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 20:39:31 ]: Java#
336 名前：デフォルトの名無しさん mailto:sage [2007/02/12(月) 01:18:02 ]: =>
ってどっかで見たことあるような
337 名前：デフォルトの名無しさん mailto:sage [2007/02/12(月) 03:26:06 ]: PerlやPHPのハッシュに使う演算子だろ。
338 名前：デフォルトの名無しさん mailto:sage [2007/02/12(月) 07:48:17 ]: Java2.0
339 名前：デフォルトの名無しさん mailto:sage [2007/02/12(月) 13:04:01 ]: >>338
それはもう古いぞ
340 名前：デフォルトの名無しさん mailto:sage [2007/02/12(月) 13:24:02 ]: JavaX
341 名前：デフォルトの名無しさん mailto:sage [2007/02/12(月) 13:42:03 ]: >>338-339
ﾜﾗﾀ
342 名前：デフォルトの名無しさん mailto:sage [2007/02/12(月) 14:25:37 ]: >>340
それはjavax.rmiみたいなパッケージとして存在するし

>>338
今はJava 6 の時代だろ
343 名前：デフォルトの名無しさん mailto:sage [2007/02/12(月) 14:33:13 ]: >>340
JBuilder Xを連想した。
344 名前：デフォルトの名無しさん mailto:sage [2007/02/12(月) 15:56:36 ]: JavaOSX？
345 名前：デフォルトの名無しさん mailto:sage [2007/02/12(月) 17:26:37 ]: Java Vista
346 名前：デフォルトの名無しさん mailto:sage [2007/02/12(月) 17:58:03 ]: JavaMillenniumEdition
347 名前：デフォルトの名無しさん mailto:sage [2007/02/12(月) 18:33:41 ]: Javaって、いつからOSになったんだ？
348 名前：デフォルトの名無しさん [2007/02/12(月) 18:34:34 ]: JNodeから
349 名前：デフォルトの名無しさん mailto:sage [2007/02/12(月) 18:35:56 ]: Japan Vistaと
Java MEみたいだ
350 名前：デフォルトの名無しさん mailto:sage [2007/02/12(月) 20:05:48 ]: JavaMX
351 名前：デフォルトの名無しさん mailto:sage [2007/02/12(月) 21:06:04 ]: JMXみてえじゃねえか
(Java Management Extension)
352 名前：デフォルトの名無しさん mailto:sage [2007/02/13(火) 05:36:14 ]: Java侍
353 名前：デフォルトの名無しさん [2007/02/13(火) 15:41:53 ]: ooの画面ってJavaみたいに見えるし、
実行はネイティブみたいだし、
あれはどういうテクノロジーなんでしょうか？
354 名前：デフォルトの名無しさん mailto:sage [2007/02/13(火) 23:17:23 ]: oo?OOoか？
eclipseもOOoもネイティブな実行ファイルはただのダブルクリッカブルじゃなかった？
355 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 01:53:19 ]: >>353
Swingのように自前でUIコントロールを描画しているのかねぇ？（謎
356 名前：353 mailto:sage [2007/02/14(水) 08:42:19 ]: ＞ネイティブな実行ファイルはただのダブルクリッカブル

ダブルクリッカブルって何ですか？

OOoはクロスGUIを使ってるからモッサリなんじゃないですか？？？
モッサリでも良いからクロスGUI欲しいお。
357 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 08:53:48 ]: ググレカス

api.openoffice.org/docs/DevelopersGuide/ProfUNO/ProfUNO.xhtml
358 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 10:40:15 ]: >>357

　（＞＜；）　なんにもわかんないんです！＞＜
　/つとﾉ　　
　しー-Ｊ
359 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 13:57:37 ]: >>356
クロスGUIつーかSwingのLnFが何やってるか知ってるか？
360 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 14:12:15 ]: 　（＞＜；）　Swingを使った事はありますがLnFわかんないんです！
　/つとﾉ　　
　しー-Ｊ
361 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 14:28:01 ]: >>353
あれはC++だろ。
362 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 14:28:44 ]: >>356
普通に考えて

Double Click + able

ダブルクリック可能って意味になるだろ
363 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 14:30:45 ]: >>360
e-words.jp/w/E383ABE38383E382AFEFBC86E38395E382A3E383BCE383AB.html
ja.wikipedia.org/wiki/LnF
364 名前：353 mailto:sage [2007/02/14(水) 14:47:38 ]: Java2より前のSwingしか使った事無いのですが、
今のSwingってXMLのスキンとかいうやつですか？

そのUIから、実行ファイルみたいなのをキック？
それともJNIコール？
365 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 15:03:35 ]: >>364
言ってる意味がわからないが
勝手に言ってることを予測して答えてみる。

今のSwingは性能が良い。
スキン変更はJavaプログラムで可能。
そのためWinXPのルナスキンを利用可能。ただしこれはWin
意外のOSで使うと著作権侵害になるのでWinのとき専用。
MacのときはMacのスキンも使える。
よって見た目は綺麗。XAMLやCAMLやXULみたいな、
XMLでスキンを変えられるかどうかということについてはよく知らない。

キック？　については、これも推測すると。
恐らく、Java Web Startの事を言っているのかと推測。
SwingアプリをJava Web Startに対応させるには、拡張子がjnlpという
XMLファイルを作って、そこの決められたフォーマットでSwingアプリの
main()メソッドがあるクラスへのリンクや
バージョン情報、必要なJREのバージョンなどを記述する。
すると、ブラウザ上で拡張子jnlpファイルを見つけると、まさにキックされ、
MIMEタイプを確認し、JREが入っているかどうかを確認し、バージョンチェックされ、
Java Web Startが起動し、Swingアプリのバージョンをチェックされ
Swingアプリが起動し実行される。

Java Web Startは、JNIは一切関係が無い。
366 名前：353 mailto:sage [2007/02/14(水) 15:09:13 ]: OOoのような画面をクロス環境（Win、MAC、Linux）で使いたかったらどうすれば良いのでしょうか？
で、処理部分はC++を使いたいです。
367 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 15:10:08 ]: Java2より前ってことはオプショナルパッケージのころか
そのときの知ってる人はもう少ないな

あの当時とはもはや別物だと思っていい

WebStartは今はデスクトップやプログラムメニューなどのショートカットに対応
つまり2回目からはブラウザの起動すら必要はない

そしてプログラムの追加と削除でもアンインストールができるようになってる
もちろん今までどおりコントロールパネルのJavaキャッシュからの削除なども出来る
368 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 15:18:38 ]: OooでJavaを使うのは、文書にJavaアプレットを埋めたりするくらいじゃな
かったか?

もしかしてMetalでない各プラットフォームで固有LnFにしたいってだけの
話なら、
String sysLnfClassName = UIManager.getSystemLookAndFeelClassName();
UIManager.setLookAndFeel(sysLnfClassName);
369 名前：353 mailto:sage [2007/02/14(水) 15:23:15 ]: いや、Java側から考えるのでなくて、
C++のコードがあるのですが、
GUI部分を１つ定義してWin、MAC、Linux全対応したいです。

そのときにC++側からSwing画面を開けるのかなー？、と。
370 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 15:26:58 ]: JNIはC++ APIもあって、データのやりとりも出来るので、
GUIをSwingで作って、エントリとなるメソッドをC++から
キックすればOK。
371 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 15:39:37 ]: >>364
Java2以前ってことはSwingというよりJFC?
XMLスキンは、恐らくSynthLookAndFeel
>>353
やりたいのは、NeoOfficeのやってることだな
GUI描画部分を、Javaにやらせるという
372 名前：353 mailto:sage [2007/02/14(水) 15:43:18 ]: MACでもJNIを簡単に作れますか？
373 名前：353 mailto:sage [2007/02/14(水) 15:45:00 ]: NeoOffice見ましたが、MACのみ。

クロスＧＵＩとして使われてるわけじゃないんだ？
374 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 16:34:17 ]: MacOSXにおいてJavaは標準サポートされてるし、JNI関係のヘッダもツールも
ある。C++コンパイラはg++。

製品バンドル版OSXなら一緒にg++を含んだ開発環境(Xcode)メディアも付いて
くるし、無料でダウンロードも出来る。Java環境の最新バージョンは1.6.0。
antも入ってる。
375 名前：353 mailto:sage [2007/02/14(水) 16:42:45 ]: じゃ、Javaで画面作って、C++コードはg++でコンパイルすれば宵ってことかぁ。

”Java＆C++”の開発効率がちょっぴり不安。
376 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 17:04:19 ]: >>366
Swingの勉強をする。
377 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 17:35:14 ]: >>375
俺はやったけど、両方わかってりゃ大した事は無かった。
つーても、やっぱc++からjavaオブジェクトを返すのにJNIEnvを使う部分があるんで、そこはちょっと効率悪いかな。
あとJNI部分のデバッグが面倒なんで、c++でロジック書いてJNIで薄くラップしてやる感じ。

java側は、ちゃんとMVCに分けて、DAOをしっかり分離してやりゃOK。
テスト用DAOに差し替えて開発して、最終的にJNIを使ったDAOでテストする。
まー規模にもよるだろうが。
378 名前：353 mailto:sage [2007/02/14(水) 17:38:49 ]: ｻﾝｸﾂ>>377

DLLコールと比べて、さらに効率悪いのかなぁ？

出来上がったアプリはやっぱりモッサリ？
379 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 17:51:13 ]: 次世代Javaの動向と関係ない話題は他所いってやれ。
380 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 17:53:03 ]: 次世代Java＝C++と連携

ですが、何か？
381 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 17:54:42 ]: ところで、次世代Javaというか有力候補のウィンドウライブラリって何？

Swingって落ち目な感じ？
382 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 18:03:33 ]: Swingは1.4以降実用レベルになってしまったから、
SWTとかの代替候補の立場が微妙になってるのが現状じゃね?
383 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 18:12:19 ]: あ、SWTが落ち目なんだ知らなかった。
知らないうちに勢力図が変わるんですね。

それと、デファクトだったEclipseがＳ∪∩の開発環境（何だっけ？）に負けたんでしたっけ？
384 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 18:20:25 ]: 其処までは行ってない。
むしろ、SWTの活躍の場は、eclipseしかない、という感じ。
Netbeansは、Jackpotがどうなるか、か？

誘導
Java 高速GUI SWT　3
pc10.2ch.net/test/read.cgi/tech/1164877399/
Java低速GUI Swing 5
pc10.2ch.net/test/read.cgi/tech/1161139809/
【Java】NetBeans Part2【Sun】
pc10.2ch.net/test/read.cgi/tech/1154582593/
385 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 18:27:26 ]: オライリーだっけ
去年の勝ち組負け組みでEclipseを最初負け組みと書いて後で消したの
一番使われてるのに負け組みはおかしいといわれたそうだが
386 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 18:41:27 ]: ふ～ん

じゃぁ、NetBeansとSwing使っとけば問題無いか。

Windows上だとちょっぴりモタツクだろうけど。
でも、モッサリドトネト（流行ってないくせにWinForms、WPFと２つあって最悪）よりかはましか。
387 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 18:42:36 ]: ごめん、もう一つ教えて。

NetBeansがEclipseをやっつけたってことは、
JBuilderとかは無用の長物？
388 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 18:50:15 ]: ごめん、さらにもう一つだけ教えて下さい。

以前のSwingではレイアウトマネージャのおかげで、
思ったように画面作り難かったのですが、
今のSwingはポトペタしやすいですか？
389 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 18:59:48 ]: >>388
NetBeans(の5以降で導入されたMatisseというデザイナ)を使うと無茶苦茶ポトペタしやすい。
と、漏れは個人的には思っている。
390 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 19:11:20 ]: >>380
JNI なんぞは、1.1 の頃には既にあったわけなんだが……

誘導
★お前らJavaはJNIで組もうぜ★
pc10.2ch.net/test/read.cgi/tech/1033795664/
391 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 19:14:29 ]: >>388
個人的には、GUIポトペタ(←(・∀・)ｲｲ!!)は、Netbeans。
ロジック書き書きは、eclipse。
両方使ってるよ。
NetbeansのSubversionプラグインは使いにくいし。
392 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 19:24:34 ]: じゃ、Netbeans使います。
CVSはWinCVS（←もしかしてサイアク？）使ってるんで。

JNIもふつーに使われてますか？
393 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 19:27:48 ]: 誘導
【Java】NetBeans Part2【Sun】
pc10.2ch.net/test/read.cgi/tech/1154582593/
394 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 19:57:46 ]: 名前のないメソッドつくろうぜ。例えば、
public class ArrayList<E> {
　　public nameless E (int index) { return get(i); }
　　//その他省略
}
のように書いて
String s = list(2); //listはArrayListのインスタンス
みたいにインスタンス名(引数)の形で呼び出す。
他にも、Mapなら
public nameless E (K key);と書いて
String s = map("key0");とか、
さらに、オーバーロード可能にすれば他にも使い方ができそうだ。
395 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 20:06:55 ]: >>394
じゃあ標準出力はSystem("%d%d", 100, 200);でOK？
396 名前：デフォルトの名無しさん [2007/02/14(水) 20:18:36 ]: 関数呼び出しのときの表現を変えるのをアノテーションで定義するのはどうだろう
@Alias(value = "ltgt" , type = "literal")//自作リテラル（ここでは<>）
@Alias(value = "plus_equal" , type = "operator")//演算子オーバーロード
これで実装するなら>>394は
@Alias("nameless")
ってとこか

んで、呼び出す対象のフィールドの宣言時も@AliasUsingをつける。
まぁ設計がまずいのに無理やり使わされるのもあれだしね。
397 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 21:33:06 ]: > それと、デファクトだったEclipseがＳ∪∩の開発環境（何だっけ？）に負けたんでしたっけ？

その文字を見たら昔のSunのCMを思い出した。
398 名前：デフォルトの名無しさん [2007/02/14(水) 21:45:16 ]: 396だけど、だめだな。
細かい仕様を定義しようとすると複雑になるし、いかに丁寧に仕組みを作っても雑に使われたら困るもんな。
よく使われるやつだけ今のString型みたいにして、アノテーションで限定解除するだけでいいか。
399 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 22:40:43 ]: >>394
>>396
次世代Javaの動向をヲチるスレであって、
勝手な妄想繰り広げるスレじゃないから。
400 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 22:48:56 ]: >>394
C# の Indexerっぽい奴なら、>>249 とか >>250 とかで既に出てるけど。

演算子オーバーロード関連なら、他にも >>283 の一番上のリンクとかもあったし。
401 名前：ﾈｶﾏ由紀恵 mailto:sage [2007/02/14(水) 23:05:20 ]: Groovy でやっていることは
入れなくても良いんじゃ・・？
402 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 23:23:43 ]: ていうか今時中身の処理が遅いからJNIなんてのは無いな。

特殊なデバイス叩かん限りpureJavaでいける。
実行速度なんて5.0 6.0で激変したしSwingも1.3→1.4以上でまともになったし。

joy pad使うとかしかJNIの存在理由が見当たらん・・・。

ここら辺は成熟してきたからこれ以上はOpenGLドライバの成熟待ちだろ。ATIもnVidiaも最近のドライバはOpenGLが糞。

そのせいで6.0でもsun.java2d.openglプロパティが使い物にならない。

Java側はドライバの対応を待つしかないからベンダと連携とって行くって言ってるし。

俺はあまり言語仕様を動的にするのには興味ないな。
仕様が複雑化してきてるし当初の仕様ポリシーから外れてきてる気がする。

個人的には値渡しの出来る構造体が欲しいかな。
一々データクラス定義してインスタンス化するのがちょっと・・・
403 名前：デフォルトの名無しさん mailto:sage [2007/02/15(木) 00:06:36 ]: >>402
public type Hoge{

String hoge;

int piyo;
}
見たいな感じかな。でも予約語が・・・
JavaBeanを簡単に生成できるシンタックスシュガーが欲しいね。
404 名前：デフォルトの名無しさん mailto:sage [2007/02/15(木) 00:36:38 ]: >>402
そこで、エスケープ解析によるオブジェクトのスタック割り付けですよ。
405 名前：デフォルトの名無しさん mailto:sage [2007/02/15(木) 01:23:08 ]: >>391
NetBeansのSubversionは動作がよくおかしくなる
というかAntとかもおかしい気がする
JDKを5.0にすると安定するから6のVMバグかも

>>392
CVSだったらNetBeans標準装備なんでそれ使えば楽

>>402
Swingは速度が目立つけど、実際は1.3で実用になるようなAPIが多数追加されて
5.0で目立つようなのが追加されていたりする

6も5.0と同じくsun.java2d.opengl使い物にならないね
JOGL自体は安定してるんだがGLJPanelのほうがイマイチなのもなおらねぇ
というかベータ時代はOpenGL有効にして動いてたような気がするのが気になる
406 名前：デフォルトの名無しさん mailto:sage [2007/02/15(木) 01:34:56 ]: >>400
その下の奴って構文解析できるのか？
class hoge{}
class A {
　public static Object method(int arg){ return null; }
　public static int (int lh)method(int rh){ return lh + rh; }
　public static void main(String[] args){
　　int hoge = 0;
　　(hoge)method(10);
　}
}

とかされたら面倒なよーな気がする。
407 名前：デフォルトの名無しさん mailto:sage [2007/02/15(木) 07:18:52 ]: >>399
昔は希望を書きまくっていた気もするが？
408 名前：デフォルトの名無しさん mailto:sage [2007/02/15(木) 08:40:38 ]: >>402
遅いからJNIするんじゃなくて、Win用C++コードをMACに移すためにJNI検討中なんです。

CocoaとかいうやつはObjective-Cだったりして困るし。
409 名前：デフォルトの名無しさん mailto:sage [2007/02/15(木) 08:51:30 ]: >>407
希望なら言語仕様作ってる人達に見える形でで出した方が通りやすいよ。

ksl とかあるんだし。
https://ksl.dev.java.net/
410 名前：デフォルトの名無しさん mailto:sage [2007/02/15(木) 08:56:41 ]: >>406
int Integer = 1;
System.out.println( (Integer)+10 );

とかと同じ扱いにすりゃ良いんじゃないかと思ったけど……
参照型へのキャストは単項+ とか単項- ついたらいかんのか。
つまり Integer って変数が宣言されてないときに

System.out.println( (Integer)+10 );

がコンパイルエラーになるから参考にならんと。むぅ。
411 名前：デフォルトの名無しさん mailto:sage [2007/02/15(木) 17:24:26 ]: >>399
ヲチりながら、愚痴るんじゃないの？
412 名前：402 mailto:sage [2007/02/15(木) 17:43:18 ]: >>405
リペイントマネージャ乗っ取って全コンポーネントダーティーだと認識させればユーザーの操作に応じて常にスケーラブルでアジャスタブルなウェジェット組めるが流石にまだ重いだろうなｗ

>ベータ時代は・・・
ttp://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6458746
これの応急処置だと思う。
JDialogに限らずOpenGL使ったコンポーネントが破壊される。

描画領域の破壊は-Dsun.java2d.opengl.fbobject=falseを指定すれば回避できるが・・・

FBO周り以外もバグがあるみたいでどうも-Dsun.java2d.opengl.fbobjectに関係なく-Dsun.java2d.opengl使った処理自体まずいみたい。
nVidiaのリグレッションバグなんだがOpenGL有効にしたらグラボ自体が不安定になって最悪システムクラッシュする。

グラボのドライバって既存アプリの描画に影響を与えるしな。リグレッションバグならそうそう戻す訳にはいかんだろうし。

>>408
結局JNI噛ます共有ライブラリ部分はネイティブなんだからリビルドするだろ？
てかwinのライブラリをmacで使おうって発想もな。
JNIにしたってネイティブ部分はプラットフォーム毎に用意するんだし。

J2MEはそれでカオスってるｗ
413 名前：デフォルトの名無しさん mailto:sage [2007/02/15(木) 18:05:37 ]: C++のコードをJavaに移植するほうが早そうだな
414 名前：デフォルトの名無しさん mailto:sage [2007/02/15(木) 19:04:29 ]: >>413ロジックのみならね。
Mac→WinだとMacしかないアプリのDLL使ったりして移植ゼロか、
Win→だとGUI周り以外はそうgdgdにならない？
415 名前：デフォルトの名無しさん mailto:sage [2007/02/15(木) 19:11:21 ]: あーJ2MEはJSR118-MR2からOpenGL実装したので専用チップ要求して更にカオスｗ

MIDP2.1はハードウェアサポートが強化されてるしウェジェットも地味に強化（新たに取り込まれたオプションパッケージが目立つ）してSEのノウハウもフィードバックされて結構良いんだが・・・
416 名前：デフォルトの名無しさん mailto:sage [2007/02/16(金) 17:45:58 ]: >>402
OpenGLといえばJava3Dを思い出した。
あちらも気が付けば大きな進展があるようだ。
JavaからOpenGLのライブラリを使えるようにするというやつ。
プラットフォーム非依存と呼ばれているJavaも3Dとなると
そうもいかないケースがあるものだが、
今後のJava3Dは古臭い時代遅れなビデオカードでは動かなく
なるか、(AWTのようにOS依存する)劣化表示
or
(Java2Dを使用したSwingのように)超低速表示されることになるんだろうか。
417 名前：デフォルトの名無しさん mailto:sage [2007/02/16(金) 17:48:15 ]: >>405
> >>391
> NetBeansのSubversionは動作がよくおかしくなる
> というかAntとかもおかしい気がする
> JDKを5.0にすると安定するから6のVMバグかも

EclipseでJava SE 6でAntを使っているがとくに問題ない。
おかしいってどんなエラーがでるのかね。
Subversionは不安なら、TortoiseSVNでコミットしてみるのはどうだろう。

> >>392
> CVSだったらNetBeans標準装備なんでそれ使えば楽
Eclipseと同じだな。しかしSubversion使ったらもうCVSには戻れない。
それだけ使い勝手が良いから。
418 名前：デフォルトの名無しさん mailto:sage [2007/02/16(金) 20:23:44 ]: そろそろ
MFCのようにSwingをラップしたGUIフレームワークが標準でJDKに入らないかな
419 名前：デフォルトの名無しさん mailto:sage [2007/02/16(金) 21:14:44 ]: JSR 296: Swing Application Framework
jcp.org/en/jsr/detail?id=296

これどうなるかねぇ。
420 名前：デフォルトの名無しさん mailto:sage [2007/02/16(金) 21:17:41 ]: >>416
JavaからOpenGL使うのはJOGL
去年1.0でたばっかりなのでこれからだと思うがOpenGL2.0がそのままラッピングされている
結果SWTのように汚いけど、これはCのコードのラップだからこれはこれでいいだろう
結果staticImportと相性がいい
まぁJOGLはSwingとは直接関係ないけど

>>417
Java6はVMがバグってるので演算結果がたまにおかしくなるというひどいバグがある
次のupdateでなおってるはずだけど最適化のバグっぽい
まぁ5.0とは別次元の速度になってるんでこんなにVMに手を入れていいのだろうかと思ったけど
予想通りVMのコアにバグいれるとは
はじめてオープンソースになった成果がこれってひどすぎ

つまりsubversionだけじゃなくてNetBeans自体が不安定になる＞JDK6
それにトータスは使い物にならないよ
バージョン管理ツーつってのはIDEと統合されてナンボだから

>>418
Swingの時点でMFC以上にラッピングされてるのだが
421 名前：デフォルトの名無しさん mailto:sage [2007/02/16(金) 21:21:08 ]: Swing Application Frameworkのプロトタイプ実装らしい。
https://appframework.dev.java.net/

見てみよっと。
422 名前：デフォルトの名無しさん mailto:sage [2007/02/16(金) 21:55:57 ]: SwingのラッパーはGroovyやRhinoから使うの便利そうだな
423 名前：デフォルトの名無しさん mailto:sage [2007/02/16(金) 21:58:35 ]: >>420
d.hatena.ne.jp/nowokay/20070113 で話題になってた
bugs.sun.com/bugdatabase/view_bug.do?bug_id=6512534 か？

J2SE 1.4.0 のときも、コードによっては 1.3.1 より遅くなって処理完了まで
2倍時間かかったり、とかあったしなぁ。個人的にはいつもの事だと思うんだけど。
ってか、JDK6 は既に現行世代だと何度言えば……
424 名前：デフォルトの名無しさん mailto:sage [2007/02/16(金) 22:20:15 ]: >>421
SessionStorage.WindowState って最大化状態サポートせんのか？と思って
users@appframework.dev.java.net に検索かけたら
https://appframework.dev.java.net/servlets/ReadMsg?list=users&msgNo=129
で、最大化状態は保持してるみたい？

最大化した状態で close(exit)した場合、最大化解除した状態のサイズは持ってないって事かな？
425 名前：デフォルトの名無しさん mailto:sage [2007/02/16(金) 22:30:55 ]: >>424
最大化解除したサイズって、どっかのメソッドで取れたっけか？

常に Frame のサイズ保存しておきながら WindowEvent おっかけて、
Frame#getExtendedState が MAXIMIZED になったら、
直前のサイズを最大化解除したサイズとして保存するとか、
Windows と他の OS で最大化する時の WindowEvent の届き方が違うので
面倒くさくて Windows だけしか対応しないとか、そんな記憶が……
426 名前：デフォルトの名無しさん mailto:sage [2007/02/16(金) 22:44:31 ]: >>423
いつものことの上、
修正コードが手早く手にはいるようになっただけで
大助かりですよね。

うまく動かなくなるバグなんて、1.4の頃ですが
GC周り突っつけばすぐ出てきましたよ。
バグ報告しても、US SUNまで訴えても直らないバグがあったりしたもんです。
直るにしても、次のリリースまで待たなきゃ駄目だしね。
427 名前：デフォルトの名無しさん mailto:sage [2007/02/16(金) 22:55:57 ]: とはいえ今はJDK7で自分で治せて配布できるようになったのは大きいかも
428 名前：デフォルトの名無しさん mailto:sage [2007/02/17(土) 00:06:11 ]: >>420
んなの初めて聞いた。バグ修正もてえへんだろうなあ。

TortoiseSVNは結構良いと思うけどなあ。ファイルの移動を
するときもわざわざ右クリックでめんどいことしないといけないけどさ。
429 名前：デフォルトの名無しさん mailto:sage [2007/02/17(土) 00:10:08 ]: >>427
直すのかなり難解だと思うが・・・。

Swingが新しくなるということは、SWTやM$のGUIよりも使い勝手がよいAPIを
作れるのだろうか。
430 名前：デフォルトの名無しさん mailto:sage [2007/02/17(土) 00:11:12 ]: そもそも新しくなるの?
431 名前：デフォルトの名無しさん mailto:sage [2007/02/17(土) 00:18:35 ]: NetBeansのSubversionは修正がされているかどうかがわざわざ再表示押さないと反映されないのがカス
コミットする前に最新状態取得しないとだめってあふぉか

CVSクライアントのほうは問題なし

というかSubversionはCVSのように自前で実装してないからなぁ
CVSモジュールに依存してるし

NetBeans3.6だったかあの時代のCVSサポート並のへっぽこさ
だから標準実装されてないのだろうね
432 名前：デフォルトの名無しさん mailto:sage [2007/02/17(土) 01:02:26 ]: >>424
> で、最大化状態は保持してるみたい？
保持してないんじゃね？単に最大化したbounds持ってるだけで。

ってか、WindowStateだしな。getExtendedState使えるのFrameだし……
433 名前：デフォルトの名無しさん mailto:sage [2007/02/17(土) 02:32:28 ]: >>431
SVNはCVSにそんなに依存していたっけか。
434 名前：デフォルトの名無しさん mailto:sage [2007/02/17(土) 08:40:54 ]: >>433
NetBeansのsubversionモジュールはCVSモジュールに依存している
435 名前：デフォルトの名無しさん mailto:sage [2007/02/17(土) 19:04:07 ]: SE 6てOSSにしてからコードの提供あったの？
６で異常な進化遂げてるし、ないならないでただのコミニュティー潰しにしか見えん。

あの超進化マジックは何？
ヒープの割当・インクリメンタルＧＣのアルゴリズム変更だけであそこまで変わるとは思えん。

＃まあ日本じゃ未だに1.4.2主流だしse7も迷走中だけど。
そろそろstaxとrhinoが使われだしても良いと思うんだ・・・
436 名前：デフォルトの名無しさん mailto:sage [2007/02/17(土) 19:13:41 ]: >>434
なんだ、そういうことか。
CVS嫌いなSubversion開発者は自分のSVN開発を批判する者に
対してかなり起こっていたからな。
「すでにCVSがあるのに、なんで独自に開発するんだ？」と質問された
ことについてもう反論していた気がする。
437 名前：デフォルトの名無しさん mailto:sage [2007/02/17(土) 20:01:54 ]: >>435
インクリメンタルGCの変化あったの?
5.0のときにトレインアルゴリズムつかわなくなってコンカレントGCになったけど
またかわったの？

速度は強度の最適化がクライアントVMでかかってるのがわかる。
演算系でサーバーVMとほぼ同じ速度が出たのはわらえた。
だからサーバーVM同梱してないのだなと。
438 名前：デフォルトの名無しさん mailto:sage [2007/02/18(日) 18:07:24 ]: レジスタ割付アルゴリズムが Linear Scan Register Allocation
とかいうものに変更されたとは聞いているが、そんなに効果があったのかー

Linear Scan Register Allocation
www.research.ibm.com/jalapeno/papers/toplas99.pdf
439 名前：デフォルトの名無しさん mailto:sage [2007/02/18(日) 19:25:03 ]: 従来のバイナリをいじらずおおむね2、30%速度向上してるんだよね
440 名前：デフォルトの名無しさん [2007/02/19(月) 12:35:31 ]: そろそろABAPみたいにSQLをネイティブに書けるようになると思うんだ。
441 名前：デフォルトの名無しさん mailto:sage [2007/02/19(月) 12:59:36 ]: >>437
インクリメンタルGCが、コンカレントGCに置き換えられたのは6からじゃなかったっけ？
5の段階では、Xinc使うなって言われてて・・・・
何か自信ないけど、パフォーマンスアップは、GCだけじゃないってのは賛成。

むしろ、Hotspot系だと思うな。
エスケープ分析効いてないかな？

というか、JDK7で盛り込むJVMの改良ってどっかで話題になってる？
JVMの機能強化ってJCPに乗らないと思うし・・・
442 名前：デフォルトの名無しさん mailto:sage [2007/02/19(月) 13:03:38 ]: 5.0からだよ、コンカレントGCにかわったのは

1.4.1だったかあたりからインクリメンタルGCは採用する価値のないものだったからいい変更だと思ったけどね
トレインアルゴリズムを使いたかったらXXオプションで指定すれば5.0でも使えた

GCの性能アップだけじゃパフォーマンスが落ちるのを防ぐだけであって性能は上がらないからGC以外が主なパワーアップだろう
６でのGCチェックはまだしてないけど、5.0でGCが10、20%性能上がってたのは有名かと
443 名前：デフォルトの名無しさん mailto:sage [2007/02/20(火) 19:28:14 ]: Lucidaフォントに日本語を追加する事ってできるの
444 名前：デフォルトの名無しさん mailto:sage [2007/02/21(水) 15:02:25 ]: 可能だけど莫大な金と人材と時間と日本語を熟知したフォントデザイナが必要だからsunだけじゃ不可能。

フォントならIPAフォントが抱き合わせライセンスじゃなかったら最強だと思うんだけどな。

所でJavaってGCが勝手にメモリガリガリやってるから
メモリの断片化をプログラマで制御出来ないよな？

長期間不眠不休なサーバーとかメモリ空間少ないJ2MEが辛いと思うんだけど、
今後ここら辺の解決策はないの？
緩和でも・・・J2MEのプリベリファイは良い案だったと思うんだ。

＃そういやse6でもプリベリファイ採用してるからそれが実行速度に献上してるかもな。
今思い出したｗ
445 名前：デフォルトの名無しさん mailto:sage [2007/02/21(水) 16:32:00 ]: >>444
System.GCしか今のところコントロールする方法はない。
あとはVMの実行時パラメータでヒープやアルゴリズムの調整でカバー。

ただ、System.GCはほとんどの実装でFullGC動くので実質使っちゃダメ。
System.newGCとかがあればかなり変わるんだろうけど。

ゲームとかにしろ常にシビアなタイミングがあるわけじゃなくて、今は100μsも遅れるとまずいけど
このタイミングなら10msは大丈夫とかあるからね。
1フレームに1回殿堂入りさせない新世代GCが指定できればそれでおけ。

どうもsunはここ数年リアルタイムJavaに力を入れてるんだけれども、
常にリアルタイム性が必要な用途ってのは少ないと理解してないっぽい。
446 名前：デフォルトの名無しさん mailto:sage [2007/02/21(水) 17:33:20 ]: > 所でJavaってGCが勝手にメモリガリガリやってるから
> メモリの断片化をプログラマで制御出来ないよな？
↑出来る処理系ってあるの？
447 名前：デフォルトの名無しさん mailto:sage [2007/02/21(水) 17:47:52 ]: >>446
C/C++だとメモリ管理は自分でするから確保も解放も
自分のタイミングで出来るって程度の意味だ。

勝手なタイミングでガンガンGCされるより断片化起こらないよねって話な。
448 名前：デフォルトの名無しさん mailto:sage [2007/02/21(水) 18:01:42 ]: >>447
それはおかしい
断片化と解放とは別の話だろ
それにC++だってアロケートしなおししないと同じだし

JavaのGCはそのタイミングをコントロールできないという点だけが問題
449 名前：デフォルトの名無しさん mailto:sage [2007/02/21(水) 20:44:23 ]: >>445
-XX:+ExplicitGCInvokesConcurrent
で、Java6なら完全停止は回避できる、のかな？
ttp://java.sun.com/javase/ja/6/docs/ja/technotes/guides/vm/cms-6.html
450 名前：デフォルトの名無しさん mailto:sage [2007/02/21(水) 23:45:23 ]: >>448
mallocなりOS依存のシステムコールで、でかいメモリとってきて、その中に
placed newでオブジェクト作れば、制御できると思う。
制御できるだけで、断片化しないメモリ確保戦略はプログラマ任せになるが。
451 名前：デフォルトの名無しさん mailto:sage [2007/02/21(水) 23:50:06 ]: >>444
GC でコンパクションが発生するのに断片化って???
452 名前：デフォルトの名無しさん mailto:sage [2007/02/21(水) 23:53:01 ]: なんか、全然次世代じゃない話で盛り上がってるな。
453 名前：デフォルトの名無しさん mailto:sage [2007/02/21(水) 23:57:03 ]: >>452
いつもの事だ。
454 名前：デフォルトの名無しさん mailto:sage [2007/02/22(木) 00:01:05 ]: >>445
> >>444
> System.GCしか今のところコントロールする方法はない。

java.lang.ref.SoftReferenceを使えば間接的にコントロールすることもできる。
455 名前：デフォルトの名無しさん mailto:sage [2007/02/22(木) 00:02:05 ]: >>445
> >>444
> どうもsunはここ数年リアルタイムJavaに力を入れてるんだけれども、
> 常にリアルタイム性が必要な用途ってのは少ないと理解してないっぽい。

彼らがJavaを作った目的は家電制御なんだけどな。
彼らはサーバを発電所のように使うものを想定している。
456 名前：デフォルトの名無しさん mailto:sage [2007/02/22(木) 00:04:13 ]: >>446
Bufferインタフェースを使って
巨大な配列を確保すれば
擬似的に管理できないこともないぞｗ

C/C++はメモリ全体を巨大な配列として扱えるようになっているのだから。
Javaでも巨大な配列をBufferで作れば似たようなことはできなくもないw
457 名前：デフォルトの名無しさん mailto:sage [2007/02/22(木) 00:05:52 ]: java.lang.refでオブジェクトの「到達可能性」をコントロールできる
香具師はいないのね
458 名前：デフォルトの名無しさん mailto:sage [2007/02/22(木) 00:14:10 ]: >>457
そりゃ、居ないだろ。

あれは到達可能でなくなった事を知るためのもので、
到達可能でなくす事を可能にしてくれるわけじゃない。
459 名前：デフォルトの名無しさん mailto:sage [2007/02/22(木) 01:27:33 ]: >>454
それ定期的に出てくるけどぜんぜんコントロールできねーよ
460 名前：デフォルトの名無しさん mailto:sage [2007/02/22(木) 13:56:01 ]: いつの世代でもGCは永遠の謎なのだ。
461 名前：デフォルトの名無しさん [2007/02/22(木) 21:22:26 ]: GCなしの方がよかったかもな～
462 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 00:09:49 ]: GCなしなんていまさらありえんだろ
463 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 00:26:43 ]: C++に逆戻りか？
464 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 00:27:32 ]: C++0xの使用をみたが、期待はずれだった。

あんな仕様では当分Javaには勝てないことがわかった。

D言語やC#のほうが全然魅力的だった。
465 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 00:31:08 ]: もう使用されているとは
466 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 01:51:35 ]: なんで、C++はそんなに使用を拡張していくんだろうねぇ…。今でも十分じゃん。
467 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 01:57:48 ]: そうだよな。

チンコの仕様に優れていても、使用に優れてない奴とかいるし。
468 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 02:01:08 ]: チョンの仕様かと思ったw

チョンのチンコの仕様は9cmで世界一ミクロ
469 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 02:06:38 ]: 仕様も使用もダメな例だな
470 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 04:24:39 ]: JDK7 build08
download.java.net/jdk7/changes/jdk7-b08.html
download.java.net/jdk7/binaries/

サマリが何も出来ていない
変わってないのかっ
と疑問も持ちつつUpdateする俺でした
471 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 05:02:19 ]: マネージド○○って完全にわすｒｙ
472 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 06:35:41 ]: CompilerAPIとRhino入れちゃったらこのノリでant入れそうで怖い。
最近標準化連中は仕様作り過ぎｗ
C++のexportみたいにry

コンパイル→テスト→ビルドの流れが全てプログラミング出来ます！
みたいにさ。

マジレスするとunsignedが欲しい。

static final unsigned byte の範囲の定数が欲しいのにって度々思う

#Java書いてるとshortの存在を忘れてint使っちゃう俺
473 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 07:56:31 ]: >>472
>static final unsigned byte の範囲の定数が欲しいのにって度々思う
short や int じゃだめってこと？
ケータイJavaかなんかかな。
474 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 08:57:09 ]: マイナス、負の値を使えばいい。
475 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 10:10:27 ]: >>473
そうJ2MEなんかで何かのパーサ書いてるとステータス操作に丁度0-128を使うことがあったりして。
ビット操作中心なんで負数は使えんし、
そもそもMEで使わんディスクスペースとヒープを確保する余裕はない！

そもそもstatic finalなフィールドすら宣言する余裕なんて無いんだよ。

文字列定数の長さを気にする様な世界だ。
ややこしい・・・
476 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 11:16:49 ]: >丁度0-128を使う

嫌がらせだなｗ
477 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 11:19:44 ]: >>475
ビット操作でも負数は使えるはずだが
478 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 12:33:58 ]: まあ、負数使いたくないのは個人的理由でもあるｗ

どうせ作ってたらサイズでかくなって定数をプリプロセッサやエディタの置換なんかで
マジックナンバーに展開して定数フィールド排除、
クラス名・メソッド名・フィールド名・インターフェイス名何かをAとかBとかにして長さ短くしてそもそもOOP何か無視して設計して
昔はそれでもダメなんでバイナリエディタで無駄なバイトコード手作業で最適化してサイズ落としたよ。
（まあ、今は難読化だけで間に合うが）

そんなんでshortとかintとかlongなんて無駄に使ってられませんｗ
少数も勿論固定少数点数ですｗ

XML1.0とXML in Namespace 仕様フルサポートしたライブラリ書いてjarサイズが50K台じゃでか過ぎるって世界だぜ・・・orz
一般的にはCLDC用のXMLパーサって10K台だよ。

＃つくづく趣味グラマで良かったと思うこの頃。
よくopera mini何て出来たもんだ
479 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 13:38:05 ]: >>472
> CompilerAPIとRhino入れちゃったらこのノリでant入れそうで怖い。
> 最近標準化連中は仕様作り過ぎｗ
> C++のexportみたいにry
> コンパイル→テスト→ビルドの流れが全てプログラミング出来ます！
> みたいにさ。
> マジレスするとunsignedが欲しい。
> static final unsigned byte の範囲の定数が欲しいのにって度々思う
> #Java書いてるとshortの存在を忘れてint使っちゃう俺

ラッパークラス作れ
480 名前：デフォルトの名無しさん [2007/02/23(金) 13:54:21 ]: >>475
> >>473
> そうJ2MEなんかで何かのパーサ書いてるとステータス操作に丁度0-128を使うことがあったりして。

今はJ2MEではなくJava ME。

つうか、もうそろそろ、スペック問題解決してもいいのでは。

昔と比べ、容量は10倍以上になったんじゃないのか？

S!アプリももう何年か前から1MBアプリを作れるようになったし
iアプリも903iからDoja5.0になって1MBにもなったし、今やダウンロード、スクラッチパッドの境界が
無くなって外部メモリも使えるようになって1MB以上のアプリも作れるようになったろ。

昔の10kB時代と比べたら全然気にしなくても良いようになってきたんではないのか？
481 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 13:55:32 ]: >>476
0-127に加えて-1か128を128替わり使えばいいのではと
482 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 13:56:13 ]: >>478
とりあえず新たにデータ型作るってのはどうよ
483 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 13:57:12 ]: >>478
jarsで圧縮率を上げればjarサイズが半分になるぜ
484 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 21:57:02 ]: static final は普通に、コンパイラでインライン展開することが
言語仕様で決まってなかったっけ。
485 名前：デフォルトの名無しさん [2007/02/23(金) 22:04:07 ]: 今のJava MEではGenericsやアノテーションは
使えるのか？
486 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 22:05:35 ]: >>484
決まってない。final で修飾されて、確実に定数式で初期化される変数だけ。

それに、ME とかの場合は static final な変数自体も節約したいんでしょ。
487 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 03:48:32 ]: >>845
使えない。VM仕様がJITがオプション扱いでブートストラップクラスローダしかない1.4か1.3時代程度だったとオモ。

けどジェネリックスなんて使うケースないと思う。
MEじゃあるべき処理を平気でとっぱらうからアルゴリズムの使い回しとか不要。
他にも汎用データクラス作るんじゃなくて一つのクラスに全てのデータと処理をぶち込むからジェネリックスの立場がない・・・。

インターフェイスすら排除する世界だぜｗ

ところでこんなリスト見つけた。VM仕様関連の情報らしい。
ttp://www.ingrid.org/java/vm/
488 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 12:23:48 ]: >>487
ジェネリクスはコレクションを手軽に扱うためだけとおもっても十分な効果が出るよ
489 名前：デフォルトの名無しさん [2007/02/24(土) 12:59:51 ]: Java SE 5になってから大分高速化したのに携帯電話には
まだ搭載できないでいるのか・・・

しかもまたまた1.3レベルとは。assertも使えぬのか。

アノテーションくらいはつかえたほうがいいとは思うのだが。
コンパイル時には無視できるタイプのアノテーションはとくにあったほうが便利だろう？

それに、いくつかクラスやメソッドが増えているし。
制約上全部は使えないとは思うけど、利便性を考えると、1.3レベルってつらそう。
490 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 13:32:37 ]: >>487
> ttp://www.ingrid.org/java/vm/
古いね。デッドリンク多いし。
491 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 15:42:08 ]: >>489
高速化したのはSunのJava SE 5の実装で、Javaっていう規格じゃないだろ。
ケータイって、SunのJVMが主流なの？
492 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 17:23:16 ]: >>488
コレクションFWないよ？レガシーしか。
java.util.*はDataとCalenderが端末依存でGMTすら禄に扱えない。
端末毎に返ってくる値が違う事があるし端末の時計とは
別にＶＭが時計持ってて端末と時間違うし時計アプリなんて信頼できんよ？
UTCなんてない。

これでもちゃんとした仕様の範囲だから困りもんだ。

>>491
主流はアプレックスのJBlend。
一応どこもsunのRI参照してるけど遅いとか理由付けてとことん独自実装＋JITが無いんでベンダー独自のインタプリタ高速化技術なるものを実装してRIとは別物。

KDDIとかSBM専用のオプションパッケージの実体はcom.jblend.*パッケージが主でリンク用のスタブクラスとJavaDocをCPに公開してるだけ。

最近のSEの仕様の恩恵が受けられないのが保守性が悪い悪い・・・
ドコモキャリア仕様の端末以外例外投げると問答無用でVM落とすしエラー出力ないから酷い酷い・・・

クラスローダーがブートストラップのしかないんで動的リンクできんしJarサイズがデカクなるって言うんで汎用のFWは作れんから
再開発部分が多いだろうねぇ。

プリベリファイがSEに取り込まれたんだからMEに何かくれよｗ
493 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 17:52:22 ]: >>492
CLDC 1.1 なら java.util.TimeZone が GMT をサポートするのは義務じゃなかったっけ？
TimeZone は GMT をサポートするけど、それを使っても
GMT な時間が返ってくるとは限らないってオチはあるかもなー、とか思った。

そーいや、JSR-310 で Date and Time API ってのがあったような。
あれって、JDK7 の contents だっけか？
494 名前：デフォルトの名無しさん [2007/02/24(土) 18:28:20 ]: >>492
System.currentTimeMills()の値を引数にして
DateやCalenderを作っても正確にならない？
495 名前：デフォルトの名無しさん [2007/02/24(土) 18:31:30 ]: >>492
> >>491
> 主流はアプレックスのJBlend。
> 一応どこもsunのRI参照してるけど遅いとか理由付けてとことん独自実装＋JITが無いんでベンダー独自のインタプリタ高速化技術なるものを実装してRIとは別物。

遅いとかではなく、かれらがハードウェアリソースをケチっているだけだと
いってみたかったりする。
携帯電話をもう少し大型化して、JVMの部分を物理的に大きく専有するようにして、電池も
巨大化させれば携帯電話でも十分早くなるはずだ、と言ってみる。

ハードディスク搭載、とバッテリ寿命さえ延びれば、さらにその理屈もとおるはずだ、と言ってみる。

そして、連中は、独自実装で市場を独占したいだけに過ぎないのだ、
かつてのSonyがやってたような、独自製品で覆い尽くし、ライバル製品との
互換性をわざと奪うために標準Java実装から逃げているだけなのだ、と言ってみせる。
496 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 19:48:51 ]: >>492
いやVectorとかでいいんだよ
それでも十分使い勝手がいい

中に何を格納するべきなのかをドキュメントに書かないとわからないってのは面倒だったりする

そういやJavaME用HotspotVMを開発したとかどっかのニュースみたな
携帯の用途だとhotspotよりはアーカイブ単位での丸ごとコンパイルのほうがよさそうだが
497 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 20:10:36 ]: >>489
IBMのJavaME向けコンパイラ/オプティマイザみたいな商用系使ってると
かなりのレベルまでstaticメソッドのインライン展開するし、
アサーションってMEの言語仕様で定めなくてもいいかなって気がするんだよね。
それよりも言語仕様のほうはシンプルにしてアプリケーションプログラマ
のほうで適切にアサーションのutilクラスを書いた方が全体としてシンプルで融通効くと思う。

というかコンパイル時にstaticメソッドのインライン展開なくても
>static final boolean DEBUG = false;
>public void assert(...){
> if(DEBUG){
> System.err.println(...);
> ...
> }
>}
みたいなコードが書けるように1.3でも言語仕様上ifブロックでの到達不能性チェックに
例外が設けられていて、かつ実装系の方でもSunとかIBMとか大体のコンパイラは
DEBUG=falseのときこの部分ごっそり削除してくれるし。
498 名前：497 mailto:sage [2007/02/24(土) 20:36:05 ]: アサーションだから
>static final boolean DEBUG = false;
>public void assert(boolean flag, ...){
> if(DEBUG){
> if(!flag){
> ...
> }
> }
>}
みたいな感じか。細かいことだけど。
499 名前：デフォルトの名無しさん [2007/02/24(土) 20:52:52 ]: なるほどー。
今ならAspectJでもっと効率よくできるかな？
500 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 22:31:51 ]: >>493
確か仕様上はGMTサポートしろゴルァだけどオチは

>GMT な時間が返ってくるとは限らないってオチはあるかもなー
だったかと・・・

>>495
仕様上は130K程度の不揮発性メモリ（KVM用）と30K程度の揮発性メモリ（コンフィグレーションライブラリロード用）
と16/32bit CPU及び何らかの方法でのネットワーク接続方法。

結局はプロファイルとオプションのライブラリロードが居るんでSUNは160~500K程度のメモリ（揮発・不揮発問わず）を想定してるんだけど。

が仕様上の要求だけどねぇ。携帯電話はそれでもリソースケチるからな・・・。

>>496
いやジェネリックスが便利なのは認めてるんだけどMEだとVector使うかテストしまくって確実に足りる最小の固定長配列使うか悩むんだよ。

ホットスポットVMなら仕様上はCDC HIとCLDC Hotspotて感じのが一応ある。
CDC用はネフロのVMが実装してたな。

>>497
良いねそれ。eclipseのjavacで試してみよう。

まあ、MEも仕様上はEcmaScript並みに互換性あるけどベンダーの実装が変な事やってんだよね。
MS VMとネスケVMとSUN VMで互換性が無かった時代のように
（厳密にはMS VMがネスケVMとSUN VMに互換性なかったんだけど。ライブラリのサポートも屑だったし）

学習能力が無いね日本の企業は。ブラウザ戦争とpureJava騒動であれだけカオスったのに。
501 名前：497 mailto:sage [2007/02/24(土) 22:46:46 ]: >>500
IBMがつくったコンパイラは例えば

1. VisualAge for Java
2. j9c(後期型は4と同等) + jxelink
3. IBM JDKのjavac
4. Eclipse/JDT(ecj.jar)
5. jikes

が挙げられる。497でstaticメソッドの展開が...って言ったのは
1のjxelink。厳密にはポストプロセッサ。

>良いねそれ。eclipseのjavacで試してみよう。

これが4のことを言っているのなら、1のjxelinkとは別物だよ。
502 名前：デフォルトの名無しさん [2007/02/24(土) 23:54:51 ]: >>500
もうさ、メガアプリ限定にしてしまえばいいよ。
俺たちが作りたいソフトはこういうものだから、
ハードウェアをもっと強化しろ！

とハード屋に圧力をかけてさ。

マイクロソフトみたいに力がないと
Vistaみたいな激重Windowsを開発してハードウェア屋が
それに追従するってこと難しいかな。

今はハード基準で携帯電話開発を強いられているみたいだけど、
ソフト屋からハード屋になんとかして圧力かけられないかねえ。

「お前らハード屋がだらしないから携帯電話開発がしづらいんだ！
ハードのスペックを高めることを要求する！」
みたいにさ
503 名前：デフォルトの名無しさん [2007/02/24(土) 23:58:12 ]: >>500
> >>496
> いやジェネリックスが便利なのは認めてるんだけどMEだとVector使うかテストしまくって確実に足りる最小の固定長配列使うか悩むんだよ。

java.nio.Bufferを実装したクラスを配列代わりに扱えば高速化するのでは？
と思ったら、あれJ2SE1.4からのものだった。

> >>497
> 学習能力が無いね日本の企業は。ブラウザ戦争とpureJava騒動であれだけカオスったのに。

SoftBankもまともじゃないし、KDDIもまともじゃないし、Docomoもどいつもこいつも
独占欲だけは高いからねえ。

ハードウェア重視でソフトウェアをなめてかかっているところが、だらしないよ。
日本の有名な大手家電メーカーがインターネット産業ろくに力を注がず、Web2.0に
乗り遅れたことをも証明しているし。
504 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 00:04:27 ]: >>502
とは言え、行き過ぎると Vista や PS3 の二の舞になると思うよ。
505 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 00:42:46 ]: 国内だとキャリア（←こいつが一番無関係ｗ）、世界的にはハード屋が頂点か。
どちらにしてもオープン標準のJava仕様がないがしろにされてるな。

まあ、ソフト屋ですら飼いならされてる現状じゃ仕方ないか。
仕様の地位をもっとこうW3C勧告の仕様並みに出来んかねぇ？（IEの糞実装さえなくなれば平和だからなアッチは）

ハードの方は十分にパワフルだと思うけどな・・・
翌々考えたら昔はメモリ以外今の携帯以下のハードと糞ＯＳでJavaが動いてたんだから。
win95よりce5のが安定してるしｗ
国内携帯は無駄な機能に溢れ返ってるからそれにシステムリソースとコストと
開発期間が圧迫されて一ソフトウェアどころじゃないだろうな。
またしても仕様の地位不足か・・・

SUNの苦労体質全部をJavaが担ってる気がするｗ
506 名前：デフォルトの名無しさん [2007/02/25(日) 01:02:42 ]: >>505
パワフルな割には容量が足りないってどういう事なんだろうなあと思うよ。
メモリもっと増やすべき。でないととてもパワフルじゃないな。

現実問題として電力消費が激しいと言う問題があるそうだ。

しかし省エネ型DRAMのようなメモリがもっと普及すれば解決できるんだとか。

つうか、携帯電話会社は、余計な機能にエネルギーを無駄に費やさず
Javaの部分にエネルギーを費やして欲しいな。
あらゆる機能をJavaを中心に動かせるようにすれば水平ポータビリティを
維持できるし、どの携帯電話でも同じように動くアプリを簡単に作れるようになる。
507 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 01:23:02 ]: KDDIがBREWで水平ポータビリィティやろうとしてソフト屋・消費者から大ブーイング受けた結果
建前上JBlend on BREW（サービス名オープンアプリ/どこがオープン何だと小一時間・・・）のっけましたが？

Javaで水平ポータビリティ実現すればsunの当初の目的が実現するな。
その為にはベンダーに協力してもらわんとダメだが。

その前に日本の携帯ビジネスモデルを破壊しないと受け入れられないだろう。
4G携帯なんて出したらドコモが死守してソフトバンクが
嘘ばら蒔いてイーモバとウィルが歓迎するんだろうな。
KDDIはBREW動いて音楽と動画DL出来れば何でも良さそうだが。

ネイティブ開発は個人には不可能か敷居高いだろうしJava（MIDP）流行らんもんかね
508 名前：デフォルトの名無しさん [2007/02/25(日) 01:38:36 ]: つかネイティブ開発はCPの審査がウザイよ。
審査に金かかるわ時間もかかるわ。
509 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 06:56:24 ]: 今のケータイでJavaをやろうとすること自体が間違いなことに気づけ。
510 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 07:12:43 ]: て事は昔の、今の携帯以下のスペックで動かしてたJava自体間違いだったって事か
511 名前：デフォルトの名無しさん [2007/02/25(日) 10:59:44 ]: Javaで何をするかが問題。
今の技術では、携帯に望みすぎ。
512 名前：デフォルトの名無しさん [2007/02/25(日) 12:55:29 ]: >>509
燃料電池またはＨＤＤが搭載されるもしくは
PDAなどもっと大型の携帯端末なら、
Javaをやる価値は少しはあるのではないかと言ってみる。

携帯キャリアメーカーもJavaに自分たちの収入源を
奪われるのを恐れて、わざとJavaの機能を制限して
Write Once, Run Anywhereの妨害をしているとおもうけどな。
彼らの、Javaの普及を妨害するやり方はつくづく陰湿だと思う。
513 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 13:37:18 ]: >>510
CPUのクロックだけで比べても意味がないぞ
514 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 21:46:09 ]: まあ、VMはハードウェアとＯＳを仮想化してるから下にパワーが無いとVMも非力になるな。
515 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 22:17:51 ]: >>510
すごく間違いだと思うなあ。Java熱に浮かされてただけじゃないかな。
516 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 03:24:52 ]: >>510
今に間違いじゃない日が来るって
おまいのPCのメモリに4GBのせなきゃVistaが・・・とか悩む日が来る事を
５年前に予想してたか？
>>512
わざとっていうか、自由はセキュリティリスクを持っているからな。
徐々に拡大してけばいいだろう
何でも出来る穴だらけの何かがデファクトになるのが怖いよ
517 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 04:23:39 ]: >>516
>今に間違いじゃない日が来るって
それって、今は間違いってことじゃん。
間違いじゃない日がきてから実用化すればいいのに。
なんでJava以外の選択肢を考えないのかね。
Collectionも使えないなんて、そんなんJavaじゃねーよ。
道具は適材適所。そこまでしてJavaにこだわるのが分からん。
518 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 06:53:19 ]: *7の頃から追っかけてるがあの頃の方が見向きもされなかったぞ。
それどころかボロクソに言われてた

昔はAWTすら使いもんにならなかった気がする。もっとスリムだったし。
519 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 08:18:20 ]: Avalon・Quartz・Cairoて出そろったのになんでJavaだけJava2Dなんだよ。

新型レンダラまだー？
520 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 09:07:33 ]: JOGLがあるよ。
521 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 10:50:29 ]: 3DはJOGLが1.0になったので使い物になった
ただ、フルスクリーン時にGLCanvasが描画されないプラットフォームがあるとかが気になる
GLJPanelは遅くてゲームなどでは実用にならないし

あと日本語ドキュメントが皆無なのがきついな
OpenGL部分はどうでもなるがそこ以外が追うのがきつい

JOGLがコアAPIになればJOGL自体の機能も充実してくると思われ
522 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 16:20:42 ]: JOGLのコア化ってありえるか？
あるとしたら現行Java2Dのハードウェア支援コードとの統合くらいじゃない？

どちらにせよいつの時代もOpenGLはデスクトップ向けVGAのドライバ対応が中途半端だからな。
ワークステーション向けは知らんが。
523 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 16:59:41 ]: >>516
> >>510
> 今に間違いじゃない日が来るって
> おまいのPCのメモリに4GBのせなきゃVistaが・・・とか悩む日が来る事を
> ５年前に予想してたか？
> >>512
> わざとっていうか、自由はセキュリティリスクを持っているからな。
> 徐々に拡大してけばいいだろう
> 何でも出来る穴だらけの何かがデファクトになるのが怖いよ

多重継承も演算子オーバーロードも何でもできますよとPRする
C++言語仕様じゃあるまいし。それはちょっと違うだろう。

Javaでできることはいっぱいあるのに、あえて彼らがそれをやらないのは
彼らが己の既得権益が破壊されるのを恐れているから。
日本企業はハードウェアに強い企業は多いけどソフトウェアには弱い
企業ばかりだからね。ソフト屋にハード屋をつぶされるのを恐れている。

その構図は、テレビ局などのメディアがインターネットを嫌っている理由に非常に良く似ている。
彼らがインターネットやGoogle、Web2.0を嫌っているのは、
彼らが苦労して長い時間をかけて培ってきたノウハウを破壊されるのを恐れているから。
彼らは小泉純一郎のような「痛みを伴う改革」や「格差社会」に自分たちが巻き込まれる
ことをひどく嫌い、ひどく恐れている。
524 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 17:06:04 ]: >>517
Javaでもこういうことができるよってことで、
とりあえず宣伝だけしておいただけだと思うがな。

いや「だけ」ってことはないな。
Sunが目指していることを実現するための
前準備としての実験でもあったわけだし
一般人にも、Javaというものがどういうものか、
これで理解してもらえたかもしれないね。
最近じゃauの勢力が拡大してどうなるかわからないけど、
一応、BREWの上でJavaも動かせると言われているし。

それに携帯Javaアプリは使えるものはいくつもある。
SuicaのアプリだってＦｅｌｉＣａチップと入出力するところを除き、
アプリケーションはJavaでできている。

なんだかんだいって、燃料電池のような大容量電池を携帯電話に搭載し、
チップが小型化すれば携帯電話Javaもますます良い方向に進んでゆくと
思うけどね。

そこで、Java以外の選択肢を出すと、結局ベンダ依存になってしまう。
今でさえ、JavaアプリはSoftBankとDocomoとでは異なるAPIを使用しているとはいえ、
基本的なAPIはベンダ依存していない。Java以外の選択肢で、
複数のキャリアに対応したアプリを作ることは、そう簡単なことではなかったはず。

BREW開発なんてCPに検査してもらうコストも時間もかかるし、メモリリークの
心配ばかりしないといけないし、容量は相変わらずS!アプリやiアプリの半分くらいでとっても地獄じゃないか。

そう考えると、Java以外の選択肢は、いまのところ、ろくなものがないと思うけどね。
525 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 17:21:02 ]: >>523-524
マ板行け。
526 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 17:30:02 ]: マ板ネタも含まれているかもしれないけどJava MEの将来に対する
要望も含まれているから、ここでもいいのではないかと
527 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 17:35:53 ]: >>526
要望なら要望聞いてくれるところで言わんと意味無かろうが。

動機からして現状を変えたいというものではなく、
単なる現状の愚痴なわけだし、完全にマ板ネタだろ。
>>523-524 は技術的な話ですらないし。
528 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 22:03:34 ]: 表題みるかぎりSE専門かと
529 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 23:23:01 ]: 技術的な話も含まれているがのう。

要望ねえ。JCPか？
530 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 23:26:20 ]: >>529
含まれてないよ。マ板池。
531 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 23:29:54 ]: >>530
営業やってる連中とか、プログラマ卒業した連中とかだと
>>523-524 が技術的に見えるのかもしらん。
532 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 03:14:34 ]: むしろBREW上のJAVAで話を広げて欲しかった。
というか、そろそろ携帯でJavaSE動かすことできそうなんだけど・・・
Mysaifuの取り組みには期待している
533 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 06:00:49 ]: >>524
>今でさえ、JavaアプリはSoftBankとDocomoとでは異なるAPIを使用しているとはいえ、
>基本的なAPIはベンダ依存していない。Java以外の選択肢で、
>複数のキャリアに対応したアプリを作ることは、そう簡単なことではなかったはず。

ダウト。Write once Run anywhere はケータイでは全然できていない。
APIも仕様も違うのに、簡単とかいうな。お前、じつは作ったことないだろ。
＃何だよ、scratch padって。

#if #else #endif が使えるC++のほうがまだケータイ向き。
でもauの審査がクソ遅いのはなんとかしてほしい。マジで。

> そう考えると、Java以外の選択肢は、いまのところ、ろくなものがないと思うけどね。

それこそお前が知らんだけじゃん。Pythonが使える機種があるんだけど、これなかなかいいよ。
つうかPalmOSが載ってくれれば一番よかったんだよ。なんでJavaなんだ？
534 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 07:00:15 ]: >>532
phoneME Advancedのどこが不満なんだ！ｗ

Mysaifu JVMは俺も入れてるけど・・・。
だって～かんきょうなくてびるど出来なかったんだも～んｗｗ

まあ、冗談は置いといてphoneME AdvancedならRIだし全部入りだしHotoSpotあるし、phoneMEベースのプロジェクトを見かけた事ないのが不思議だ。

てかBREW自体流行ってないし国内じゃあうのせいでBREWの印象悪いし、正直実装さえしてくれたらKJNIの方が良いな。

もうちょっとJBlendがRI通りに実装してくれたら・・・
MIDPにMMAPIのprotocolパッケージ入れてくれたら・・・
WavPlyer実装してくれたら・・・
後はデコードくらい自分でするのに・・・

ところでMEにnioパッケージ実装しても端末の物理メモリが足りませんって落ちになるんだろうか？
535 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 07:09:12 ]: >>533
M1000ってPalmじゃなかったけ？
MIDPが使えるからkjavaじゃなくてMIDP for Palm OSなんだろうか。
536 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 12:07:15 ]: >>532-535
キミら、次世代と関係ない話題は他所でやってくれんかね？

次世代っても、勝手な妄想とか勝手な要望とかは愚痴と変わらんのよ。
便所に「税金安くしてくれ」って書いて要望とか言わんでしょ。
537 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 19:04:27 ]: て言ってもSE7って情報少ないな
538 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 20:21:12 ]: これがSDKに内包されてjavaguiが広まないかなぁ

journal.mycom.co.jp/articles/2007/02/26/jsr296/
539 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 21:17:25 ]: それSwing普通に使える人にとってメリットがほとんどないぞ

フレームワークがはやったから作っただけというのが近い
struts以上に薄いラッパだし、SwingWorerとダブるところも多いし
これほどメリットがないフレームワークってのも珍しい
540 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 21:33:51 ]: ポトペタツールが対応するか次第のよーな。
541 名前：デフォルトの名無しさん [2007/02/28(水) 09:38:38 ]: >>533
> >>524
> #if #else #endif が使えるC++のほうがまだケータイ向き。
> でもauの審査がクソ遅いのはなんとかしてほしい。マジで。

プリ糞セッサに依存している時点で設計が全然駄目じゃん。

> > そう考えると、Java以外の選択肢は、いまのところ、ろくなものがないと思うけどね。
> それこそお前が知らんだけじゃん。Pythonが使える機種があるんだけど、これなかなかいいよ。

Python載せられることのどこがいいの理解できない。
542 名前：デフォルトの名無しさん mailto:sage [2007/02/28(水) 22:01:15 ]: どこかで見たような・・
543 名前：デフォルトの名無しさん mailto:sage [2007/02/28(水) 22:22:37 ]: >>533
んー、まえもimodeスレかMIDPスレで書いたけど、#ifdefのような条件
コンパイルがデメリットなく出来るようJavaの言語仕様はうまくできているん
だよね。C/C++の後追いだからちゃんと考えられてる。仕様書よんでごらん。
そのほかJavaME向けにインライン展開がんがんつかうようなコンパイラ
併用してクラス設計すると携帯向けでもプリプロセッサって必要ない。まあ
マクロはないから文法ひっくりかえすような表記でコードは書けないけど、
それはC/C++でも行儀良くないからな。
544 名前：543 mailto:sage [2007/02/28(水) 22:31:04 ]: スレ違いの話だけだとあれなんでSEの話もふっとく。

techon.nikkeibp.co.jp/article/HONSHI/20070220/127928/
↑
OSGi(JSR232)はJavaMEの分野では静かに着々と浸透しているのに
SEへの導入(JSR291)は及び腰なんだよな、Sun。自分で旗振って
OSGi始めたのにいまさら梯子外すのはないよなあ。
545 名前：デフォルトの名無しさん mailto:sage [2007/03/01(木) 09:21:12 ]: >>543
>#ifdefのような条件
>コンパイルがデメリットなく出来るようJavaの言語仕様はうまくできているん

だからそれはJ2SEのような環境が統一されている場合の話であって、
機種依存が激しい携帯ではなりたたないって。
VMですら機能やバージョンが違うのに。

>そのほかJavaME向けにインライン展開がんがんつかうようなコンパイラ
>併用してクラス設計すると携帯向けでもプリプロセッサって必要ない。

インライン展開があればプリプロセッサは必要ないという根拠が分からん。説明よろしく。
546 名前：デフォルトの名無しさん mailto:sage [2007/03/01(木) 10:02:45 ]: >>543
>#ifdefのような条件
>コンパイルがデメリットなく出来るようJavaの言語仕様はうまくできているん

MEで一つのソースの中に複数ターゲット向けのコード混ぜたら絶望的なソースになるよ？

最低プロファイル・機種毎にソース分けんと確実に死ねる。

jadも分けんとたまにハマるから油断できん！
547 名前：デフォルトの名無しさん mailto:sage [2007/03/01(木) 10:13:36 ]: あー言い忘れたeclipseでリファクタリングしただけでエミュでは動いて実機では動かなくなるのがMEの世界だ。

システムが勝手に走らせる特定のスレッドの実行が一定時間以内に終わらないと強制終了とか。

実行時例外catchしてcatch節でコード実行すると問答無用で落とすとか（catchしても何もしなければ良かったり、ときにはcatchすら許してくれない）

あと実機じゃ機嫌悪いと動くコードもマジで動かん。
MEでプリプロセッサ使ったソースなんて保守以前の問題。
548 名前：デフォルトの名無しさん mailto:sage [2007/03/01(木) 10:58:01 ]: >>545
>だからそれはJ2SEのような環境が統一されている場合の話であって、
>機種依存が激しい携帯ではなりたたないって。
>VMですら機能やバージョンが違うのに。

つーか、J2SEでも、Sun/IBM VM間のクセの違いの吸収や、
Sun VMでもSwingの1.4, 5, 6での差を吸収させるのに、#ifdefは欲しい。
549 名前：デフォルトの名無しさん mailto:sage [2007/03/01(木) 11:39:58 ]: いやだからそういう次元じゃないとｒｙ
MEやれ
550 名前：デフォルトの名無しさん mailto:sage [2007/03/02(金) 00:07:56 ]: >>548
SEで、ifdefは勘弁して欲しい。
それなら、せめて其処のコードは別クラスに分けて設計してくれよ・・・
551 名前：デフォルトの名無しさん mailto:sage [2007/03/02(金) 20:50:21 ]: JDK7 build09
download.java.net/jdk7/changes/jdk7-b09.html
download.java.net/jdk7/binaries/

何だろう？2回続けてサマリがないビルドだ・・・
まあ今回もupdateするけど～
552 名前：デフォルトの名無しさん mailto:sage [2007/03/02(金) 21:32:24 ]: >>551
>>470 のリンク先見たら前回のは出てる。

ビルド方法でトラブってて changes が自動生成できてないから、
後から手動で生成してるとか？それとも単に怠慢で遅れてるだけ？
553 名前：デフォルトの名無しさん [2007/03/03(土) 07:27:48 ]: フィールドのgenericTypeを取りたいんだが方法はある？
例：List<Integer> listのInteger
554 名前：デフォルトの名無しさん [2007/03/03(土) 08:19:37 ]: >>544
べつに無理にJava標準に含めることを早めなくても問題なかろ。

早めることよりもむしろ、理にかなってこそ導入すべきだが。
Javaを駄目にするおそれがあるとしてJavaに導入することをまだ認めていないだけだと思うぞ。
JCPは少なくとも、Java SE 1.3以降からの上位互換性をもの凄く気にしているようだから
下手にほいほいと導入するわけにはいかんでしょうや。

そう考えると、enum型の導入が遅くなった理由もなんとなくわかる。

OSGiはなぜかEclipse Communityががんばっているようだし。
Eclipseのプラグインフレームワークに導入されているが、
SunとIBMだもんね。そういうところでは決して仲がよいとはいえないしねえ。
SWTを巡る技術的な問題もあるし。Swingは遅いからSWTを作ったと主張してきたIBM
に不信感を抱いているのではないかな？
555 名前：デフォルトの名無しさん [2007/03/03(土) 08:22:53 ]: >>548
駄目だお前。
ソフトウェア工学をなめとる。
修行が足りんぞ。
556 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 08:24:07 ]: >>553
get(i)
557 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 08:28:45 ]: >>553
download.java.net/jdk/jdk-api-localizations/jdk-api-ja/builds/latest/html/ja/api/java/lang/reflect/ParameterizedType.html
558 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 08:50:51 ]: >>557
$ cat Test.java
import java.util.List;
import java.util.ArrayList;
import java.lang.reflect.ParameterizedType;
import java.lang.reflect.Type;

public class Test {
public static void main(String[] args) {
ArrayList<Integer> l = new ArrayList<Integer>();
Type type = l.getClass().getGenericSuperclass();
ParameterizedType pt = (ParameterizedType)type;
for (Type t: pt.getActualTypeArguments()) {
System.out.println(t);
}
}
}

$ java Test
E

ありゃ。
559 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 09:02:20 ]: class IntegerList extends ArrayList<Integer> {}

public class Test {
public static void main(String[] args) {
Type type = IntegerList.class.getGenericSuperclass();
for (Type t: ((ParameterizedType)type).getActualTypeArguments()) {
System.out.println(t);
}
}
}
とすると
class java.lang.Integer
となるな。
560 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 11:03:18 ]: >>553
List<Integer> の Integer はコンパイル時に情報消えるよ。
>>559 みたいなのは特殊な例。
561 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 11:15:54 ]: って、ローカル変数じゃなくてフィールドの宣言についてか。

public class test {
    public List<Integer> sample;
    public static void main(String[] args) throws Exception {
        for (Type t: ((ParameterizedType)test.class.getField("sample").getGenericType()).getActualTypeArguments()) {
            System.out.println(t);
        }
    }
}

>java test
class java.lang.Integer
562 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 11:21:52 ]: >>558はgetClassしてる時点でどうなるかをかんがえればよろし
563 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 14:24:41 ]: >>553
初心者質問スレ行けよ。
564 名前：デフォルトの名無しさん [2007/03/03(土) 15:28:47 ]: >>556-563
㌧
565 名前：デフォルトの名無しさん mailto:sage [2007/03/04(日) 09:29:05 ]: >>551
追記：
見た目で大きく変わるところ発見。
Javaのウィンドウのデフォルトアイコンがデュークのアイコンになってる！！
可愛いです。

デュークのライセンス変更で、こういう事になったのね
わかりにくいカップよりコレはいいな
566 名前：デフォルトの名無しさん mailto:sage [2007/03/05(月) 16:02:11 ]: invokedynamic 使えるかどうかプログラム側から判断するのって、どうすれば良いですか？
567 名前：デフォルトの名無しさん mailto:sage [2007/03/05(月) 16:44:34 ]: >>566
実行時に動的でも静的でも良いから invokedynamic 使ったクラス読み込んで、
エラー出たら使えないんじゃね？

そーいや、invokedynamic って今どーなってんだろ？
invokedynamic のオペランドとかの詳細あったっけか？
568 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 15:34:36 ]: 某スレの 288 へレス。
> クロージャよりは揉めずに入りそうな気がしてる。
ウソはいかん。javac の人なんかはイラネって言ってるし。

blogs.sun.com/ahe/entry/java_se_7_wish_list
要は、プロパティに dot でアクセスしようとすると、
既存のフィールドアクセスと区別つかなくなるので、後付の面倒なルールを加える必要があるから嫌だそうで。
例えばフィールド宣言したコンパイル単位ではフィールドアクセスでそれ以外ではプロパティアクセスとか、
プロパティと同名のフィールド持てないとか、そんな感じのルール。
どんなルールで対処するにせよ、完全な互換性維持は無理だろうし。
もしくは "->" とかでプロパティにアクセスするとかだけど、これはこれでキモイから嫌なんだそうで。

weblogs.java.net/blog/forax/archive/2007/01/property_reload.html
ksl でプロパティの試験実装してた人とかも、
Access to property は setter getter で、って意見変えてるし。
569 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 17:20:57 ]: >>568
そうか、キモイか・・・うん、キモイなぁ

dotを使うのは、駄目と言う点は全く賛成だが
表記方法さえ、決まればOKだと思ってるんだけどなぁ

俺は、個人的な好みは->はキモイけど、 : ならOKです。
570 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 17:41:54 ]: ::
.
.*
->
->*

いろんな言語のaccessor。あと何があったっけ？
571 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 17:48:11 ]: >>569
オレ自身は "->" でもいいじゃん、とか思ってたりする。
他の人が "->" がキモイって言うのも理解できるんだけど。

jroller.com/page/scolebourne?entry=property_access_is_it_an
${classInstance.propertyName} みたいに ${} で括った部分では
式言語使えるようにすりゃええやん、ってのも出てるけど……
そこまでして dot に拘らんでも、と思わなくもない。
572 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 18:14:36 ]: >>569
:: じゃなくて : なの？

class A { property Object b; }
class B { property Object c; }
class Hoge {
　A a; B b; Object c;
　boolean flag;
　Object method(){
　　return flag ? a : b : c;
　}
}
とかされると分かりにくくなるよーな気もする。
構文解析自体は結合順位とかがあるから出来ると思うけど。
573 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 18:15:17 ]: dot人気ないね。
フィールドアクセスとプロパティのインターフェースを別のものにしたら、
単なるgetter/setterの省略表記になってしまってあまりうまみがないと
思うのは俺だけかな？
574 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 18:42:44 ]: >>573
皆が納得できる上手いルールが作れれば dot でも良いと思うけど。
人気がないって言うよりも、>>568 のような追加ルールを決める部分を
誰もやりたがらないような気もする。
簡単なルールで互換性壊したりすれば既存のソース使えなくなった人から嫌われるだろうし、
なるべく互換性維持しようとすると、ルールが複雑になって
今度はコンパイラの作者とかから嫌われるだろうし。

>>132 のリンク先が紹介された後、"->" はキモい、dot が良いって言ってた連中の
blog 見た感じだと、>>568 みたいな問題を小さく考えてるか、
もしくは問題自体を理解してないような。

C# みたく最初から言語機能としてプロパティを持ってる言語ならともかく、
Javaの場合は既存のJavaBeansのプロパティがあって後付けしようとしてるんだから
getter/setter の省略表記と割り切った方が現実的じゃないかな？
575 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 22:38:47 ]: >>572
あ、いや、: ←コロンを使うという意味だった。
Perl、Pnutsなんかで親しんでいる例からいくと、 :: で使うのを想定してた。
一つだと、 hogehoge==null？a : b;
とか、switchが混乱するから。

>>573
いや、むしろそれがいい。
見たら裏で何をしているかがよく分かる。
別に、dotではなくて :: でも可読性は落ちないと思う。

-> は、演算記号と紛らわしくて、嫌。
576 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 23:03:00 ]: プロパティなんてそもそも本質的には冗長な機能なんだから、
どうせ使えるようにするならマイクロソフト系の言語と同じ記法でいいと思うんだがなあ。
577 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 23:08:52 ]: > マイクロソフト系の言語と同じ記法でいいと思うんだがなあ。
具体的には？
578 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 03:22:06 ]: C++で->使ってるから、->でいいや。
579 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 04:10:14 ]: >>576
VBだとdotじゃなかったっけ？
580 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 08:32:28 ]: >>577,579
VB,C#ともどっとだね。
仕様策定してる連中がドットを嫌う理由がよくわかんない。
どうせ現存するソースコードにはプロパティ使ってるものなんて無いんだから
新しくプロパティの意味を持たせても別にいいと思うんだが。
581 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 08:50:48 ]: >>580
C# だと、同名のプロパティとフィールドは同時に宣言できないんだっけか？
まぁ、そーゆー後付けのルール追加すりゃ出来るかもしれんけどさ。
Javaに、そんなルール後付けしたら互換性無くなるし。

なんでこんな簡単な事が理解できないのかわかんない。
582 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 08:55:00 ]: >>581
プロパティ自体後付けじゃん…て思ったんだけど、
setter/getterペアにアクセスする演算子のことなのか。
プロパティ定義の構文も新しく作るのかと思ったよ。
C#の Property Hoge { ～ } みたいにさ。
だったら「そんなもんｲﾗﾈ」に一票だなあ
583 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 09:19:05 ]: >>582
> プロパティ自体後付けじゃん…て思ったんだけど、
JavaBeans のプロパティ自体はあって、その構文糖を追加しなければならない。
だから、完全に後付けってわけでもない。
JavaBeansのプロパティや、それを使ってる既存のフレームワーク捨てるなら別だけど。

あとプロパティ定義の構文を新しく作っても、プロパティアクセスに dot 使えば問題は出る。
例えば、
class MyComponent implements java.beans.DesignMode {
　private boolean designTime;
　public boolean isDesignTime(){ return designTime; }
　public void setDesignTime(boolean f){ designTime = f; }
}
みたいな既存のコードがあるとする。

プロパティが追加されて java.beans.DesignMode が
interface DesignMode {
　public static final String PROPERTYNAME = "designTime";
　public abstract property designTime;
}
みたいに変更された場合に、MyComponent をコンパイルする（＝互換性を持つ）のが難しい。
584 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 09:57:09 ]: >>580
> 仕様策定してる連中がドットを嫌う理由がよくわかんない。
dot 使ったらフィールドアクセスとプロパティアクセスの区別がつかなくなると何度言えば……
585 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 10:02:47 ]: >>580
> どうせ現存するソースコードにはプロパティ使ってるものなんて無いんだから
ひょっとして、現存するソースコードに Beans のプロパティ持ってるものが
大量にあるって事がわかってない？
586 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 11:37:56 ]: だからさ、プロパティってのはgetter/setterペアのことじゃなくて
それとは別に新しい概念を持ち込むのかと思ってたって>>582に書いたでしょう。
何嬉しそうにツッコミいれてんだよ。
587 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 11:41:08 ]: > 何嬉しそうにツッコミいれてんだよ。
いや、無知だなぁ、と思って。
588 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 11:51:08 ]: >>587
どの辺が無知だったか教えてちょ。勉強するから。
589 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 11:56:57 ]: >>588
このスレに出てるのだけでも、プロパティに関するリンク先読んでれば
beans と関係のない新しいプロパティを導入するとか思わんでしょ。普通。
590 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 13:21:21 ]: >>589
そうだな。すまんかった。
591 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 20:35:44 ]: >>583
>みたいに変更された場合に、MyComponent をコンパイルする（＝互換性を持つ）のが難しい。

ここがよくわかんないんだけど、誰か解説して。
アクセッサがあればそちらを優先的に使う（あるいは逆にフィールドアクセスを優先する）というルールを決めればすむ話じゃないの？
で、583みたいな状況になったらコンパイラが警告を出してくれればそれでいいと思うんだけど。
592 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 20:47:38 ]: >>591
> アクセッサがあればそちらを優先的に使う
それやったらコンパイルが通らん。

> フィールドアクセスを優先する
フィールドでプロパティを上書きできるようになるけど、それで良いんか？
593 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 20:56:24 ]: × フィールドでプロパティを上書き
○ フィールドでプロパティを覆い隠し
594 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 21:00:25 ]: >>592
> > アクセッサがあればそちらを優先的に使う
> それやったらコンパイルが通らん。
いや、コンパイルは通るかもしれんが……

例えば
> public boolean isDesignTime(){ return designTime; }
は public boolean isDesignTime(){ return isDesignTime(); }
に展開されるから実行時に StackOverflowError 吐いて死ぬ。
595 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 21:20:38 ]: >>584
区別させないのがプロパティだろうに。
596 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 21:24:32 ]: >>595
コンパイラが区別できないって意味なんだけど。

人間が区別しないとか、区別を意識させるべきでないってのとは別の話だよ。
597 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 22:11:17 ]: >>596
まぁ互換性を維持してのプロパティの導入には実装上の困難を
解決できていないというのはいいんだが、だからといって
「できる方法で実装しちゃおう」となるとしたら賛成できないなぁ。

互換性の面から考えた場合、方法は大きく3種類に分類できて、

1.JavaBeansと相互に互換性のある方法
2.JavaBeansとは互換性がないが、バイトコードレベルでの
　仕様変更を伴わない方法
3.バイトコードレベルで拡張する方法

このうち、3.を採用すると何でもありだから議論から除外するとして、
個人的には1.には拘らないから2.でうまいことやってくれないかなと
思うんだが。
598 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 23:05:53 ]: >>597
1 の場合はともかく、2 や 3 の場合はコンパイラ実装するとか言語仕様追加する、
とかってのは一番楽な部分だからね。

JavaBeans を切り捨てるってのは、技術的というより政治的な問題だから、
ハッカー気質が強い人ほど、自分でコード書いたりする時間がなくなって
政治的な問題に時間を取られる、って予感があるので手を引きたがる。

2 の場合は機能を欲しがる人は居るかもしれんけど、
（2 をやれるだけの政治的立場とか確保してる人の中で）
やりたがる人は居ないと俺は思うから、たぶん実現できないと思う。
599 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 23:18:49 ]: > JavaBeans を切り捨てるってのは
切り捨てるわけじゃないか……

でもまぁ、標準API とかで setter/getterと新プロパティ共存させるとか
標準API とかの setter/getter を新プロパティで置き換えるとかってなれば
厄介な政治的問題だってのは予想できるでしょ。

言語として 2 のプロパティ持ってても、
標準API は 2 のプロパティをサポートしませんとかなったら間抜けだし。
600 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 23:26:45 ]: > でもまぁ、標準API とかで setter/getterと新プロパティ共存させるとか
こんな決定したら袋叩きにあうような気もする。
メンテ面倒くさいし。

enum でも、似たような事やってたけどさ。
enum だと、自前の enum を定義するクラスが比較的少ないから
メンテが面倒って不満がそれほど大きくならんかっただけだと思うし。
601 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 23:30:42 ]: XMLEncoderがenumに対応してないと気づいたときに、Javaは終わったと思った。
602 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 23:34:54 ]: これ?
bugs.sun.com/bugdatabase/view_bug.do?bug_id=5015403
603 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 08:40:52 ]: >>592
>それやったらコンパイルが通らん。
だから具体的に説明してくれって。頭の悪い俺でも分かるように。

>フィールドでプロパティを上書きできるようになるけど、それで良いんか？
これが問題になるのって、フィールドがnon privateのときだけだよね。
フィールドもアクセッサもpublicというのはちょっと考えにくいから、これでも別にいいと思うけど。

>>594
>例えば
>> public boolean isDesignTime(){ return designTime; }
>は public boolean isDesignTime(){ return isDesignTime(); }
>に展開されるから実行時に StackOverflowError 吐いて死ぬ。

これ、展開させたらだめだよ。インスタンス変数に全くアクセスできなくなる。
展開させるのは foo.bar 形式だけ。ただし this.bar はのぞく。
これなら大丈夫じゃない？
604 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 09:35:33 ]: >>603
> これが問題になるのって、フィールドがnon privateのときだけだよね。
違う。例えば

class A{ public int field = 0; }
class B extends A{ private int field = 1; }
class C { public static void main(String[] args){
　System.out.println( new B().field );
} }
とかだと A の field にアクセスできんでしょ？
つまり、private なフィールドでも public なプロパティを覆い隠せる。
ってか、言語仕様読んでも、なんでＡの field にアクセスできないのか
俺には良くわからんのだが…… 覆い隠しって単純名だけに作用するんじゃないんかな？

> これ、展開させたらだめだよ。インスタンス変数に全くアクセスできなくなる。
そうだよ。だから無理だって言ってるじゃん。

> 展開させるのは foo.bar 形式だけ。ただし this.bar はのぞく。
そんな無茶な。現行の言語仕様では foo.bar と this.bar は区別してないし。
605 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 09:38:13 ]: >>603
> 展開させるのは foo.bar 形式だけ。ただし this.bar はのぞく。
> これなら大丈夫じゃない？
package-private もしくは protected なフィールドと、
public なプロパティで問題起こるから解決になってない。
606 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 10:13:00 ]: >>604
> 覆い隠しって単純名だけに作用するんじゃないんかな？
違うか。覆い隠しじゃなくて、隠蔽されたフィールドは継承されないから、
B のインスタンスからは A の field にはアクセスできないのか。

名前の章ばっかし見てたら理解できんかった。
607 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 10:17:35 ]: どっちにしろ、今更プロパティを言語仕様に導入しようなんて考えるのが間違ってる。
608 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 12:25:26 ]: 間違い、とまでは思わないけどね。
609 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 13:47:17 ]: >>603
> 展開させるのは foo.bar 形式だけ。ただし this.bar はのぞく。
これだと、他にも穴があるか。
class A implements Compareble<A>{
　private int field; public long getField(){ return field; }
　public int compareTo(A another){ return this.field - another.field; }
}
とかがコンパイルエラーになる、と。
610 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 15:00:26 ]: > 展開させるのは foo.bar 形式だけ。ただし this.bar はのぞく。
(this).bar とかだとどうすんだろ？
611 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 16:53:37 ]: ってか、そーゆールールなら
・フィールドが可視ならフィールドアクセス
・そうでなければ、プロパティがあるならプロパティアクセス
とかの方が良いような気もする。

それでも static なプロパティを許したりすると、同名のメンバークラスと衝突するし。
ってか、同名のフィールドが可視なら shorthand syntax for accessing properties
を使えないのって、本当に使いやすいかも結構問題のような？
612 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 19:42:20 ]: 何か激しく壊れてない？
ttp://download.java.net/jdk7/binaries/
613 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 19:42:27 ]: >>604
>違う
というのは勘違いということでいいのかな？

>そうだよ。だから無理だって言ってるじゃん。
だから『展開させるのは foo.bar 形式だけ。ただし this.bar はのぞく』といっているんだけど。

>そんな無茶な。現行の言語仕様では foo.bar と this.bar は区別してないし。
なんで無茶なの？区別してないなら区別すればいいじゃん。thisは予約語なんだから簡単じゃん。
614 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 19:48:30 ]: >>613
＞なんで無茶なの？区別してないなら区別すればいいじゃん。thisは予約語なんだから簡単じゃん。
汚い設計。
わかりにくいです。
あとマルチスレッド周りで問題がでそうだな。
615 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 20:05:41 ]: >>613
> というのは勘違いということでいいのかな？
いや、覆い隠しは勘違いだったけど、
private フィールドで public なプロパティを隠蔽できるから問題になるのは変わらない。

> 区別してないなら区別すればいいじゃん。
区別しても、 >>605、>>609、>>610 みたいな穴があるから、やるだけ無駄。
616 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 20:44:57 ]: >>611
どっちかっつーと dot でプロパティアクセス許す場合、
フィールドと同名のプロパティを作れるってのが混乱の元だとか認識されてんのかも？
617 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 20:51:03 ]: > あとマルチスレッド周りで問題がでそうだな。
問題でるかな？
618 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 20:53:23 ]: >>613
> なんで無茶なの？
根本に近い方のルールを書き直すってのは、
既存のコンパイラを改変する時に多くの労力がかかりそうだってのは分かるでしょ？

だから無茶なの。
619 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 21:20:36 ]: >>571
> ${classInstance.propertyName} みたいに ${} で括った部分では
> 式言語使えるようにすりゃええやん、ってのも出てるけど……

ksl の課題追跡にあった
https://ksl.dev.java.net/issues/show_bug.cgi?id=2
に似てるっちゃ似てるかも。

でも、ecmascript みたいに Java と同じく } でブロック終了する言語だと
対応とるの大変そうだなとか思った。その辺は EL だと楽だけど。
620 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 21:34:43 ]: ヒアドキュメント＋式言語ってのが良さそう
Velocityが標準になるみたいな感じだが。
621 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 22:29:53 ]: >>616
要は、今の仕様で

private int xxx;

というフィールドと

public int getXxx()

というメソッドが混在できる以上、フィールドの延長上のプロパティと
getter/setterの延長上のプロパティとは相容れないわけだ。

いまのキモいJavaBeansのgetter/setterはプロパティとはなんの
関係もないことにすりゃ、それで解決すると思うんだけどね。
622 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 22:49:49 ]: >>621
> いまのキモいJavaBeansのgetter/setterはプロパティとはなんの
> 関係もないことにすりゃ、それで解決すると思うんだけどね。

仮に、それをやっても「解決する」のは言語仕様の問題だけで、
ライブラリ＆フレームワーク＆ユーザーコードの方に問題を押し付けてるのような。
それなら、ぶっちゃけ新しい言語作っちゃった方が速いと思う。
623 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 23:18:12 ]: >>622
上の方でだれか言ってたけど、フレームワークのプロパティとは無関係な「Java言語プロパティ」
を作ってもいいんじゃないか。紛らわしいなら名前は変えてもいいけど。
そもそもなんでプロパティ構文が欲しいんだ。ドットネットが羨ましいんだろうか。
624 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 23:24:53 ]: >>622
「問題」って、どんな問題かな？
別に既存コードの変更が迫られるわけじゃないっしょ？
625 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 00:09:08 ]: >>623
むしろstructが羨ましいんじゃないか？
626 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 02:48:40 ]: >>624
互換性を確保しつつ新プロパティを使おうと思ったら、
既存のプロパティと、新プロパティの両方管理しなきゃいけなくなる。
二重のコストを払う必要が出るんだから、普通は問題になる。

おまけに、フレームワークやライブラリが二重のコストに耐えかねて
既存のプロパティを捨てたら、やっぱり既存のコードを書き換える必要が出る。
直接コードの変更を迫ってないだけで、間接的にコードの変更を迫ってる。
627 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 07:18:35 ]: >>626
プロパティが導入されたからといって、既存のコードを無理に
対応させることはないでしょ？別物なんだから。

それに例えば、ジェネリクスが導入されたとき、それに対応して
書き換えられたフレームワークはあったし、もちろんそれを利用
しているユーザーコードも書き換えられることがあったけど、
それは別に変更を余儀なくされて行ったわけじゃないよね？
628 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 07:52:01 ]: >>627
> それに例えば、ジェネリクスが導入されたとき、それに対応して
Generics の場合は「JavaBeans とは無関係なプロパティ」導入と違って、
例えば Collection フレームワークを Generics対応に書き換えたら、
互換性が完全に無くなるってわけではなかったけど、
「JavaBeans とは無関係なプロパティ」の場合は、
「JavaBeansのプロパティ」のサポートをうちきれば互換性が無くなるし。

例えるなら enum の方が近いな。int enum と typesafe enum の両方を提供してるAPIがあって。
それにはコストがかかる。int enum だけ、typesafe enum だけを提供してるAPIもあるけど、
プロパティの場合は影響範囲も、統一的に扱う必要性も enum の時より大きいから
両方の提供がより大規模に起こるのは容易に想像できる。

「JavaBeansのプロパティ」と「JavaBeans とは無関係なプロパティ」は共存可能って話なんだろう？
互換性維持のためには「JavaBeansのプロパティ」が必要で、
新機能対応のためには「JavaBeans とは無関係なプロパティ」が必要で、
それを両方管理しようとすりゃコストはかかる。問題になるだろ、普通は。
629 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 08:10:26 ]: 定義はgetter/setterで行って、呼び出すときだけプロパティみたいにも使えるようにするのじゃダメ？
例えば、p=a.getXxx()をp=a.xxx、a.setXxx(p)を a.xxx=pとか。
630 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 08:37:50 ]: >>629
それだと dot でやるのが面倒。

既存の getter/setter に使われてる「プロパティの名前」と
同名のフィールドが存在可能だから。
631 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 08:39:25 ]: >>628
そのコストってのもフレームワークの作者とかはともかく開発者は関係ないね
632 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 08:44:16 ]: >>631
何より、無駄にバグのリスクが増えるし、
標準APIとかでドキュメントの翻訳に時間がかかるようになるとも考えられるね。
633 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 08:45:07 ]: >>631
開発者というより、末端ユーザだな
634 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 09:10:34 ]: >>629
a.xxx と同名のフィールド a.xxx があった場合、扱いが面倒。

互換性を考えるなら >>611 あたりのルールが落としどころかとも思うけど、
public な同名のフィールド使えば、プロパティに触れなくする事ができたりするし、
完璧とはいいがたい。

言語仕様に書く文言も相当慎重に選ばないと、
デフォルトパッケージのクラスが import 出来なくなったみたいに、
言語仕様の文言から副作用がでる可能性も……
もっとも、import の方は意図しない副作用なのか意図的なものか、
ちゃんと知らんのだけど。
635 名前：デフォルトの名無しさん [2007/03/14(水) 12:24:27 ]: マルチコア対応は言語に乗っかるのか、VMに乗っかるのか・・・
636 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 12:37:32 ]: >>627
Genericsは、既存の一般コードに関しては意味の変更なく使えたぞ
>>632
さすがにそのコストを考えるのは臆病すぎｗｗｗ
>>635
マルチコア対応って一体何なのか分からない。

なぁ、何でみんなdotにこだわるの？
別の記号にして、定義も全く別にすればスッキリ導入なんだけど？
バイトコードは拡張しないと駄目だろうけど。
637 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 12:48:08 ]: >>636
> 別の記号にして、
dot 以外の記号はキモイから嫌らしい。

> 定義も全く別にすれば
既存の資産と協調して使えないので、導入しても嬉しさ半減。

> バイトコードは拡張しないと駄目だろうけど。
バイトコード拡張は必要ないでしょ。
クラスファイル仕様は弄るかもしらんけど。
638 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 12:50:02 ]: >>635
マルチCPU対応のVMだったら、マルチコアもそのまま使えるんじゃない？

ってか、マルチコア対応を言語にのっけるってどーやるんだ……
639 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 13:13:07 ]: そういやRhinoのLiveConnectは実装側で拡張されててJavaObjectのゲッタ(getXxx)・セッタ(setXxx)にJavaScriptObjectのプロパティ(xxx)からアクセス出来たな。
JavaBeans使ってたんだろうか？

結局JavaScriptObjectのプロパティからアクセスしようとした時JavaObject側にxxxってフィールドがあると衝突して使い物にならないから
LiveConnectには元々ない後付けされた機能なんて不完全だって言われてたな・・・。

オライリーのサイ本にも指摘されてたような。
640 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 13:39:56 ]: >>626
阿呆だな。もっと簡単な問題があるよ。

>>624
JavaBenas のプロパティと別のプロパティなわけでしょ？
標準API とかの既存の interface に abstract な property を追加したら
既存のコードの中で、そのinterface を実装してて JavaBeans とは別のプロパティを
実装してないクラスがあれば、互換性に問題が出る。
互換性に配慮したら interface に迂闊にプロパティ追加できない。

それだと、たぶん使い物にならない。
641 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 13:48:02 ]: >>627
具体的に言えば java.beans.DesignMode にプロパティ追加して
interface DesignMode {
　public static final String PROPERTYNAME = "designTime";
　boolean isDesignTime(); void setDesignTime(boolean f);
　public abstract property designTime;
}
とかすると、既存の
class MyComponent implements java.beans.DesignMode {
　private boolean designTime;
　public boolean isDesignTime(){ return designTime; }
　public void setDesignTime(boolean f){ designTime = f; }
}
みたいなコードを書き直す必要がある。

DesignTime とかだけならともかく、他の interface も property の追加に関しては慎重にならざるをえない。
よって interface で property にアクセスできない事が多くなる。
JavaBeans のプロパティと別の新プロパティを導入しても、
あんまし使い勝手がよくないだろうね。
642 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 14:10:45 ]: なるほどいろいろ問題があるな。
結局 ->案が一番妥当だろう。
プロパティを定義する側はこれまでどおりgetXXX/setXXXを使用する。
プロパティを使用する側はgetXXX/setXXXと->XXXの両方が使える。
フィールドにXXXがあっても問題なし。
しかし、この程度のものならいらないな。
643 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 15:29:22 ]: >>642
だよな。
いらないと思うよな。
644 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 15:41:27 ]: あとはgetとsetを対にした定義文もほしいな
645 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 15:47:49 ]: >>641
今Beansで「プロパティ」と呼んでいるものと別物として新プロパティシステムを導入するのだったらその書き換えはいらないよね？
646 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 16:03:21 ]: >>645
だから、>>641 は
> 今Beansで「プロパティ」と呼んでいるものと別物として新プロパティシステムを導入
した場合に発生する問題だってば。

今Beansで「プロパティ」と呼んでいるもの、
要するに setter/getter呼び出す syntax sugar として
accessing properties な構文を入れるなら、>>641 の問題は発生しない。
647 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 16:36:28 ]: >>646
なんで書き換えようとするの？そのままにしとけばいいじゃん。
648 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 16:56:32 ]: >>647
>>641 をちゃんと読め。
649 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 17:45:12 ]: >>648
ちゃんと読んでもわからないです。
何故 interface DesignMode に property designTime を追加してるの？
ひょっとして俺ｽｹﾞｰアホなこと訊いてる？
650 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 18:38:36 ]: > ひょっとして俺ｽｹﾞｰアホなこと訊いてる？
うん。
651 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 22:27:50 ]: >>641
あきれる。
isXXX()/getXXX()をgetterのインターフェースに用いたままプロパティを
実現しようとすることに問題があるから別のインターフェースを採用
しようという話なんだから、その例でinterfaceの方にisDesignTime()を
追加するという仮定自体がそもそもありえないし、仮に追加しても
何の影響もない。
652 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 22:35:24 ]: dot以外の記号がキモイならdot二つのx..hogeでもいいよ。
653 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 23:25:14 ]: >>652
孔明あらわる
654 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 23:56:34 ]: >>651
俺もそんな気がしたんだけど、>>650 だそうです。
655 名前：デフォルトの名無しさん [2007/03/14(水) 23:57:20 ]: 記号でわざわざ入力二回って耐えられなくない？
656 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 00:00:24 ]: 耐えられないなら++も--も使わずにプログラムを書いてくれ。
657 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 00:45:46 ]: // << >> == && ||
↑これらも

つか==なしとか縛りきつくね？
658 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 00:47:52 ]: VBのプロパティとかdotだし、コード上で分かりにくいってことはなかった。
FlashのActionScript(ECMAScript派生)もread onlyプロパティがあったが、dotだね。
dot以外を選択するのは、正直コンパイラ屋の都合でしかないと感じる。
メンバ変数に@PropertyFieldアノテーションを施す程度で妥協して欲しい。
659 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 01:30:43 ]: ちょっと待てECMAScriptは全部プロパティだ
660 名前：デフォルトの名無しさん [2007/03/15(木) 01:32:16 ]: >>656-657
2chらしい模範解答だなｗ
661 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 01:52:21 ]: IDEやJava用エディタならテンプレート機能が充実しているし
そんな構文糖は要らないってのも意見として尊重してほすぃ。
662 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 02:15:35 ]: >>661
どうなんだろ、セマンティクスがハッキリするから
getter,setterが分かりやすくなるという点ではIDEも歓迎なのでは？
実現方法はともかく。
663 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 04:06:26 ]: >>661
コードの読みやすさが上がるのであれば、新しい構文糖の導入も大いに結構じゃないかい？
664 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 07:43:28 ]: >>651
あきれる。

> 仮に追加しても何の影響もない。
そんなは事ない。
665 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 07:47:20 ]: >>651
>仮に追加しても何の影響もない。
追加したら、java.beans.DesignTime を実装している既存のクラスを書き換えなきゃいけなくなるだろう。

影響がないって、馬鹿じゃないのか？
666 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 07:48:08 ]: >>665
× java.beans.DesignTime
○ java.beans.DesignMode
667 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 08:18:45 ]: >>661
java.net/pub/pq/142 とか見ると、
property構文は、XML構文に次いで人気がないんだよね。

java.net/pub/pq/141 とかだと、
very important と、somewhat important をあわせても 1/4 ぐらいだったりする。

まぁ、この手の投票がちゃんと機能してるかはわからんし、
構文糖なら要らないってのと、重要度が低いってのは同じ意見じゃないんだけど。
668 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 08:34:05 ]: >>658
> VBのプロパティとかdotだし、コード上で分かりにくいってことはなかった。
もし問題がないなら dot を使うのに反対の人はあんまし居ないと思うんだが。
同じクラスでフィールドと同名のプロパティが持てる言語を出してきて
わかりにくくないって言うんならともかく。

> メンバ変数に@PropertyFieldアノテーションを施す程度で妥協して欲しい。
それって、何か改善する？
669 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 09:09:07 ]: >>668
> 同じクラスでフィールドと同名のプロパティが持てる言語を出してきて
> わかりにくくないって言うんならともかく。
それなら、同名のフィールドとプロパティが共存できて、
さらにフィールドもプロパティも dot でアクセスする言語がわかりにくくないって言わないと。
（dotじゃなくても良いけど同じ記号でアクセスする言語）
670 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 09:17:17 ]: >>651
> その例でinterfaceの方にisDesignTime()を
> 追加するという仮定自体がそもそもありえないし
……。 isDesignTime() は元からあるメソッドですが。
671 名前：649 mailto:sage [2007/03/15(木) 10:23:39 ]: >>670
おまえ逃げてないで俺の質問に答えろよ。
672 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 10:26:26 ]: >>671
質問になってない。
673 名前：649 mailto:sage [2007/03/15(木) 10:31:39 ]: >>672
答えになってない。
674 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 10:36:21 ]: >>621
それだけじゃ解決しないね。

新プロパティ(dotでアクセス)と同名のフィールドが作れるなら
setter/getterのプロパティと同じ問題が起こるし、
C#みたく新プロパティと同名のフィールドが作れなくするなら、
標準APIが新プロパティを追加したらユーザコードの書き換えが必要になる可能性がある。

これ以降は >>640 >>641 と同じ路線だな。
上記の書き換えを最小限に抑えようとすれば、
標準APIは極力新プロパティを追加しない方向になるだろうから、
新プロパティの構文は言語仕様に定義されたが、
標準APIで新プロパティが使えない、という本末転倒な事態が予測される。

つまり、使い勝手が悪い。
675 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 10:39:07 ]: >標準APIが新プロパティを追加したらユーザコードの書き換えが必要になる可能性がある。
標準APIが新プロパティを追加したら、
そのclass/interfaceを継承/実装して同名のフィールドを使っていたユーザコードの書き換えが必要になる。
676 名前：649 mailto:sage [2007/03/15(木) 10:42:44 ]: やっとわかったよ。お互い説明が下手だと苦労するなｗ
677 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 11:02:59 ]: >>675
まぁ、interface に「新プロパティ」を追加したら、
どっちみちそのinterface を実装しているクラスの書き換えが必要になる。
既存のコードは setter/getter は実装してても、
「新プロパティ」まで実装してて書き換えの必要がないってのは考えにくいから。

この書き換えを最小限に抑えようとすれば、
標準API は、極力 abstract な新プロパティを追加しない方向になるだろうから
以下、>>674 と同文、と。
678 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 11:15:13 ]: > 標準API は、極力 abstract な新プロパティを追加しない方向になるだろうから
標準API は、既存の setter/getter を置き換えるものも含めて、
極力 abstract な新プロパティを追加しない方向になるだろうから

うーむ。既存の setter/getter は互換性のために残す事を想定してるから
置き換える、じゃないんな。まぁ、setter/getter を残しても残さなくても、
標準API に abstract な新プロパティを追加すれば同じだけど。
679 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 20:13:04 ]: ゲーム関係に力を入れてけば自然とデスクトップ周りが強化されるからそっち系だな
OSを選ばないUDIライブラリとか、BGM周りはネイティブにディスパッチとかね。
標準であるかどうかってのがここらへんは大きい。
680 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 22:34:05 ]: まずジョイパットか
681 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 23:05:33 ]: ジョイパッドサポートは地味に大きいな

って10年前からいわれてるが

あとはJOGLも標準ではいってくれるといいのだが
今はプラットフォームごとに用意してあげないといかんからWindows以外はめんどくさい

本当は新世代専用GCコールもほしい
タイミングコントロールできて殿堂入りしないやつならアクション系もバリバリ使える
682 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 00:05:01 ]: >>677
interfaceに追加したらそれを実装するクラスに影響があるのは、
「プロパティ」に限らず抽象メソッドでも同じだわな。

既存のinterfaceに「抽象メソッド」を追加したら他のクラスに影響が出る
↓
だから標準APIに「抽象メソッド」は追加できない
↓
「抽象メソッド」は標準APIに使えないから無意味

あほか。
683 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 00:22:54 ]: >>682
> 既存のinterfaceに「抽象メソッド」を追加したら他のクラスに影響が出る
普通は、既存の interface に抽象メソッド追加するのは慎重にする。

逆に、今までにない interface を作る時は自由に抽象メソッドを定義できる。
> 「抽象メソッド」は標準APIに使えないから無意味
安易に追加できないが、「使えない」とか「無意味」とはならない。

abstract な新プロパティも、抽象メソッドと同じで、
今までにない interface を作る場合は自由に定義できるだろうけど、
既存の interface に追加する場合は慎重にならざるを得ないだろう。
既存の interface 経由で使えない事が予想される新プロパティは
「使えない」とか「使い勝手が悪い」と言える。
684 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 00:26:00 ]: >>683
△既存の interface -> ○標準APIの既存の interface
685 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 01:10:18 ]: java.sql.Connectionなんか増えまくりだった気がするが。
古い実装のを呼ぼうとするとErrorでも出るかな
686 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 01:11:37 ]: >>683
既存のinterfaceを安易に拡張できないってのは当然だね。

>既存の interface 経由で使えない事が予想される新プロパティは

なんで新プロパティに限って既存のinterface経由で使われることを
期待されなければならないんだろう？
687 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 01:16:08 ]: >>682
> だから標準APIに「抽象メソッド」は追加できない
> ↓
> 「抽象メソッド」は標準APIに使えないから無意味
ここで飛躍してる。基本的には「追加できない」==「使えない」とはならない。

で、setter/getter とは無関係な新プロパティシステムを導入したとして、
その新プロパティを、標準APIの既存の interface で使いたいと言う場合は
・新プロパティを追加すれば、その interface を実装していたコードを変更する必要が出る。
・逆に新プロパティを追加しなければ、標準APIの既存の interface では新プロパティは使えない

で、俺は標準APIの管理者は後者を選択すると予想するので、
その場合は新プロパティは「標準APIの既存の interface経由では使えない」ので
使えないとか、使い勝手が悪いと言えるだろう。
仮に前者を選んだとしても、コードの変更を迫られるので無問題とはならない。
688 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 01:23:35 ]: >>686
> なんで新プロパティに限って既存のinterface経由で使われることを
> 期待されなければならないんだろう？
限って？他では期待されてないんだっけか？
689 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 01:27:18 ]: >>688
限ってないよな。Closure だって、Closure Conversion とかで
abstract なメソッドが一つだけの既存の interface に変換する事を考えてたりするし。
690 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 01:48:55 ]: blogs.sun.com/ahe/entry/java_se_7_wish_list のリストとかを見るに、
たいてい inteface と関係ないか、既存の interface との協調にも配慮してあるよーな。
691 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 05:18:23 ]: >>681
新世代・・・・ああああNewGeneration用のGCってことか。
いや、殿堂入りが無いというより、tenureの32をいじれるようになった方がいいかな。

ある程度、コア数が増えて並行処理が速くなると、OldGenerationを少なくして
Newgenerationのtenureを32回より多くして、NewGenerationで運用したほうが
効率いいと思うんよねぇ。
昔、24CPUのマシン使った時、10GB程度のNewGenerationをParNewGCかけてたけど
確か0.5s程、ホンの一瞬だった。
692 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 07:42:00 ]: >>688
class定義に影響する新機能としては例えばfunction-typeなんかがあるけど、
じゃあこれは既存のinterfaceに追加されて使われることを期待されてるの？
693 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 08:53:05 ]: >>688
対抗馬である setter/getter の syntax sugar なプロパティなら
既存の interface経由で使えるしな。

それと比較しても「使い勝手が悪い」といえるだろうね。
694 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 08:53:44 ]: >>692
具体的に、どんな問題が出るんだ？
695 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 12:35:00 ]: >>691
並列GCはデフォの状態よりスループットはいいけどレスポンスが大幅に悪化するぞ
あとGC稼動のタイミングをコントロールできる10msのGCとコントロールできない0.1msのGCだと前者のほうがいいわけで
696 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 13:50:53 ]: >>695
今のマシンスペックならGCに0.1msもかからんよ。

ゲームならヒープサイズとスタックサイズの調整で2Dまでならストレスなく遊べる。
やっぱメモリ食いは収まらないけど。

取り合えずただのデスクトップツールとしては実用的じゃない？

ジョイパッド拾えるようになると同じ方向性で障害者用の入力補助装置の入力拾えそうでアクセシビリティ周りが格段に良くなって良いと思うけどな。
697 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 14:15:04 ]: >>686
GCの時間はヒープサイズに綺麗に比例するのでなんともいえないよ

最近のマシン持っているけど0.5msきることは実際にゲームつくっていてまずない
新世代領域を少なくしてやっと0.2mくらいか

インクリメンタルGC（現在の実装は並列GC）だとレスポンス悪化してるし、
デフォのGCだとFullGCがいつかは必ず起きるし、おきたら使い物にならない

そもそもJava2DやJOGLなどライブラリによるGCはコントロールできなから
自分のコードでの調整は何も意味がない

0.1mが0.05mであっても同じこと

リアルタイム性ってのは早いかどうかじゃなく、コントロールできること、把握できることだから
698 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 15:41:40 ]: >>571
まるでApache Antの記法だな
699 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 15:42:31 ]: >>572
四項演算子か。

Checkstyleプラグインが警告しそうだな
700 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 19:54:46 ]: >>693
既存のinterfaceに public int getHoge(); なんて追加したら
おんなじように「問題」は発生するが？

>>694
何の問題も出ないだろう。既存のinterfaceに追加したりしなけりゃ。
701 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 20:14:48 ]: >>700
setter/getter の syntax sugar なプロパティであれば、
既存の interface で、既に宣言されている setter/getter で
プロパティにアクセスする分には問題は発生しない。

setter/getter と関係のない新プロパティシステムを導入した場合、
既存の interface で、既に宣言されている setter/getter ではプロパティにアクセスできない。
で、標準API みたいに変更すると影響範囲が大きい既存の interface は安易に変更できないから
新プロパティを追加したくても既存の interface には追加できず、
既存の interface からは、この新プロパティは使用できない可能性が高い。
故に setter/getter の syntax sugar よりも「使い勝手が悪い」といえる。
702 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 21:11:41 ]: 相変わらず説明が下手だな。
703 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 21:19:01 ]: さすがに読解力に問題があるだろう。
704 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 22:07:53 ]: >>701
>既存の interface で、既に宣言されている setter/getter ではプロパティにアクセスできない。

既存の「getter/setter」と関係ないプロパティが前提なら、当然既存のinterfaceにも
存在しているわけがないだろう。ここでアクセスしようとしている「プロパティ」ってのは
何のことを言っているんだ？
もし「getter/setter」のことならば、それはプロパティとは関係のない単なるメソッドだから、
普通にメソッドとしてアクセスすればよい。
もし新たにプロパティを追加することを想定しているのならば、それはインターフェースの
拡張に他ならないから、他に影響が出るのは当然。それは別にプロパティに限らない。
705 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 22:18:48 ]: >>704
> ここでアクセスしようとしている「プロパティ」ってのは
当然、setter/getter と関係ない新プロパティシステムのプロパティ。
で、プロパティの持つものは、既存の setter/getter で表わされるのと同じもの。

プロパティ導入の大きな動機の一つに、setter/getter を宣言するのも、
呼び出すのも冗長だという不満を解消するというものがある。
setter/gettter とは別の新プロパティシステムを使えば、
既存の interface にある、既存の JavaBeans のプロパティに対して、
setter/getter を呼び出すのが冗長だという不満を解消できない。

仮に Tiger で追加された Generics が、もし仮に既存の Collection API と協調できず、
List でも Map でもパラメタ型を取れなければ、使い勝手が悪いと評価されるだろう。
それと同じ。
706 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 23:00:03 ]: あはははは。
foo.getBar()がfoo->barになっただけでどんな不満が解消するんだよ。
707 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 23:07:26 ]: 流れぶったぎるがJSR-296使ってみた奴居る？
708 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 23:08:42 ]: >>706
なら、なんでプロパティが必要なんだ？

それに、最初出てきた案は setter/getter の syntax sugar なんだぜ？
709 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 23:18:32 ]: >>703
わかってもらえない場合は、別の角度からの説明を試みるべきだと思う。

>>706
だよな。いらねーよな、こんなプロパティもどき。初心者が混乱するだけ。
710 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 23:22:40 ]: >>709
普通は説明されなくてもわかるだろ。あんなの。
気づかない方が頭がおかしいんだよ。
711 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 23:35:01 ]: >>710
「普通」とか言うけど、「使い勝手が悪い」っていう結論は主観が入り込んでるだろ？
712 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 00:10:42 ]: ->で全然問題なし
713 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 00:25:29 ]: JavaBeans のプロパティと同名のフィールドを持てる事が問題ってところから
>>621 で
> いまのキモいJavaBeansのgetter/setterはプロパティとはなんの
> 関係もないことにすりゃ、それで解決する
という意見が出た。
新プロパティシステムを作れば、フィールドと同名のプロパティを禁止できるからって話なんだろうけど、
>>674 のような問題も予想されるため、完全な解決とはならない。

結局、限定名のルールとかフィールドアクセスのルールが
ぎちぎちに詰め込まれているので dot でフィールドにアクセスする事と、
dot でプロパティにアクセスする事が相容れないと考えた方が良いみたい。

それとは別に、>>640、>>641 で言ったように setter/getter とは別の新プロパティシステムを導入する場合、
setter/getter の syntax sugar ならプロパティとしてアクセスできた情報の一部に
プロパティシステムを使ってアクセスできない事が予想される。

結局、「setter/getter とは別の新プロパティシステム」を導入しても
setter/getter のsyntax sugar で問題とされた事を解決できず、
さらに setter/getter の syntax sugar では出なかった問題も発生する。
まぁ、「setter/getter とは別の新プロパティシステム」の詳細を見ての評価じゃないけど
現在の情報からなら setter/getter の syntax sugar より「使い勝手が悪い」と言える。
714 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 00:28:20 ]: >>713
どうでもいーけど長文ウザイ
715 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 10:20:14 ]: 説明が下手なんだからしょうがないよ。
716 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 10:22:41 ]: 説明されなくたって、既存のプログラムに新機能を追加して、
どんな影響が出るかを予見できないってのは技術者として拙いだろ。
717 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 10:30:57 ]: じゃあレスする必要ないじゃんｗ
なんで一生懸命説明してんの？
718 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 10:33:03 ]: >>716-717
次世代Javaと関係ない話題だな。続きは他所行ってやれ。
719 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 12:59:19 ]: >>718
たった2レス程度で…気が短いな
720 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 16:16:28 ]: >>713
結局、getHoge()/setHoge()を使わない新プロパティシステムを導入しても、
既存のgetHoge()/setHoge()を使えないから使い勝手が悪いということかw
721 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 00:14:19 ]: ふー、びっくりした。でも、反対派の意見はほぼ一点に集中している。
プロパティは既存の言語機能と干渉するから、導入の必要はないというもの。
それ、ほんとなのかなあ（ｒｙ
722 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 00:44:26 ]: サイレントマジョリティの声を尊重してプロパティを導入することにしました。
当然のことだよね
723 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 00:51:13 ]: >>721
既存の言語機能と干渉とかいう以前に、そもそも「そんなに必要な物なのか」って
ことがまずあるんじゃないか？

プロパティの仕組み導入の話が出てるのは、
「定義するのも使うのも既存のgetter/setterの仕組みだとめんどくさい」
という要望から来てるんだろうけど、
「めんどくさい」っていう理由だけで言語仕様変えてったらとんでもないことになる気がする。

相当面倒、ってのが、すごく簡単ってなるならまだ納得できなくもないけど、
IDE使ってる人の中にはgetter/setterがそこまで面倒とは思わない人もいるんじゃないかとも思う

ちなみに個人的にはgetter/setterの使用側は今のままで十分。
ただ、定義するのが面倒だから、アノテーションとかで自動でデフォルトのgetter/setterが
作成される仕組みができるぐらいでも満足だよ。
724 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 02:14:53 ]: a = obj get foo;
obj set foo = 1;
725 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 08:54:34 ]: >>722
>>667 の結果を見るに、
プロパティ要らないって意見の方がサイレントマジョリティで、
プロパティ欲しいと言ってる方が、声の大きい少数派。
726 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 11:47:22 ]: >>721-722はネタなんで相手しなくていいです
727 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 12:23:09 ]: >>724 はネタじゃないのか……
728 名前：724 mailto:sage [2007/03/19(月) 20:34:17 ]: >>727
ネタです。
729 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 23:15:19 ]: >>723
うむ。
プロパティ自体は特にそんなに欲しいものでもないが、自分で開発していて
コードの半分以上が意味のないgetter/setterで占められているクラスが
山のようにあるのを見ると、何かが間違ってる気がしてならない.。
730 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 23:21:52 ]: あるBeanのプロパティ値ともうひとつのプロパティ値を足し算してその結果を格納とかめんどくさすぎ
同様にBigDecimalの演算もきっつい
731 名前：デフォルトの名無しさん mailto:sage [2007/03/20(火) 00:51:51 ]: >>730
プロパティに足し算して格納とかってそんなに使う？
俺、WEB開発系がメインだけど、プロパティに対して加算とかって
ほとんどしたことないし、BigDecimalも使ったことない。

きっとプロパティが必要な分野と、たいして必要とされない分野があるんだろうな。
732 名前：デフォルトの名無しさん mailto:sage [2007/03/20(火) 01:17:10 ]: getHoge()がめんどくさいから->でやらせろって言ってる人は、
やっぱりadd()がめんどくさいから演算子オーバーロード使わせろ
とか言うのかな。
733 名前：デフォルトの名無しさん mailto:sage [2007/03/20(火) 02:00:33 ]: BigDecimalは業務系はこれしか使わないというくらい使う
BigDecimalだけはStringのようにシンタックスシュガーとしてaddとかやってほしいな

プロパティの足し算引き算ってのは普通にあるっしょ
金額とか在庫とかいくらでも
特にO/RマッパやBeanBinding関係使うと頻発
734 名前：しろうと mailto:sage [2007/03/20(火) 09:36:43 ]: public class Foo {
　　public int bar;
}

じゃだめなん？
735 名前：デフォルトの名無しさん mailto:sage [2007/03/20(火) 10:15:22 ]: セット時やゲット時に加工が出来ないからダメ
それに定義のほうはどうにでもなるためたぶん問題になってない
736 名前：デフォルトの名無しさん mailto:sage [2007/03/20(火) 22:24:23 ]: VMがグリッドコンピュータに対応するのはいつだ？
737 名前：デフォルトの名無しさん mailto:sage [2007/03/20(火) 22:34:18 ]: VMがグリッドコンピュータのネイティブな基盤になればいいのに。
738 名前：デフォルトの名無しさん mailto:sage [2007/03/20(火) 22:38:44 ]: 設定がないと動かないJVMは面倒だな。

グリッドとかは、アプリケーションの下で何らかのグリッド制御部が
動いていて、JVMのリソースとしてグリッドが見えるって前提だろうから
MVMが実現して、アプリケーションの起動とJVMの起動が分離するまでは
あんまり興味がないね。
739 名前：デフォルトの名無しさん mailto:sage [2007/03/20(火) 23:23:42 ]: クラスタ用OSとしてのJVMなら
BEAだかが仮想化技術として構想を発表してたはず
740 名前：デフォルトの名無しさん mailto:sage [2007/03/20(火) 23:27:12 ]: >>738
グリッドが見えるのを前提にする必要はないでしょう。
HotSpotが全自動で動的最適化を行うように
グリッド制御部が全自動でスレッド分散を行うのが
あるべき姿だと思います。
741 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 22:20:18 ]: JDK7 build10
download.java.net/jdk7/changes/jdk7-b10.html
download.java.net/jdk7/binaries/

NewFeatureは地味なパフォーマンス向上と
getAsText,setAsTextか。これはちょっと嬉しいな。
742 名前：デフォルトの名無しさん mailto:sage [2007/03/25(日) 05:37:51 ]: グリッドより先にjavacがメニーコアをフルに使用するための中間コード
を生成することになることが重要。
PGがthreadを手書きしてでしか対応できないというのではコストがかかりすぎる。
743 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 13:15:00 ]: プロパティの話に戻りますが、
やっぱ、何か明示的にプロパティを示す構文がほしい。
と思ったのは、eclipseでリファクタリングするとき。
getter側をリネームしたら、setter側も変わってほしいし、名前の定数も変わってほしい。

public static final string PROPNAME_XXX = "XXX";
public Object getXXX() { ... }
public void setXXX() { ... }
の三者の一貫性を、自動的に保ちたい。
なんか、アノテーションつけとくと、eclipseが、それをヒントに一括リネームしてくれる
だけでもいいんだけど。
744 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 14:16:16 ]: それはプロパティ構文あってもなくてもあんまり変わらないのでは。
745 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 14:25:33 ]: >>743
getter/setter はまだしも、
> public static final string PROPNAME_XXX = "XXX";
の必要性が良く分からん。
746 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 14:42:25 ]: 俺もその部分が？だな
名前だけで型がないし、そもそも型が要らないならenumでいいし
まさか、文字列の中身がクラス名とか
747 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 15:40:52 ]: >>745
>>746
プロパティ名を変えるときに、プロパティ名の文字列リテラルがソース中に散らばってると、
修正がめんどくさいから。
IDEの完全一致文字列リテラルの置換でできなくはないけど、"item"、"count"なんてプロパティ名
だと、無関係な文字列に誤爆するかもしれん。
748 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 17:01:43 ]: >>747

＞修正がめんどくさいから。

得てしてこういう理由で出てくるワークアラウンドは
引きずらない方がいい悪習慣である可能性が高い
749 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 18:19:33 ]: >>748
いや、一つの識別子をソース中に書くのは1回で、あとは参照に置き換えるってのは、
コードのメンテナンス性を保つ上で、ものすごく基本的なことだと思うが。

getXXX, setXXXというメソッド名は、XXXというプロパティ名に従属する識別子なんだから、
ソース中の1箇所の変更で、全てが整合性を保った状態で変更されるのが理想。
C#では、それを文法で強制している。javaでは、整合性の保持はプログラマ任せ。
プロパティ名変更する度に、getXXX、setXXX、firePropertyChangeの引数、全て変更って、
バカバカし過ぎる。せめて、IDEに面倒みてもらいたい。
YYYListener、addYYYListener、removeYYYListenerも、相互に関連する名前なんだから、
ソース1箇所の変更で全てが修正される方が望ましい。
これも、C#ではeventで実現できるが、javaはプログラマ任せ。

javaは保たれるべき一貫性の保持を、文法で強制するんじゃなくて、守るべき
ルールとして与えてるだけなんで、そのルールが守られることのチェックを、アノテーションでできてほしい。
addYYYListenerにしても、
@AddListenerMethodFor(YYYListener.class)
void addYYYListener(YYYListener listener) {}
みたいにして、名前の整合性がなかったら、コンパイラで検出できるようにすべきだと思う。
IDEではYYYListenerをリファクタリングでリネームしたら、addもremoveもリネームできて、ほしい。

javaは、識別子の命名ルール関係で、コンパイラでは検出できないけど、
守られていないと正しく動作しない決め事が結構ある。
そのあたり、アノテーションでバンバン検出できるようになると良いんだけど。
750 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 19:16:31 ]: C#は詳しくないが、プロパティ名を変更したとき、
そのプロパティを実際に使用している箇所の変更は不要なの？
751 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 19:26:01 ]: private int myVar;
public int MyProperty {
get { return myVar; }
set { myVar = value; }
}
752 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 21:00:03 ]: >>749
> getXXX, setXXXというメソッド名は、XXXというプロパティ名に従属する識別子なんだから、
これも別の概念なんだよね。BeanInfo や PropertyDescriptor を自分で書いてる人は
hoge って名前のプロパティで、void hoge(Object) を setter に、Object hoge() を getter に指定する事も出来るし。
もっとも、真面目に BeanInfo 見てないフレームワークだとプロパティと認識してくれないかもしれんけど。

> バカバカし過ぎる。せめて、IDEに面倒みてもらいたい。
ここは同意なんだけど、IDEで吸収するのか、言語/コンパイラで吸収するのかってのもあるし。
とりあえず、現状だと言語/コンパイラのレベルで BeanInfo 扱うのは面倒っぽい。

例えば、今コンパイルしようとしてる Hoge.java の BeanInfo を扱うのが面倒。
PropertyDescriptor の getWriteMethod とか getReadMethod とかで、
まだコンパイルされてない Hoge.class の java.lang.reflect.Method 取るっても取れないだろうし。
これがないと、プロパティ名を getter/setter に変換できないし。
753 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 23:03:02 ]: >>747
それはわかるが>>743のコードはカス
>>751のようにすべきかと
754 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 23:15:07 ]: >>743
PROPNAME_XXX って firePropertyChange 関連以外で使う？
755 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 23:48:38 ]: >>751
C#構文をそのまま持ち込んだらこうなるな。
欲を言えば、myVarとMyPropertyの関係(というか変数実体についての記述)を
何らかの形で示すことができて、省略時はデフォルトsetter/getterが呼ばれる
ようにできたらとC#より便利になると思うんだけどね。
つまり、アクセスをフックしたり禁止したりする場合だけ明示的に記述する。
＃C#の場合はgetter/setterを省略した場合はアクセス不可
756 名前：デフォルトの名無しさん mailto:sage [2007/03/27(火) 00:42:52 ]: プロパティと変数なんて一対一になるとは限らないじゃん。
757 名前：デフォルトの名無しさん mailto:sage [2007/03/27(火) 01:14:48 ]: もちろん絶対必要というわけじゃなくて、プロパティの型と同じ、実体となる
フィールドを指定すること*も*できるってんならいいんじゃない？
758 名前：デフォルトの名無しさん mailto:sage [2007/03/27(火) 08:18:58 ]: プロパティなんぞいらん。糖文増やしてどうすんだよ。
759 名前：デフォルトの名無しさん mailto:sage [2007/03/27(火) 12:29:55 ]: >>751みたいなので普通にいいんじゃね？
getとsetのメソッドやら先頭を大文字推奨、プロパティとしては小文字扱いとか
現状のほうがややこしいだろ
getとsetがばらばらにおかれることによって見通しが悪くなる場合もあるし
リファクタリングの問題もある

プロパティ名としてマルチバイトキャラ埋め込んだ場合の話とかもあるし

現状のままが最悪だよ
760 名前：デフォルトの名無しさん mailto:sage [2007/03/27(火) 13:44:08 ]: >>751
そっから .NET に倣って、 set_プロパティ名 get_プロパティ名ってメソッドに展開される、と？
761 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 02:49:13 ]: private int myVar;
public get int myProperty() {return myVar;}
public set void myProperty(int value) {myVar = value;}

JavaScriptライクにこれでおｋ。
762 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 05:11:32 ]: getとsetを予約語にせずに実現できるならね。
763 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 05:31:48 ]: 予約語にしたらまずいん?
764 名前：デフォルトの名無しさん [2007/03/30(金) 05:45:23 ]: getやsetを変数名とかに使ってたらどうするんだよ？
765 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 05:49:20 ]: そんなに互換が大事ならシンタックスシュガーなんていらないだろｗ
むしろIDEに機能として組み込めよ
766 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 07:07:49 ]: >>764
5.0になったときも非互換変更あったじゃん
そのためにコンパイラの文法バージョンを指定するオプションがあるんでしょ
767 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 07:33:32 ]: @prop(setter="on",getter="on")
private String str;
で
XX.setStr("A");
XX.getStr();
がコンパイルとおる、でなにがいかんのかと（ry
768 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 09:52:12 ]: >>764
@Set、@Getにすればいいよ。
769 名前：デフォルトの名無しさん [2007/03/30(金) 11:45:38 ]: ブロックにアノテーションつけられないんじゃないっけ
770 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 11:54:29 ]: @getter("getValue");
@setter("setValue");
private String value;

これでいーよ。
771 名前：デフォルトの名無しさん [2007/03/30(金) 11:56:08 ]: ブロックとは？
772 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 12:12:16 ]: objective-pascal 方式

@setter("__value") @getter("__value") public String value;
private String __value;
773 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 14:36:20 ]: >>761
に一票。
assertだって使ってた奴いたんだから構わんよ。
というか、get、setっていう変数はなさそうだし、あとに何も付かないset,getメソッドも
そんなに無いだろうからいいよ、それで。
774 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 14:55:04 ]: >>763
予約語にしたら set get が変数名、フィールド名、メソッド名、クラス名等々に使えなくなる。

>>773
java.util.List#get(int) java.util.List#set(int, E)
java.util.Map#get(Object)
これだけあれば影響力十分だよなぁ……
いくら互換性を軽視したって言っても、流石にシャレにならんと思うぞ。

俺なら >>761 の文法なら予約語にしない方を選ぶけど。
ってか、そもそも >>761 って set get つける必要あるのか？
775 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 19:29:56 ]: >>751
のほうがまとまってていいな
776 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 19:35:36 ]: 新記法のプロパティ定義は使い勝手が良くないから駄目だって、
説明の下手なおじさんが上の方で散々教えてくれてるのに。
777 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 21:55:01 ]: >>751みたいなC#方式はvalueが予約語になるのが個人的には嫌だ。
778 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 22:12:44 ]: >>777
C# みたいな文脈依存の予約語なら、value が使えないのは set {} 内だけだし。
779 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 22:32:27 ]: 別にそのままにしてなくてもいいだろ
private int myVar;
public int MyProperty(value) {
get { return myVar; }
set { myVar = value; }
}
とか
780 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 22:45:47 ]: > public int MyProperty(value) {
……。そっちに付けるか
781 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 23:50:18 ]: こんな案もあるんだから、もっとアノテーション使いまくりでいいんじゃねぇの？
今のアノテーション仕様にとらわれる必要はないよ。
journal.mycom.co.jp/articles/2006/11/01/jsr308/
782 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 00:02:40 ]: アノテーションでコンパイル制御できるようにならんかのう。
ディレクティブは邪道だから駄目か
783 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 00:50:04 ]: >>776
説明だけが下手なんだったら良かったが、論理展開も
おそらく頭の中も下手だったからな。
784 名前：デフォルトの名無しさん [2007/03/31(土) 06:33:25 ]: 日本語でおｋ
785 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 10:08:46 ]: >>779
これ今の文法だとgetの後に;が無いって怒られるじゃない
普通のメソッドの中でも {}　でスコープを制限する記法があるから
やっぱ普通のメソッドじゃないという何らかの記述は必要。

>>751 に加えてsetの後に引数記述付けたらいいんじゃないか？

で、この書き方の場合はアノテーションじゃなくて
propertyとかいう新しい予約語使うのがいいな。
メソッドは文法が違うんだから。

アノテーションは、あくまで付加的な情報であって
文法の指定であって欲しくはない。
786 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 11:32:15 ]: >>782

コンパイル制御させたら地獄のIFDEFの復活になりそうなんだが…。
787 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 12:43:15 ]: >>786
でも C# には ConditionalAttribute あるよ
788 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 13:54:10 ]: >>785
プロパティ構文実装しようとしてる時点で
現行の文法でとおらないというのは意味のないことだな

propertyの予約語に関しては影響範囲はたぶんenumよりは少ないと思う
enumはつかわれまくってたからなぁ
789 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 16:09:44 ]: >>787
過去の言語を十分に研究して作成した言語でも言語設計の失敗はある。
790 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 16:13:51 ]: C♯には #if もあるわけで
791 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 16:55:34 ]: >>785 >>788
ちっとは勉強した方が……

blogs.sun.com/ahe/entry/java_se_7_wish_list
の Shorthand syntax for declaring properties のところに、
この構文なら property はキーワードにする必要が無いって書いてある。

weblogs.java.net/blog/forax/archive/2007/01/a_property_prop_1.html
の prototype-1.7-b05.jar 試してみれば分かるけど
property を言語全体に影響する予約語にする事無く、property でプロパティの定義させてる。

常に予約語にする必要がないってわけじゃないけど、
導入する構文によっては予約語にする必要はない。
もしくは、予約語にしないように導入する構文を慎重に決める必要がある。
792 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 17:00:14 ]: 予約語にしたほうが構文解析が楽とか紛らわしいのがなくなるとかメリットもあるから
単純にはいえんよ
793 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 17:17:48 ]: >>789
なんか一言で失敗作呼ばわりされてしまったなぁｗ
794 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 17:40:08 ]: >>792
「property を予約語にしない」ってのを選択肢として持ってないのは不勉強。
795 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 17:58:51 ]: 勉強厨か
上のほうのget　setも構文解析からだけ考えれば予約語にする必要はないべ
gotoだって使わないが予約語だし、newだって予約語にしなくても本当は使えることは使える
796 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 18:01:38 ]: > 上のほうのget　setも構文解析からだけ考えれば予約語にする必要はないべ
既出。
797 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 20:18:57 ]: >>796
「既出。」だけのレスは2ch不勉強
798 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 23:32:26 ]: propertyっていう変数は、結構使われてると思うけどな。
799 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 11:57:31 ]: >>792
紛らわしさって？

property を予約語にしない場合の紛らわしさって言っても
せいぜい property property が出来るぐらいだと思うが。
800 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 12:05:25 ]: ×property property が出来る
○class property がある時に property property property が出来る

もっとも、>>785 も >>788 も具体的な構文規則も例も書いてないから、
>>785 >>788 の脳内構文で出来るのかは知らんけど。
801 名前：デフォルトの名無しさん [2007/04/01(日) 15:41:45 ]: >>781
前にGenerics使うと長くなるからtypedefいるだろとか言ってたC++信者がいたが
これはほんとに可読性に問題起こしそうだな……
どうにかならんもんか
802 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 15:52:49 ]: >>801
blogs.sun.com/ahe/entry/java_se_7_wish_list

Type aliasing
Shorthand syntax for declaring local variables
803 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 16:57:04 ]: >>802
結局は、独自定義があるとそれによって可読性が落ちるかもしれないから
適用範囲に十分注意ってとこだな
804 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 18:00:26 ]: Ada風に別名を付けるときに元の型から値の有効範囲縛れるように出来ると良いな。

新しい型の有効範囲外だとエラー投げてほしい。

typedef month byte 1...12;

aliasでも良いね。...は->でも良いかも。

alias day byte 1->31;
typedef leapsecond byte 1->60;

キャストは値の範囲が大きい方から小さい方の場合は代入されている値が小さい方で表せる範囲の場合のみ、または小さい方から大きい方。
805 名前：デフォルトの名無しさん [2007/04/01(日) 18:12:17 ]: >>804
それこそアノテーションでいいんじゃないか？
806 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 18:34:49 ]: >804
飽和演算もほしくなるな
807 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 18:52:21 ]: JavaBeansのフィールドやセッターにアノテーションってのが現実的だな
範囲外がきたとき例外出すのか、飽和させるのか、値を変えないのかの判断もいれればグッド
ついでに一番面倒なプロパティリスナのfireも自動でやってほしい
808 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 21:53:14 ]: >>807
その情報を元にWebアプリ側で自動でバリデートやエラーメッセージ出してくれたら最高に楽だな。
809 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 22:05:41 ]: >>808
なんかライブラリとNetBeansでプラグイン作りたくなってきた
GUIとのバインディングでもかなり効率よさそうだしな
810 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 22:41:26 ]: プロパティなど要らぬ！
構文糖・即・悪こそが我々Java厨の共有する唯一の正義ではなかったのか！

それを捨てるというならば、まずtypedefを導入しやがれ
811 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 23:14:33 ]: Genericsは構文糖じゃねーのかよ
生成されるバイトコードはキャスト使いまくりのものと同じだろ
812 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 23:28:04 ]: >>810
そんなもん、EoD とか言って autoboxing みたいな構文糖が入った時点で捨てとるような。
813 名前：デフォルトの名無しさん mailto:sage [2007/04/02(月) 00:10:56 ]: >>811
乙
814 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 11:11:13 ]: >>810
何かいまいち語呂が悪いな

というかtyprdefはねえよwww
815 名前：デフォルトの名無しさん [2007/04/03(火) 19:05:07 ]: そろそろCloneable（何故かスペルミス）が@SafeCloneアノテーションになったりしないかな
ある程度どのように実装しているか表現できればコードチェックのときに便利だと思う。

copy(Cloneable obj)とかif(obj instanceof Cloneable){/*処理*/}とかそういうことは出来なくなるけど……
816 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 19:40:24 ]: いやtypedefは欲しい。
Javaで導入されていないのは、sourceが読みにくくなるという理由だろうけど。
817 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 21:04:57 ]: typedef String MyString;
みたいなのは同じ型の別名を作るだけだから有害だが、
typedef Map<String, List<MyClass<Integer, String>>> MyType;
みたいなのは特別な組み合わせに特別な名前をつけているから有用だと思う。

だから、Genericsありの場合のみtypedefを許すというのはどうだろうか。
818 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 21:12:11 ]: class MyType extends Map<String, List<MyClass<Integer, String>>>{}
819 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 21:31:09 ]: >>816
実態が変わるのならきっついのでは？
Javaはすべてダイナミックリンクなわけで
Stringからchar[]への変更とかIntegerからLongへの変更とか現実的ではないし
820 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 21:38:01 ]: これさー

typedef String MyString;
MyString abc = "sample";

これ、OK にするん？　NG にするん？
821 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 21:44:12 ]: >>818
それでいけるかー

typedefのためだけにファイルいっこつくるのが許容できるかどうかだな
822 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 21:51:09 ]: >>821
逆にファイル一個作らない場合、どのソースファイルに記述するか迷わないか？
ひとつのクラス内でのみ使用するというならいいが。
823 名前：デフォルトの名無しさん [2007/04/03(火) 21:53:30 ]: >>818
擬似Typedefアンチパターン
www-06.ibm.com/jp/developerworks/java/060310/j_j-jtp02216.shtml
824 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 22:27:37 ]: extendsに関してはあまり的を得ているとはいえない批判だな。
公開APIで使うべきではないけど、内部処理で使うには問題はなかろう。
「大規模では・・・」というのも、モジュール境界で使わなければいいだろう。
825 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 22:33:36 ]: >> 820
OKだろ。
826 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 22:59:03 ]: >824
当を得る、的を射ると書こうと思ったが
"的を得る"もあながち間違いとはいえないらしい
827 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 23:09:14 ]: >>820
そんなん言語仕様作ってる連中が居るところで聞かなきゃ意味がない。

どーせやるなら generics のパラメタ型だけじゃなくて
JSR 308 の型へのアノテーションも含めて欲しいけど。
828 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 23:35:42 ]: typedef派の諸君！ Java7で何かが変わると思ったら大間違いだ！
所詮dolphinなんか、property派のお祭に過ぎない！
我々typedef派にとってdolphinほど馬鹿馬鹿しいものはない！
多数決で決めれば、property派が勝つに決まってるじゃないか！
829 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 00:16:01 ]: 俺は言語使用云々よりもMVMが最も重要だと思う。
MVMさえ実現されれば、デスクトップJavaもサーバJavaもかなりの勢いで道が開ける。
830 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 00:44:35 ]: 俺もそうは思うが、MVMって実装される予定はあるのか？
831 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 01:12:55 ]: >>828
俺はビビらない

もうちょっと上手くやってください

>>830
俺がずっとヲチしてるとこは年単位で動きナス
ttp://research.sun.com/projects/barcelona/
ttp://java.sun.com/developer/technicalArticles/Programming/mvm/
唯一怪しげな情報として引っかかってきたのが
ttps://jvmcomm.stage.dev.java.net/
ここによると、MVMは作られた、とのこと。
もしかして、通常権限だとアクセスできない
ttps://mvm.dev.java.net/
に何らかの情報が？誰か触った事のある奴居ないっすか？
832 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 08:41:27 ]: >>823
いい記事を知った
㌧
833 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 09:33:04 ]: >>828
クロージャー祭りなワケですが。
834 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 11:59:58 ]: 諸君！この言語は最悪だ！
プログラミングだとかコンピュータだとか、
私はそんなことには一切興味がない！

あれこれ改変して問題が解決するような、
もはやそんな甘っちょろい段階にはない！
こんな言語はもう見捨てるしかないんだ、
こんな言語はもう滅ぼせ！

私には、建設的な提案なんか一つもない！
今はただ、スクラッチ＆スクラッチ、0から書き直すことだ！
835 名前：デフォルトの名無しさん [2007/04/04(水) 13:45:51 ]: MS儲おつかれさまです。
836 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 20:03:09 ]: MVMなんかいくら待ったって無駄だっ！
837 名前：デフォルトの名無しさん mailto:sage [2007/04/05(木) 01:17:46 ]: >>835
うん、MSは儲かるよ
838 名前：デフォルトの名無しさん mailto:sage [2007/04/05(木) 07:55:41 ]: 外山ゲイツ
839 名前：デフォルトの名無しさん mailto:sage [2007/04/12(木) 20:20:00 ]: JDK7 build11
download.java.net/jdk7/changes/jdk7-b11.html
download.java.net/jdk7/binaries/

何か地味なビルド。
OpenJDKでのビルド修正に関するFixばかり。
840 名前：デフォルトの名無しさん mailto:sage [2007/04/13(金) 15:01:43 ]: NIO2 の草案できたらしい。
d.hatena.ne.jp/kazama/20070413 より。
841 名前：デフォルトの名無しさん mailto:sage [2007/04/13(金) 21:03:32 ]: すげー
日本語版が用意されているという趣向が
ちょっと見てみようかという気になる
842 名前：デフォルトの名無しさん [2007/04/18(水) 12:27:47 ]: 進歩してるなｧ
journal.mycom.co.jp/articles/2007/04/11/openterracotta/index.html
843 名前：デフォルトの名無しさん mailto:sage [2007/04/18(水) 20:17:38 ]: JRE仮想化はBEAみたいなハードウェアよりなのが勝つんじゃないかな
844 名前：デフォルトの名無しさん mailto:sage [2007/04/18(水) 20:53:59 ]: ところでJavaでCPUのコア数って取得できましたっけ？
845 名前：デフォルトの名無しさん mailto:sage [2007/04/18(水) 21:06:02 ]: >>844
次世代関係ないな。初心者質問スレいけ。
846 名前：デフォルトの名無しさん mailto:sage [2007/04/19(木) 08:13:46 ]: 知らないなら知らないって言えばいいのにｗ
847 名前：デフォルトの名無しさん mailto:sage [2007/04/19(木) 21:58:33 ]: JOGLがSEに組み込まれることと、
Uniform Driver Interface対応がされれば
Javaクライアントの未来もあるんだが、
今だサーバ関係ばっかサポートしてるな。
848 名前：デフォルトの名無しさん mailto:sage [2007/04/19(木) 22:03:55 ]: JavaSE6でJOGLとの融合する予定だったけど不安定でとめたからな
今のバージョンでOpenGLレンダリングでGLJPanel使うとよくおちる
5.0はまともにレンダリングされなかったけどな
なんかリペイントマネージャがおかしかった模様

JOGL＋GLCanvas自体は安定してるのでゲームでは問題ないけど、
GLJPanelが動くようにならないと復権無理だな
あとは入力インターフェースとして2軸2ボタンでいいのでジョイパッドの正式サポートを
849 名前：デフォルトの名無しさん mailto:sage [2007/04/19(木) 23:13:54 ]: 「New」IO「2」か。。。どれだけ計画性のないネーミングだっつーの
850 名前：デフォルトの名無しさん mailto:sage [2007/04/19(木) 23:31:50 ]: >>849
NIO2は別名なんだろ？
統合か名前が変わるかするだろう
851 名前：デフォルトの名無しさん mailto:sage [2007/04/20(金) 10:36:48 ]: >>849
サントリー New Old
852 名前：デフォルトの名無しさん mailto:sage [2007/04/20(金) 12:39:51 ]: >>851
あれはわざとやったらしいよ
853 名前：デフォルトの名無しさん mailto:sage [2007/04/20(金) 23:37:33 ]: マトリックスの奴の名前だっけか
854 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 00:43:10 ]: >>853
仁王？
855 名前：デフォルトの名無しさん [2007/04/28(土) 06:15:28 ]: 言語レベルでの複素数型のサポートっていつやるの？
856 名前：デフォルトの名無しさん mailto:sage [2007/04/28(土) 09:15:37 ]: >>851
そうなのか。Sunってなんか変なところでマーケティングが変なこと言い出す気がする。

1.1→1.2→1.3→1.4→5.0→6.0
なバージョニングといい

J2SE→Java SE
といい。
857 名前：デフォルトの名無しさん mailto:sage [2007/04/28(土) 09:42:56 ]: いや、たんに世の中のバージョンとあわせただけだよ
sunの文化として0.1がメジャーバージョンアップなんだよ
でもマイナーバージョンアップにしか見えない

だから製品名と内部バージョンとをわけるという他の会社と同じものにあわせた
あと6.0はない、6だ
Java2登場前はただのJavaがあったし、SDKはJDKという名前でまたJDKに戻った

Java2という名前を入れるときに製品名としては2.0にすべきだったのさ

ただそれだけのこと
858 名前：デフォルトの名無しさん mailto:sage [2007/04/28(土) 11:14:04 ]: マーケティング周りで散々分かり辛かったから一般消費者向けに分かりやすい製品名にしただけ。
ブランド名はずっとJavaの4文字だし。

JDKに戻ったのもsun内部ではずっとJDKと呼ばれ続け、開発者側もJDKで十分慣れ親しんだため。

そして何より、今はゲイツの相手せずに済むから・・・

J/Directなんて禁句だぜ？

アゝ、なつかしの*7・・・
859 名前：デフォルトの名無しさん [2007/04/28(土) 16:05:42 ]: ♪ア・ソ～レ

ア・チョン！ア・チョン！

ア・チョン！チョン！チョン！バカ！
860 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 00:11:38 ]: XMLリテラルよりヒアドキュメントに対応して欲しいのは俺だけ？

String sql = <<END_OF_SQL
update USER_TBL
set name = ?,
age = ?
where id = ?
END_OF_SQL
861 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 00:14:26 ]: IDE使っていれば改行を気にすることないから俺は要らんな
862 名前：デフォルトの名無しさん [2007/04/29(日) 00:34:43 ]: 複素数なんていらないじゃん。
commonsにライブラリあるからそれで十分。
863 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 08:52:50 ]: >>860
ヒアドキュメントは確かに欲しい
あと、ヒアドキュメント中にJavaの式を埋め込むこともできたらいいな
864 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 09:17:28 ]: 言語でサポートされるなら複素数型は欲しいな・・
865 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 09:57:06 ]: そういえばCSV(TSV, etc.)を読み書きするためのライブラリが標準でないのが気になった
866 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 10:20:46 ]: TSVやCSVは環境依存しまくりだからな
ほとんどの場合Excel準拠でいいのだろうが
H2のライブラリを使うという手もある

だが、まずはファイルのコピー等を実装するのが先じゃね？
867 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 10:47:04 ]: 仕様通りのCSVって見た事ないんだが。
カンマで区切る以外はメチャクチャだろ。
868 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 11:05:13 ]: >>867 仕様ってrfc4180？
869 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 11:53:46 ]: >>868 4180って後付けだし他のシステムで吐き出したCSVを扱う
ときには全く意味ないよね。
870 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 12:37:17 ]: 後付の規格にあわせていたら過去のソフトとの互換性が取れんからな
どうせやるなら文字コードやどのソフトで出力したかなどメタ情報がほしいね

そのへんつっこんでいくとXMLになるから意味がないのだけれども
871 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 12:55:08 ]: 後付規格以外では、独自規格乱立してんだから互換性取るなんて無理。

RFC準拠の標準ライブラリとかならともかく、
自分とこの独自規格に合ったのが欲しいなら
自前の CSVライブラリ作った方が楽だし簡単。
872 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 13:07:50 ]: ttp://opencsv.sourceforge.net/
これ使ってる。別に困った事はない。というか、ＣＳＶ使うのは止めて欲しい。
問題が解決するわけじゃないが、タブ区切りの方が好み。
カンマより、タブの方が文章中で出てくる頻度が少ない。

というか、明確に項目を区切るための制御文字があってそれを入力できる方がいいなぁ
873 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 13:08:18 ]: ちょうどCSVってかテキストデータのライブラリ作ってる。
MIMEにあるかIANAに見に行って、RFCも日本語訳参考にしてるから
たぶん仕様的には正確だと思う。

RFC4180についてだけど、セル内改行を LF にすればExcel CSVに対応できる。
しかしAccess CSVは CRLF で、RFC4180と仕様が同じという困ったちゃん。
読み込みは柔軟に、書き出しは目的に合わせて厳密にという対応が必要だね。
874 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 13:28:53 ]: 後付けでもECMA-262とW3C DOMはうまい事まとめてるのにね。
相変わらずMSはオープン標準に従う気はないし。

テキストフォーマットの読み書きといえばODFなんかの文書フォーマット読み書きライブラリが標準拡張くらいであっても良いのにね。
やるとしたらテキストコンポーネントのプラグイン扱いかな。
変なところで妙に充実してるのがjavaのクラスライブラリなんだし。
875 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 13:29:04 ]: >>873
おれもそのAccessとの対応を対数ヶ月前やった
ダブルクォーテーションの中はあらゆる改行タイプをゆるせばいいだけだったっぽい
動きとしてはAccessのほうが納得しやすい
876 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 13:35:53 ]: >>874
javaってinterface作るのは好きだけど
SPIを作るのは嫌いって人が多すぎるんだよね。
MP3とかOGGとかSound APIにちょこっとしか準拠してないしｗ
877 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 13:54:41 ]: >>876
インターフェース作る＝自分でAPI定義
SPIの実装＝定義にあわせて作る

だからまったく別の話じゃね？
878 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 14:00:48 ]: このルールにあわせろっていうのは好きだが、
ルールに従うくらいなら俺仕様でって奴が多いってこと。
879 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 21:31:55 ]: >>878
うわ、激烈耳が痛てぇ。 orz
880 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 23:46:40 ]: >>878
それじゃMSがやってることと同じじゃんか。
881 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 00:08:54 ]: まぁ、大抵の奴はそう思うんじゃね？
882 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 00:36:26 ]: >>876
例えば標準のプラグインがヘボいので上書きしたい場合みたいに
他のプラグインと衝突する場合のガイドラインがなかったりするし。
いざ作ろうとすると、SPIまわりはドキュメントが不足してる。

他にも、Sun の標準プラグインに必要なインターフェイスだけしかないとか
java.net.URLStreamHandlerFactory はなんで SPIになってねーんだとか
SPI自体がテキトーに作られてる感が無きにしも非ず。
883 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 10:26:19 ]: C99では複素数もとっくにサポートされてるのにJavaはダメだね。
コンパイラに実装するのは難しくないだろ。
いろんなComplexクラスとか見ると、また車輪の最発明なのかと思って悲しくなる。
884 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 10:55:57 ]: ここは・・・

C99なんて仕様だけだろﾌﾟｷﾞｬｰm9

って言えばいいのか？

マジレスもしとくか、複素数を普通の演算子で扱いたいって事なんだろうけど
Javaの流れとしてはXMLリテラルの方が先じゃない？
俺としてはどっちも要らんが。
885 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 11:42:39 ]: >>883
確かに人それぞれの複素数クラスがあるよね。
886 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 12:50:02 ]: 複数のライブラリを横断的に使ってて、
複素数型がライブラリ毎に違うのが面倒くさいとか
そーゆーケースでもない限り標準APIに拘る必要も無いような。

複素数型入れても今更感が強いし、
下手すると独自規格乱立したCSVに後付標準規格(?)ができたのと同じで
それほど意味がないものになるような気もする。
887 名前：デフォルトの名無しさん [2007/04/30(月) 12:55:54 ]: >>884
gccのC99じゃだめなのか？
Javaも無料のコンパイラ使ってるくせに…
888 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 15:30:34 ]: そんなにCがいいならC使ってればいいんでは？
889 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 15:56:36 ]: >>883
Complexクラスが標準になればいいだけの話か。
890 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 16:45:23 ]: 複素数リテラルのまえに、BigIntegerリテラルだろ。
891 名前：デフォルトの名無しさん [2007/04/30(月) 17:05:27 ]: Wikipediaをwikiって略すな！
同時にWikipedia以外のWikiも盛り上げよう！
892 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 17:17:46 ]: >>891
携帯するものなんて電話以外にもいくらでもあるのに
携帯電話を携帯って略すのもやめよう
893 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 17:29:32 ]: >>890
リテラルは知らんけど、BigInteger BigDecimal の演算子オーバーロードは
dolphin で追加されそうな気配はある。>>132 のスライドに入ってるし。

もっとも、目玉は closure と erase erasure だろうけど。
closure というか、function type の実装には
java.lang.function パッケージに引数型+戻り値型を名前にした interface を使うみたいだけど
（ {int=>int} なら java.lang.function.II みたいな名前で int invoke(int) だけを持つ interface）
これ、実行時に生成するなら同じ仕組みで List<String> とかも生成するんじゃないかな。
と妄想中。VM（厳密には ClassLoader？）に手を入れる事になるけど。

で、そっちに時間取られると演算子オーバーロードとかは漏れる可能性もあるもしんない。
894 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 17:57:08 ]: >>891
seasarスレにカエレ(・∀・)

ま、どうせこのスレとあっちのスレ、中の人は同じだがな。
895 名前：デフォルトの名無しさん [2007/04/30(月) 18:23:11 ]: MVMは次に乗らないのか？
スレッドはネイティブ対応しないのか？
あーらんに負けるぞ。
896 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 18:28:56 ]: > スレッドはネイティブ対応しないのか？
？？？
897 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 19:25:00 ]: いまだにグリーンスレッドと勘違いしてるんだろう.
898 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 19:34:54 ]: 一瞬Rubyスレかと思ったわい。
899 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 19:46:22 ]: >>898
ﾉｼおれもれも。
ところでRuby処理系のネイティヴスレッド化って完了したの？

YARV Ruby でぐぐってみたけど、ささだ先生のところは0.4.1くらいで更新が
止まってるみたいで、最新の状況がよくわからん。

あ、スレちがいか。すまん。
900 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 20:17:55 ]: >>893
目玉はBigIntegerとBigDecimalだと思うよ
業務アプリだとこの辺頻繁に使うし
901 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 20:19:27 ]: >>899
そういうときはJRubyに関連付けするのだ
0.9.9がでたのでもうすぐ正式版が登場
つまりJavaVM上でRubyは動かすのが正解

VM起動時間なんてJavaSE6なら2回目以降は0.5秒だから問題ないし
902 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 20:46:47 ]: >>900
っても、closureの話は聞こえてくるけどBigDecimalの話はあんまし聞こえてこないんだよね。
903 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 20:53:57 ]: >>902
仕事に絡まないプログラムならそうかもしれんが
仕事では使わないという場面はほとんどないからなぁ。
そして仕事で組んでる場合、次の技術というのに目が行く人は少ない。
目をつけていても発言する場が日本語でできないのなら誰もしないだろうさ。
904 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 21:24:54 ]: >>903
いや、Sunがどーゆー実装にするとか、JCPでどーゆー提案が出たとか
そーゆー話が聞こえてこないって事なんだけど。
905 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 21:37:14 ]: JCPとかリードスペックとか現時的に業務に絡んでないやつらが多すぎなんじゃ？
906 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 21:42:30 ]: >そして仕事で組んでる場合、次の技術というのに目が行く人は少ない。
>目をつけていても発言する場が日本語でできないのなら誰もしないだろうさ。
技術者として終わってるな
907 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 21:51:54 ]: >>906
じゃぁ始まってるアンタが変えてよ
908 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 21:56:07 ]: >>905
愚痴たれるんならマ板に行ってやれ。
909 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 22:04:35 ]: >>906
たとえ真実でも、言ってはいけない事ってのがあってだな……
910 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 22:28:02 ]: >>906-909

PGが絶対口にしてはいけない一言
pc11.2ch.net/test/read.cgi/tech/1176001986/l50
911 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 01:55:23 ]: >>889
ライブラリにクラスを追加するとか、演算子オーバーロードが出来るようにするとか
よりも、プリミティブな複素数型を言語に追加してくれってこと。

複素数は機種依存するもんじゃないし、
たとえばFFTや平面座標上の点の計算に活躍する。
912 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 02:00:43 ]: 小数点演算すらソフトウェア実装なのに面倒なことさせるな。
913 名前：デフォルトの名無しさん [2007/05/01(火) 07:17:37 ]: > 現時的に業務に絡んでないやつらが多すぎなんじゃ？

現実的に国内で業務システムに絡んでる奴は
頭弱すぎて割り込めないだけ。
914 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 07:49:23 ]: >>911
> たとえばFFTや平面座標上の点の計算に活躍する。
の用途のために、何故
> プリミティブな複素数型を言語に追加してくれってこと。
が必要なのかわからん。クラスじゃ何でダメなんだ？

あと「プリミティブな」ってVM変更（バイトコードインストラクションを拡張）しろって話？
たぶん、そんな要求してもマトモに相手にされないと思うけど。
915 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 08:19:29 ]: この人は、単に複素数リテラルと演算子のオーバロードが欲しいだけだと思う。
言葉が不自由なので、自分の要求を正しく伝えられないのでは？
916 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 08:35:19 ]: >VM変更（バイトコードインストラクションを拡張）しろって話？

言語仕様の追加みたいだけど、どこからVM仕様追加の話になるんだ？
C99のようにゴニョゴニョっとまねして、チャチャッ実装しちゃってくれってことじゃないのか。
まあ、あれば便利だし、有難く使わせてもらうけど。
917 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 08:42:26 ]: 自分で実装してJCPに提案しろｗ
918 名前：デフォルトの名無しさん [2007/05/01(火) 08:54:09 ]: 演算子をオーバーロードして、BigDecimalの割り算はどうやって丸め指定を表現するんだろ
919 名前：デフォルトの名無しさん [2007/05/01(火) 08:56:26 ]: Javaの複素数演算用クラスって、どっかになかったか？
いちいち、引数をとらないといけないし、Fortranなどマシン語レベルの
ライブラリ充実している言語と比べると、スピードが出ないだろうけど、
だからといって、VM仕様から変更は影響が大きすぎるだろ。
920 名前：デフォルトの名無しさん [2007/05/01(火) 09:06:24 ]: >VM仕様から変更

だからどうしてVM仕様変更の話になるんだと小一時間（ｒｙ
921 名前：デフォルトの名無しさん [2007/05/01(火) 09:14:02 ]: >>920
java.sun.com/docs/books/jvms/second_edition/html/Concepts.doc.html#19511
922 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 09:36:30 ]: >>912
strictfpで宣言しない限り結局はFPUに計算させてない？
923 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 10:37:21 ]: >>916

>>911 の
> ライブラリにクラスを追加するとか、演算子オーバーロードが出来るようにするとか
> よりも、プリミティブな複素数型を言語に追加してくれってこと。
から。

クラスもダメで、演算子オーバーロードもダメで（たぶんリテラルもダメ）、
プリミティブな型を追加と言われたらバイトコード拡張なのか？ってのは至極当然。
924 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 11:13:54 ]: 意味なしリクエストは却下
925 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 04:33:33 ]: >>916
>>921
>>923
それがどうやって実装されるかということを君達がアレコレ妄想する必要はない。
それがあればどう世界が変わるかだけを考えろ！
926 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 07:43:02 ]: まったく変わらない。
以上
927 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 08:46:01 ]: >>915
複素数リテラルって何？
3.1i
1 + 2i
"3 + 4i"
とかのことか

それと演算子オーバーロードは、
Complex,Matrixクラスの話題とよくセットで出てくるが、
その程度で演算子オーバーロードを実装するのはコストが
高いなどの論点とは今回は関係ないようだ。

おまえは思い込みが激しいようだな。
928 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 08:57:25 ]: 言語不明瞭意図不明。
929 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 09:03:14 ]: >>927
>>928
おまえ誰だよ。早く消えちまいな。
930 名前：デフォルトの名無しさん [2007/05/02(水) 09:35:38 ]: 野次と荒らしは2chの花
931 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 11:39:25 ]: >>930
ｦﾀとDQNが抜けてるぞ
932 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 06:00:15 ]: >>925
どう実装されるかはしらんが、プリミティブ型を追加するという時点でVMに手をいれないといけないのは決定だろ。
933 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 09:20:31 ]: C99だと
struct complex {double real, imag;}
struct complex {double z[2];}
とかで実装されてるんじゃないか。
だからコンパイラの拡張のみでマシーン（VM)の方に手を入れることはない。
というか、一般人が実装のことを考える事自体が意味ないじゃん。
934 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 09:32:36 ]: 配列で大量に計算する用途だとクラスよりC#の値型のようなものがあるとベターだな。
935 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 09:58:40 ]: >>933
えーと。
結局、プリミティブな複素数型は特に必要がなくてクラスでやってもOKって話かな？

本当に複素数型欲しいなら
現時点でGPLで配布されてる javac に複素数型導入して公開したり、
そのパッチを ksl に投稿してみるとか、
BugDatabaseに行って、RFE出すとか既存のRFEに投票するとか、
その bugID 晒して、皆に投票呼びかけたりとか、
もちっと前向きな行動した方が良いと思うよ。

ここで複素数追加みたいなネタ振られたって、
皆でどーゆー実装するのか妄想して遊ぶぐらいしかできないでしょ。
936 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 10:09:09 ]: 座標上の点の計算には便利そうだ。特に回転とか。
複素数クラスがあってもnewしまくるから遠慮してたけど、
言語に追加されるなら便利そうだけどな。

今のトレンドは言語に複素数を追加することなんじゃないか。
C,D,Pythonは既に言語レベルでサポートしてるし。
937 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 10:25:59 ]: トレンドってほど支持する流れも否定する流れも大きくないと思うが……
938 名前：デフォルトの名無しさん [2007/05/03(木) 10:37:45 ]: >>933
頭悪そう
C99を使ってろ
939 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 10:53:07 ]: >>936
ちなみに、何を作りたくて複素数型が必要なんだ？
940 名前：デフォルトの名無しさん [2007/05/03(木) 10:57:23 ]: >>934
C#の値型は、クラスと比べてどんなメリットがあるの？
コンパイル時に最適化されて
ランタイム負荷が小さいとか？
941 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 12:34:41 ]: >>940
クラスのオブジェクトに比べ生成と削除のコストが低い。
値型は参照を介せずにスタックに直接値が格納されたり、
配列やクラスのメンバーとして直接その領域に値が格納されるので
ボクシングが発生しない限りGCの必要な実体が作られることがない。
このためプリミティブ型に近いパフォーマンスを発揮する。
942 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 12:45:20 ]: >>939
必要ないんでしょ。

ってか、実際に複素数型が必要な分野のプログラム組んでる人間が
「演算子オーバーロードよりもプリミティブな複素数型」なんて言うとは考えられないし。
943 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 14:50:30 ]: >>941
値型ってのが広い範囲を表すからいいたいことがあいまいだぞ
944 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 15:00:41 ]: 下手に構造体チックなものが登場されてもBeanの文化が壊れるから
ByteBufferで我慢が出来ないなら諦めてくれって方針で十分。
945 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 19:32:28 ]: >>933
だから、それはプリミティブ型じゃないだろ。
946 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 20:49:44 ]: Ｃ＃の値型みたいなのがほすぃ
って言いたかっただけなんじゃないか、と。
947 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 21:32:14 ]: >>946
Java に C# の値型みたいなの導入すると
コンパイラ弄るだけじゃすまなくて、それこそ VMの変更が必要なりそうだし。
メソッドの戻り値で値型を使う場合とか。

それに、C# は最初から値型があったから良いけど、
Java の場合は generics 導入しちゃった後だからねぇ。
今から C# の値型みたいなものを追加したとしても
現時点でのプリミティブ型みたいに generics で使えなさそうだし。
948 名前：デフォルトの名無しさん [2007/05/03(木) 21:52:46 ]: Javaも遅かれ早かれVMの拡張は必要になると思うのだがいつごろ来ると思う？
949 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 22:05:05 ]: >>948
おいおい……
バイトコードインストラクションの話ならJSR-292のinvokedynamic追加の検討中。
後は>>893がfunction type関連でVM拡張とか言ってる。
950 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 22:13:31 ]: >>949
さんくす。複素数の議論でVM拡張は避けるべき的な話が出てたので確認してみた。
別にVM拡張前提で話をしてもかまわないわけだよね。
951 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 22:21:32 ]: >>950
ここは「次世代Javaの動向」をヲチるスレだから、
新機能追加の要望とか、単なる妄想オナニーなら他所でやってくれ。
952 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 22:24:40 ]: だれもVM拡張は避けろといってなくて、プリミティブ型を追加するならVM変更という話と、そんな無意味な要求は却下されるよという話が同時進行してただけかと。
953 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 22:28:41 ]: >>951
ヲチするだけとはどこにも書いてないわけで。
しかも、最初から要望とか妄想オナニーばかりのスレで、950も過ぎてから言ったところで説得力ない。
954 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 22:32:05 ]: >>953
今回ので言えば、既に >>935 で他所行けって出てるし。
他の話題でも他所行けってのは散々出てるし。
955 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 22:38:34 ]: つまり、スレの流れについていけなくてわめいてるってわけか。
956 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 22:41:32 ]: >>953
便所に落書きしても要望だとは思われないよな。普通は。
957 名前：デフォルトの名無しさん mailto:sage [2007/05/04(金) 01:17:58 ]: 複素数を扱うライブラリがあれば便利だと思うが
言語仕様に含めるのはやり過ぎです。

ところで値型って、VBのByValを指しているの？
958 名前：デフォルトの名無しさん mailto:sage [2007/05/04(金) 01:45:44 ]: >>957
ここは予想や感想を述べる場所じゃないとのことなので、
そういう動向は今のところ無いということでおしまいらしい。

値型はVB.NET以降では、ユーザー定義型（Structure）、Enum、クラスを除くVBの基本データ型をさす。
VBのデータ型と.NET(CLR)のプリミティブ型は若干違うから注意。
ここではユーザー定義型（Structure）の意味で使ってる。
.NET(CLR)ではValueType C#ではstruct。
Javaだと参照型以外の型＝プリミティブ型＝値型という理解でいいのかな？（自信は無いが）

あとは質問か雑談スレへとかいわれそうだ。
959 名前：デフォルトの名無しさん mailto:sage [2007/05/04(金) 03:50:43 ]: >>956
「普通は。」ってなんだよ 9m(^x^
960 名前：デフォルトの名無しさん mailto:sage [2007/05/04(金) 09:51:42 ]: C#：全部ヒープに置いたら遅いだろ！struct導入する！
Java：エスケープ分析で自動的にスタックに置くｳﾏｰ
961 名前：デフォルトの名無しさん mailto:sage [2007/05/04(金) 12:14:58 ]: どうもsturct(値型）の話になってるようだけど、なんなら
typedef double complex[2];
でいいじゃん。どう実装されるかなんかはベンダ任せなんだけどね。
962 名前：デフォルトの名無しさん mailto:sage [2007/05/04(金) 19:07:54 ]: ベンダ任せなわけがない
963 名前：デフォルトの名無しさん [2007/05/04(金) 20:59:25 ]: Hさん、居るよね。
964 名前：デフォルトの名無しさん mailto:sage [2007/05/05(土) 21:03:27 ]: MさんとKさんもいるよね。

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef