- 1 名前：デフォルトの名無しさん [2008/01/03(木) 12:29:37 ]
- 前スレ
[Java SE 7] 次世代Javaの動向 5 [dolphin]
pc11.2ch.net/test/read.cgi/tech/1178925915
[mustang/Java SE 6] 次世代Javaの動向 4 [dolphin]
pc11.2ch.net/test/read.cgi/tech/1163986696/
[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/
- 204 名前：デフォルトの名無しさん mailto:sage [2008/02/24(日) 17:07:46 ]
- >>201
バイナリ互換性じゃなくてソース互換性？
「下手すると」って書いてるけど、どの案でどういう問題が？
- 205 名前：デフォルトの名無しさん mailto:sage [2008/02/24(日) 18:03:08 ]
- >>204
あるクラスにプロパティ hoge と、フィールド hoge があった時に、
識別子 hoge で、フィールドとプロパティどっちアクセスすんの？って話。
プロパティ hoge の宣言と、フィールド hoge の宣言を排他にすりゃ問題ないけど
beans のプロパティ hoge と、フィールド hoge は共存できてたわけで、
安易に排他にするとソース互換性を破壊する。
アクセスレベルのルールをちゃんと考えれば互換性たもてるかもしれんが、
失敗すればフィールドアクセスのつもりがプロパティアクセスになったりしてソース互換性破壊する。
頑張ってアクセス時のルールで互換性維持したとしても
プロパティ hoge を継承クラスのフィールド hoge で隠蔽できるようになったりする。
- 206 名前：デフォルトの名無しさん mailto:sage [2008/02/24(日) 18:26:02 ]
- 排他にすりゃいいし、フィールドで隠蔽できないようにすりゃいい。
というか、draft3はそういう案じゃなかったか？
で、それが「安易に排他にする」ことだとして、そこで発生する問題は何？
- 207 名前：デフォルトの名無しさん mailto:sage [2008/02/24(日) 18:30:18 ]
- >>206
標準APIでプロパティ使うと、継承クラスで同名フィールドが宣言できなくなる。
beans のプロパティと同名のフィールドを宣言してるソースは大量にあるわけで。
っつーか、draft3 ってどれの事いってるん？
- 208 名前：デフォルトの名無しさん mailto:sage [2008/02/24(日) 19:00:33 ]
- これね。
docs.google.com/View?docid=dfhbvdfw_1f7mzf2
>標準APIでプロパティ使うと、継承クラスで同名フィールドが宣言できなくなる。
そこであらかじめ定義されたプロパティと同名のフィールドをサブクラスで
定義しなきゃならないケースというのが想像できないんだけど？
もしそれが問題になるんなら、親クラスで定義されるのがプロパティじゃなくて
フィールドでも一緒じゃね？
>beans のプロパティと同名のフィールドを宣言してるソースは大量にあるわけで。
beansと関係ないからこそソース互換性を保てるわけなんだが。
- 209 名前：デフォルトの名無しさん mailto:sage [2008/02/24(日) 19:48:02 ]
- >>208
自前のクラスで、標準APIのクラス Hoge を継承する SubHoge に、
フィールド hoge が宣言されてるとする。
これは既存のソースでプロパティ導入前にはなんの問題もないけど、
プロパティが導入されて、標準APIのクラス Hoge にプロパティ hoge が後付で導入され、
おまけにプロパティとフィールドが排他だとなると、ソース互換性が破壊されるわけ。
フィールドは隠蔽されるだけだし、最初から存在するルールだからソース互換性は破壊されない。
- 210 名前：デフォルトの名無しさん mailto:sage [2008/02/24(日) 19:59:01 ]
- 標準API ：
class Hoge{ abstract Hoge getHoge(); }
ユーザ側：
class SubHoge extends Hoge{
Hoge hoge;
Hoge getHoge(){ return hoge; }
}
で上手くいってたのに、
プロパティ導入して、標準APIが
class Hoge {
abstract Hoge getHoge();
abstract property Hoge hoge;
}
とかに変わると、SubHoge はコンパイル通らなくなるわな。
- 211 名前：デフォルトの名無しさん mailto:sage [2008/02/24(日) 20:04:42 ]
- 後付けでプロパティ追加なんてしなきゃいいじゃん。
これができないとどういう場合に困るの？
- 212 名前：デフォルトの名無しさん mailto:sage [2008/02/24(日) 20:12:09 ]
- >>208
あと、beansとの互換性を維持する場合の問題は別にあって、
同名のプロパティが言語仕様上は共存できるとかね。
例えば
interface Hoge {
boolean isHoge(); void setHoge(boolean b);
Hoge getHoge(); void setHoge(Hoge hoge);
}
は、言語仕様上は問題ない。
だけどプロパティとしては同名プロパティが複数あるので曖昧になる。
beans仕様は厳密じゃないから、どっちを優先的にプロパティにするかとか、
実は同名プロパティを複数持ったbeansは不正なのか、みたいな事を記述してない。
java.beans.Introspector が決める事になってるみたいだけど、
これもブラックボックスで振る舞いは文書化されてない。
で、beansと互換性のあるプロパティを言語仕様に導入しようとしたとき
Hoge hoge;
System.out.println(hoge.hoge);
とかなったとき、getHoge() を呼ぶべきか isHoge() を呼ぶべきか？
はたまた同名プロパティは宣言できないようにすべきか？ みたいな問題が出てくる。
まぁ、こーゆーのが現実に問題になるケースは少ないと思うけど
言語仕様上はきっちり決めとかないといけないから。
- 213 名前：デフォルトの名無しさん mailto:sage [2008/02/24(日) 20:33:45 ]
- みんなきちんとIntrospectorを使っているんならまだましだけど、
勝手にやっちゃってるフレームワークが氾濫しているのも問題だよな。
- 214 名前：デフォルトの名無しさん mailto:sage [2008/02/24(日) 20:41:35 ]
- 今時プロパティのない言語は時代遅れ。
- 215 名前：デフォルトの名無しさん mailto:sage [2008/02/24(日) 20:44:49 ]
- get/setをエディタが補う時代にプロパティとかいらんだろ
でもプロパティってバインド機能があるんだっけか
- 216 名前：デフォルトの名無しさん mailto:sage [2008/02/24(日) 20:48:48 ]
- 追加はしてくれるけど、消したり隠したりしてくれないんだよな。
- 217 名前：デフォルトの名無しさん mailto:sage [2008/02/24(日) 21:27:05 ]
- 正直クロージャすらない言語は時代遅れ
- 218 名前：デフォルトの名無しさん mailto:sage [2008/02/24(日) 22:29:55 ]
- func.invoke(20)をfunc(20)にするのだけど、確かに見た目と意味が一致していい気がするけど、
int y=new {int a=>a+1}.invoke(20); は分かるが、
int y=new {int a=>a+1}(20); これはどうかと思わないか？
プロパティとかクロージャも含めて、言語仕様にリテラルを入れるのは
直接的には省略した記法でしかない。
やっぱり、それを新規に導入するだけのメリットがあるかどうかだろ。
ジェネリクス同様、所詮はCのマクロの置き換えと同じだしｗ
- 219 名前：デフォルトの名無しさん mailto:sage [2008/02/24(日) 22:34:53 ]
- そんな使い方しないってw
あほかよ
- 220 名前：デフォルトの名無しさん mailto:sage [2008/02/24(日) 22:44:47 ]
- int x = (Integer)new Function("text/javascript", "1+1").invole();
やっぱりこれで良いんですけど。
- 221 名前：デフォルトの名無しさん [2008/02/24(日) 22:45:52 ]
- タプルと演算子オーバーロードは、確か、絶対にサポートしないってどこか書いてあった（英語）。
bigdecimalのオペレータ[+,*とか]・オーバーロード・サポートもあんまり期待できない。
byte b; Float o;
{b, o}=init(something);
クラスを定義するほどでもなく、ちょっと利用のつもりでこんな感じだろうけど、
Object[] init(something){return new Object[]{new Byte(2), new Float(2.1)};}
この長い書き方で実質的に展開されるんだろうし、別にリテラルとしてサポートするメリットな意味ない。
クロージャ（GUIイベントを主とした）と違って、あんまり必要としてる人はいないみたい。
配列じゃなくてクラスを返し他方が、他の人が読んでも分かるみたいで、private
で使うんじゃないか？オレなら、publicやprotectedのメソッドでは、こういうAPIがあると作った人を疑っちゃうけどね。
- 222 名前：デフォルトの名無しさん mailto:sage [2008/02/24(日) 22:49:53 ]
- 演算子オーバーロードのサポートも時間の問題と思われ
- 223 名前：デフォルトの名無しさん [2008/02/24(日) 22:53:26 ]
- それと、クラスをメモリ上に一旦読み込んでしまえば、
匿名クラスとかクロージャとかで関数一つでもクラスをいちいち生成される
とか気にしても、性能に全く関係ないよ。
.classでもメモリ上ではCのように速さとか性能はほぼネイティブと同じになるし、
せいぜいメソッドで動的呼び出しか、静的呼び出しかの違いぐらいじゃないか？
それに、C、jvmくらべるより、それよりもIO待ちのほうがはるかに遅くなるｗ
クラスファイルが多くなるだろうけど、jarで固めるだけだし。
javaとかjvmとかは、C++C＃Rubyみたいにプログラマーよりじゃなくて
実はハードよりの言語（と仕様）だったりする。
確かゴスリン(BGGA)もやる気みたいだったし、あとはjdk1.7に間に合うかどうかだろう。
クロージャは1.7の目玉だしな。
- 224 名前：デフォルトの名無しさん mailto:sage [2008/02/24(日) 22:56:34 ]
- >>220
それ、何をしたいのかやりたいことは分かるが、そもそもJavaと関係ないだろｗ
- 225 名前：デフォルトの名無しさん mailto:sage [2008/02/24(日) 23:06:29 ]
- >>217
匿名クラスがjavaのクロージャなんだけど、
そのクロージャってなんだよｗ
- 226 名前：デフォルトの名無しさん mailto:sage [2008/02/24(日) 23:09:26 ]
- java.util.concurrent
GUI使わない案件なら、やっぱりJavaはこれでしょ。
クロージャのほうが先に導入されてるとそれなりに面白かったけど。
- 227 名前：デフォルトの名無しさん mailto:sage [2008/02/24(日) 23:14:33 ]
- >>225
匿名クラスがクロージャそのものなのはC#なんでは？
- 228 名前：デフォルトの名無しさん [2008/02/24(日) 23:15:46 ]
- >>220
それだけダラダラとタイプ量があるなら匿名クラスと同じ。
ていうか、匿名クラスならまだjavaだけど、それjsだろ。
いつも書いてて絶対に必要になるし、ダラダラ書くの面倒じゃん？ってのが始まりだろう。
- 229 名前：デフォルトの名無しさん mailto:sage [2008/02/24(日) 23:17:51 ]
- >>218
俺には「C言語はアセンブリのマクロにすぎないから不要」ってぐらい暴論に聞こえるんだが。
クロージャにしたって、一塊の処理の手続きを「ひとつのオブジェクトでもある」のと「データとは異なるものとしてコンパイラに特別扱いしてもらう」のうち後者以外はすべて異端って扱いはどうなのよ。
- 230 名前：デフォルトの名無しさん mailto:sage [2008/02/24(日) 23:24:33 ]
- >>227
C#のクロージャの話をしたいのか。
- 231 名前：デフォルトの名無しさん mailto:sage [2008/02/24(日) 23:26:33 ]
- >>229
なかなかの暴論だなｗ
オレには「アセンブリは、所詮はCのベンダー実装に過ぎない」って思ってたけどｗ
- 232 名前：デフォルトの名無しさん mailto:sage [2008/02/24(日) 23:27:24 ]
- withLock(lock, {=>
System.out.println("hello");
});
withLock(lock) {
System.out.println("hello");
}
あたりは本当にいろいろと可能性が広がりそうで楽しみ。
Collectionも引数にクロージャ渡すものがかなり拡張されるだろうね。
- 233 名前：デフォルトの名無しさん mailto:sage [2008/02/24(日) 23:28:04 ]
- >>230
C#スレでやれよ。
- 234 名前：デフォルトの名無しさん [2008/02/24(日) 23:30:08 ]
- >>229
何を実現したいのかと、それをどうやるのかの実装とは、別にして考えてみたらどうだ？
それなら全て異端ってことじゃなく、両立可能だろうな。
- 235 名前：デフォルトの名無しさん mailto:sage [2008/02/24(日) 23:38:09 ]
- >>232
Collectionには手を出さないんじゃないか？
ジネリクスと混じってしまってパッと見なんだか分からなくなる。
ジネリクスは目が慣れるまで少し時間がかかったしｗ
コンカレント辺りのブロッキングキュー・クラスとかでやるならまだしも。
- 236 名前：デフォルトの名無しさん mailto:sage [2008/02/24(日) 23:40:35 ]
- 俺はGenericsは単純すぎて拍子抜けした。
C++使いからみれば単純この上ない。
- 237 名前：デフォルトの名無しさん mailto:sage [2008/02/24(日) 23:54:25 ]
- C++が意味不明なんだよ。
それもジェネリクスじゃなくて、C++はテンプレートだろ。
C++のやりたいことは雛形プログラム手法で、Java総称型なんだけど、その様子だと分かってないな。
- 238 名前：デフォルトの名無しさん mailto:sage [2008/02/24(日) 23:59:23 ]
- >>220
それ、クロージャじゃなくてevalじゃん。
- 239 名前：デフォルトの名無しさん mailto:sage [2008/02/25(月) 00:02:44 ]
- ちなみにおまいらクロージャ候補はどの候補がいいと思うよ？
- 240 名前：デフォルトの名無しさん mailto:sage [2008/02/25(月) 00:10:35 ]
- >>238
クロージャーであることが目的になっちゃってるの？
- 241 名前：デフォルトの名無しさん mailto:sage [2008/02/25(月) 00:13:49 ]
- >>240
evalだと静的に色々解析できないじゃん
- 242 名前：デフォルトの名無しさん mailto:sage [2008/02/25(月) 00:20:02 ]
- 内部イテレータが欲しい俺は少数派か？
- 243 名前：デフォルトの名無しさん mailto:sage [2008/02/25(月) 00:23:33 ]
- ↑具体的にどういうコードになるの？
- 244 名前：デフォルトの名無しさん mailto:sage [2008/02/25(月) 00:24:35 ]
- >>240
少なくともevalを多用するのは嫌い。
evalは(たとえ動的言語であっても)最後の武器だと思ってる。
- 245 名前：デフォルトの名無しさん mailto:sage [2008/02/25(月) 00:25:11 ]
- 2ch は保守派 (というか優位に立ちたい人) しかいないからわざわざ披露しない方が良いよ。
- 246 名前：デフォルトの名無しさん mailto:sage [2008/02/25(月) 00:30:15 ]
- html出身の人にはクロージャの意味は分からんのです。
- 247 名前：デフォルトの名無しさん mailto:sage [2008/02/25(月) 00:39:00 ]
- >>237
C++の方が機能が多いってだけだろ。
C++だってgenericだぜ。
- 248 名前：デフォルトの名無しさん mailto:sage [2008/02/25(月) 00:39:47 ]
- >>245
馬鹿は頭固いから何言ってもダメだしな。
なぜこんなスレに来ているのかわからんが。
- 249 名前：デフォルトの名無しさん mailto:sage [2008/02/25(月) 01:02:42 ]
- JavaのGenericsを批判している人も批判していない人も、型引数への制約やワイルドカード型引数といった
JavaのGenericsの機能を本当に使いこなせている？
Google作成のGuiceあたりはGenericsを多用しているので、勉強になる。
これらのソースをすらすら理解でき改造できるようになってから、批判しよう。
- 250 名前：デフォルトの名無しさん mailto:sage [2008/02/25(月) 01:08:50 ]
- あの程度理解できない人間はこのスレに来るべきじゃないよ
- 251 名前：デフォルトの名無しさん mailto:sage [2008/02/25(月) 01:21:01 ]
- clone() じゃねーけど、減らす仕様もロードマップに示して欲しいなー。
@Deprecated じゃないけど 「旧仕様互換ソースはコンパイルできるが新仕様準拠ソースは
コンパイルエラー/ただしランタイムは解決可能」 みたいなアノテーションでも作って。
- 252 名前：デフォルトの名無しさん mailto:sage [2008/02/25(月) 01:37:26 ]
- それはコンパイルオプションで解決すりゃいいことでは
- 253 名前：デフォルトの名無しさん mailto:sage [2008/02/25(月) 04:54:50 ]
- 使う方のソースはそれで良いけど宣言する方のソースはアノテーション必要でしょ。
- 254 名前：デフォルトの名無しさん mailto:sage [2008/02/25(月) 05:55:52 ]
- やっぱりC＋＋出身者は、個人的な問題を指摘する事が多いね。
- 255 名前：デフォルトの名無しさん mailto:sage [2008/02/25(月) 09:14:43 ]
- cloneって何か変わるの？？
- 256 名前：デフォルトの名無しさん mailto:sage [2008/02/25(月) 14:10:28 ]
- >>245
だれだおまえ？
- 257 名前：デフォルトの名無しさん mailto:sage [2008/02/25(月) 21:27:34 ]
- 私の名はクリストファー・エリクソン。
- 258 名前：デフォルトの名無しさん mailto:sage [2008/02/25(月) 21:28:14 ]
- よう！くりちゃん！！久しぶり！！
- 259 名前：デフォルトの名無しさん mailto:sage [2008/02/25(月) 22:15:22 ]
- >>250
ずいぶんと自信過剰ですな。
ところでJVMの実装とかあなたはできるんですか？
- 260 名前：デフォルトの名無しさん mailto:sage [2008/02/25(月) 23:09:49 ]
- >>222
おまえはだれだ？
- 261 名前：デフォルトの名無しさん mailto:sage [2008/02/26(火) 00:19:24 ]
- ボクハ、オンガクカ、デンタクカタテニ
- 262 名前：デフォルトの名無しさん mailto:sage [2008/02/26(火) 00:28:42 ]
- もうjava2Kでいいじゃん
- 263 名前：デフォルトの名無しさん mailto:sage [2008/02/26(火) 00:46:08 ]
- >>259
GenericsとJVM実装って全然別やん…
- 264 名前：デフォルトの名無しさん mailto:sage [2008/02/26(火) 00:55:26 ]
- なんか、味噌でも糞でもとにかく延々と追加して行かなければいけないような雰囲気だねー。
マッチポンプで仕事作ってるようも見える。
- 265 名前：デフォルトの名無しさん mailto:sage [2008/02/26(火) 02:46:25 ]
- C＃がね。
- 266 名前：デフォルトの名無しさん mailto:sage [2008/02/26(火) 02:51:58 ]
- clone()ってなくなるの？
- 267 名前：デフォルトの名無しさん mailto:sage [2008/02/26(火) 07:47:39 ]
- 珍妙なもんを削る方向にも進めということでしょ。
- 268 名前：デフォルトの名無しさん mailto:sage [2008/02/26(火) 09:27:53 ]
- チンチンを削ちゃうの？
- 269 名前：デフォルトの名無しさん mailto:sage [2008/02/26(火) 09:27:55 ]
- >>266
今更削除できないと思うが。
- 270 名前：デフォルトの名無しさん mailto:sage [2008/02/26(火) 09:47:04 ]
- clone削除されたら困るんだが
- 271 名前：デフォルトの名無しさん mailto:sage [2008/02/26(火) 10:05:15 ]
- されないw
- 272 名前：デフォルトの名無しさん mailto:sage [2008/02/26(火) 11:57:23 ]
- やっぱり小さいチンチンは削除です
- 273 名前：デフォルトの名無しさん mailto:sage [2008/02/26(火) 14:30:54 ]
- >>245
全く何を言いたいのか意味不明なんだが、もっと分かりやすく書き直してくれないか？
- 274 名前：デフォルトの名無しさん mailto:sage [2008/02/26(火) 20:17:29 ]
- >>268
尖らすの？
- 275 名前：デフォルトの名無しさん mailto:sage [2008/02/26(火) 23:06:10 ]
- ちぎり取るんだろ
- 276 名前：デフォルトの名無しさん mailto:sage [2008/02/27(水) 00:32:49 ]
- 結局プロパティってなくなったの？
boundのダウンキャスト地獄な仕様みた瞬間うんざりしたからいらんけど。
- 277 名前：デフォルトの名無しさん mailto:sage [2008/02/27(水) 00:44:36 ]
- getter/setterでいいよな別に。
アクセッサの表記にget/setがなくなる程度のメリットしかない気がする。
- 278 名前：デフォルトの名無しさん mailto:sage [2008/02/27(水) 00:53:16 ]
- ワンモアセッ！
- 279 名前：デフォルトの名無しさん mailto:sage [2008/02/27(水) 01:34:49 ]
- >>277
例えばどうやるの？
- 280 名前：デフォルトの名無しさん mailto:sage [2008/02/27(水) 01:40:24 ]
- Property Spec (draft 3)の次ってあるの？
ぐぐってもv4とかなさげなんだけど
- 281 名前：デフォルトの名無しさん mailto:sage [2008/02/27(水) 01:50:35 ]
- Seasarのpublicフィールドみたいなことを
勝手にやられるより、あったほうが良いんじゃないか？
- 282 名前：デフォルトの名無しさん mailto:sage [2008/02/27(水) 01:58:51 ]
- どうなんの?
何かアノテーションとコンパイラのサポートで十分な気がするけどこれも言語仕様変える気?
- 283 名前：デフォルトの名無しさん mailto:sage [2008/02/27(水) 03:34:44 ]
- プロパティなんてメソッド経由のアクセスで十分だろ。なに必死になってんのｗ
- 284 名前：デフォルトの名無しさん [2008/02/27(水) 04:06:28 ]
- clone()がどうとうかこうとかも、意味不明なことをいう変質者が多いな。
- 285 名前：デフォルトの名無しさん mailto:sage [2008/02/27(水) 05:19:15 ]
- ああ。なんだか何いってんのかわかんない奴が最近多いよ。
やっぱ春だな
- 286 名前：デフォルトの名無しさん mailto:sage [2008/02/27(水) 10:43:09 ]
- プロパティはもう入らないんじゃないかな。
クロージャは入るだろうけど。
>>232のような制御構造に近い記述のメリットが大きいから。
並列とか制御に関するクラスの記述に便利だしね。
- 287 名前：デフォルトの名無しさん mailto:sage [2008/02/27(水) 10:46:12 ]
- やっぱ、break, returnだろ。
てか、偶然に速レスになってるし。
- 288 名前：デフォルトの名無しさん mailto:sage [2008/02/27(水) 14:56:53 ]
- プロパティとかクロージャとかどうでもいいから
XMLリテラルとソースファイルのエンコード指定と
RAW文字列？みたいな今不便なところを改善する機能をはやく取り入れてほしい
- 289 名前：デフォルトの名無しさん [2008/02/27(水) 16:20:49 ]
- XMLリテラルはXjが最有力と言われた時期もあったけど、
もう入らないと思う。最近続報が全くないので。当時の賛否を考えると、
here documentであることよりもXMLであることがネックになってると思われ
- 290 名前：デフォルトの名無しさん mailto:sage [2008/02/27(水) 16:54:45 ]
- ヒアドキュメントより文字列リテラルに変数変数埋め込めるようにして欲しい。
+結合だと冗長になる。
- 291 名前：デフォルトの名無しさん mailto:sage [2008/02/27(水) 21:17:53 ]
- そういう機能作ると半分の人間が動的に作成した文字列に値が入らないか心配しはじめるだろう。
- 292 名前：デフォルトの名無しさん mailto:sage [2008/02/27(水) 21:21:11 ]
- 変数変数って何よ？
- 293 名前：デフォルトの名無しさん mailto:sage [2008/02/28(木) 00:16:52 ]
- XMLリテラルとか変数変数とか向こうで要望出したらどうだ？（当然英語だけどｗ）
- 294 名前：デフォルトの名無しさん mailto:sage [2008/02/28(木) 06:07:06 ]
- ようはEL式風のヒアドキュメントがあればHappyってこったな
- 295 名前：デフォルトの名無しさん mailto:sage [2008/02/28(木) 22:47:11 ]
- null代入を禁止する型が欲しい。
契約プログラミングまでいかなくていいので、
派生型としてnull代入を禁止する型がほしい。
- 296 名前：デフォルトの名無しさん mailto:sage [2008/02/28(木) 22:55:28 ]
- >>295
FindBugs の @NonNull で我慢
- 297 名前：デフォルトの名無しさん mailto:sage [2008/02/28(木) 22:59:00 ]
- >>296
できれば代入操作時にnullが指定されたら動的に例外投げてくれるような仕組みがあるとうれしいんだけどね。
FindBugsのそれはしらなかったよ。使ってみる。
- 298 名前：デフォルトの名無しさん [2008/02/29(金) 04:57:36 ]
- このnullについては、ライブラリや言語（仕様）やjvmで解決できる問題じゃないと思うんだが、単んに愚痴をこぼしてるだけ？
- 299 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 05:08:38 ]
- JVM まで持ち出すなら何でもできるじゃん。
- 300 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 05:21:03 ]
- 正直イラン
- 301 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 07:48:05 ]
- そしてJavaは「C++Jあヴぁ」となりました。
- 302 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 22:48:25 ]
- >>298
既存のライブラリを呼ぶときキャストの嵐になるのを覚悟すれば、
null代入可能なものと不可能なものを型システムで区別すること自体は簡単。
Cでいうと、普通のポインタはNULLポインタ型と非NULLポインタ型のunionだと思えばいい。
- 303 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 22:58:23 ]
- バグ検知のための利便性向上目的でしょ。アスペクソ指向 & アサーション方面からの
アプローチでする話じゃないのかな。String s not null と思いつきで書いてみると、いずれ
テーブルのカラム宣言のようなカオスになりそうだが。
- 304 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 00:45:54 ]
- 俺の欲しいのとしてはこんな感じ：
String! s; s = null; // 文法エラー
String t = null; s = t; // 実行時エラー
public void hoge(final String! s){
s.~~(); // 絶対にNullPointerExceptionがおこらない
}
class Hoge<T!>{ }
List<Object!> o = anotherList; // 要素がnullでもとおっちゃうなあ…
|
 |
