- 1 名前：デフォルトの名無しさん [2007/05/12(土) 08:25:15 ]
- 前スレ
[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/
- 220 名前：デフォルトの名無しさん mailto:sage [2007/08/05(日) 09:39:23 ]
- >>211はここを見るべき
www-06.ibm.com/jp/developerworks/java/051104/j_j-jtp09275.shtml
- 221 名前：デフォルトの名無しさん [2007/08/05(日) 10:18:29 ]
- >>220
おまえ191だろｗｗｗ
そんな記事は知ってるわ。
そもそもインライン化とエスケープ解析は違う。
- 222 名前：デフォルトの名無しさん mailto:sage [2007/08/05(日) 13:22:13 ]
- >>211
> Javaのコンパイラはソースコードとバイトコードの対応付けが規定されているので、
> そもそもバイトコードの最適化はありえない。
（ ﾟдﾟ）ﾎﾟｶｰﾝ
- 223 名前：デフォルトの名無しさん mailto:sage [2007/08/05(日) 14:45:58 ]
- >>221
そうだね、エスケープ解析した結果として、スタックアロケーションしたりインライン化したりするんだね。
違う階層の言葉だったね。
- 224 名前：デフォルトの名無しさん mailto:sage [2007/08/05(日) 14:47:26 ]
- if(true)が無視されてバイトコードに埋め込まれないのは、バイトコードの最適化といわないのかな。
- 225 名前：デフォルトの名無しさん mailto:sage [2007/08/05(日) 14:54:08 ]
- メソッドに仮実装がある場合で、その処理を通さずメソッドの先頭で値だけ返したい場合とか
if (true) を未到達エラー回避にたまに使うな。C#はboolを変数化しなきゃいけなくて面倒だ。
ああ、まるで脱線した話題だけどね。
- 226 名前：デフォルトの名無しさん mailto:sage [2007/08/05(日) 14:59:07 ]
- インライン化はエスケープ解析の結果じゃないけど、まぁいいや。
もうちょっとスレタイトルにふさわしい話題ないの
- 227 名前：デフォルトの名無しさん mailto:sage [2007/08/05(日) 15:02:44 ]
- ならクロージャとJAM以外で見所のある機能があれば紹介して。
- 228 名前：デフォルトの名無しさん mailto:sage [2007/08/05(日) 15:03:08 ]
- template萌えな私を叱ってください。
- 229 名前：デフォルトの名無しさん [2007/08/05(日) 16:24:56 ]
- JITは標準のコンパイル結果に対して最適化するように動くので、
バイトコードへコンパイルするときは、
明らかな最適化が可能なもの意外は何もしないよ。
バイトコードへコンパイルする時に、
Javacが生成しない最適化されたバイトコードを生成すると、
JITは最適化の対象外になるからかえって遅くなる。
Javacを無視してバイトコード生成するのはJikesぐらい
- 230 名前：デフォルトの名無しさん mailto:sage [2007/08/05(日) 16:29:39 ]
- ん？javacって最適化方針まで規格化されてるの？
- 231 名前：デフォルトの名無しさん mailto:sage [2007/08/05(日) 16:31:19 ]
- 規格化なんかされてないでしょ。
特定の実装の話じゃないの？
- 232 名前：デフォルトの名無しさん mailto:sage [2007/08/05(日) 16:33:24 ]
- javacが生成しない最適化されたバイトコードって話がどこからでてきたのかがわからん
- 233 名前：デフォルトの名無しさん mailto:sage [2007/08/05(日) 17:44:13 ]
- そもそも今のjavaの動的コンパイル技術はJITじゃなくてHotSpotだろ。
>>141
jdkのRhinoはMozillaのRhinoコードが実行できないほどの超絶劣化品。
あれらのエンジン間に互換性はないよ？
Rhinoの実装ライブラリがsun.*パッケージに移動されてるから
Rhinoに含まれるセキュリティーライブラリがどの常に利用できるとも限らんし、
バイトコード吐かないから常にインタプリタモードで動いて遅いし。
E4Xないし。上げ出したら切りがない。
- 234 名前：デフォルトの名無しさん mailto:sage [2007/08/05(日) 21:45:36 ]
- >>233
HotSpotは、実行時間食ってる箇所を見つけてJITコンパイルする。
もしくは、あんまし実行されない箇所のJITコンパイルを抑制する。
大雑把な議論をする場合はJITでもHotSpotでもどっちでも良い。
変な拘り持ってる奴を相手にするんでなければ。
- 235 名前：デフォルトの名無しさん mailto:sage [2007/08/05(日) 22:06:34 ]
- 3回動くとコンパイルが走ると感覚的に判断してるから、
ベンチマーク前は、10回は回してからやってる。
server vmってのは何時間も動かすと更に最適化されたりするんだろうか
- 236 名前：デフォルトの名無しさん mailto:sage [2007/08/06(月) 03:18:49 ]
- >>234
でもそれって最適化方法が同じ実装の場合に限られない？
サーバー向けVM製品とかの中にはHotSpotと同じ適応型最適化コンパイルするけどVM実装の都合で
あえて変わったタイミングでコンパイルしたりする奴居るよ。
>変な拘り持ってる奴を相手にするんでなければ。
てのはこいつらのこと？
- 237 名前：デフォルトの名無しさん mailto:sage [2007/08/06(月) 08:15:35 ]
- >>235
感覚に頼んじゃなくて -XX:+PrintCompilation とか -Xbatch とか使ったほうがいいと思うけど
- 238 名前：デフォルトの名無しさん mailto:sage [2007/08/06(月) 09:30:04 ]
- >>236
一切JITコンパイルしない最適化方法の事をJITって言ってたら
話が通じなくなるから問題だけど、タイミングが変わるぐらいなら問題ないでしょ。
- 239 名前：デフォルトの名無しさん mailto:sage [2007/08/06(月) 11:41:02 ]
- >>236
> あえて変わったタイミング
kwsk
- 240 名前：デフォルトの名無しさん mailto:sage [2007/08/06(月) 16:57:02 ]
- >>239
たまたま見つけたんで製品名は知らんが
アプリケーションが１度走り出したら負荷のかかるGC/動的コンパイルを
徹底的に発生させないために実行初期にとっとと見切りプロファイルしてマシン語吐いちゃってシステムの稼働を優先させるタイプのVMをどっかで見た。
でも、実行初期段階からボトルネック見つけたりパフォーマンスを平均化する技術を使ってるらしくAOTじゃないみたい。
民生用じゃないVMなんかはそういう変わった実装見るよ。
>JITコンパイルしない最適化方法の事をJITって言ってたら
MEベンダの中にはただのインタプリタ最適化を"独自の"JIT技術と呼んでるところもあるんだなｗ
漁ると結構変なVMっていっぱい。
あと、JITをただの動的コンパイル（OR最適化）のことだと思ってる奴とか。
- 241 名前：デフォルトの名無しさん mailto:sage [2007/08/06(月) 17:00:03 ]
- 語義的には Just In Timeで何かしてたら、なんでもJITになるわな。
- 242 名前：デフォルトの名無しさん mailto:sage [2007/08/06(月) 17:23:51 ]
- JITコンパイラと名乗ってなければ、
> ただのインタプリタ最適化を"独自の"JIT技術と呼んでる
なんの問題もないだろ。
- 243 名前：デフォルトの名無しさん mailto:sage [2007/08/07(火) 15:30:39 ]
- JSR-308に関してこんなん見つけた。
pag.csail.mit.edu/jsr308/
正式リリースからは削除予定だけど、JDK7の開発期間中は暫定的に、
/*@Readonly*/ Object x;
みたいのがあると、アノテーションとして認められるらしいんだけど、
これJDK6以前とJDK7以降で共用のライブラリ書くとき便利だから
言語仕様として残して欲しかったり……
JMLみたいな既存のツールが既に/*@...... */ ってタイプのコメント使ってるので
言語仕様に組み込むのはダメって話らしいんだけど。
- 244 名前：デフォルトの名無しさん mailto:sage [2007/08/08(水) 03:26:00 ]
- コメントに書くのは邪道。
- 245 名前：デフォルトの名無しさん mailto:sage [2007/08/08(水) 19:26:13 ]
- >>243
そーゆー事やりたいんだったら、JDK7以降用にソースを書いておいて、
Tree API とか使ってアノテーション落とした方が良いかもね。
- 246 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 11:58:02 ]
- エスケープ解析って、*.javaを解析するのか、*.classを解析するのかどっちなの？
- 247 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 12:35:59 ]
- >>246
.javaはまず無い。バイトコードにスタックにオブジェクトアロケーション
する命令なんか無いんだから。おそらくバイトコードをJITコンパイルする
段階でエスケープ解析していると思われる。
- 248 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 13:00:12 ]
- >>243
> @Readonly Object x;
> if (x instanceof Date) { ... } // error: incompatible annotations
> if (x instanceof @Readonly Date) { ... } // OK
> Object y;
> if (y instanceof Date) { ... } // OK
> if (y instanceof @NonNull Date) { ... } // error: incompatible annotations
これ必要なんだろか？ 型アノテーションってインスタンス毎に
ついてるわけじゃなくてerasureなgenericsと同じような扱いでしょ。
こんなん付けても無駄に長くなるだけなんじゃ……
- 249 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 13:10:08 ]
- エスケープ解析って、
＞バイトコードをJITコンパイルする 段階
の技術だったのか。よくわかった。
ただ、「思われるとか」憶測で語っているのはどうかと。
- 250 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 13:32:15 ]
- 思われなくても、JITコンパイル時の処理です。
- 251 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 13:47:33 ]
- >>248
if (list instanceof ArrayList<String>) { ... }
とかはコンパイルエラーになるのにな。
一貫性がないっつーか……
- 252 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 13:49:34 ]
- >>250 よくよくわかった。
- 253 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 14:00:37 ]
- >>243
なんつーか互換性重視だった 1.5 までと、
どっちかっつーと互換性軽視 機能追加重視の最近の風潮で
ねじれが出てるような気もする。
こんぐらい無節操に機能追加される（予定だ）とプリプロセッサ使いたくなるよな。
>>245 のも発想的にはプリプロセッサだし……
- 254 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 14:30:29 ]
- アノテーション使わなければ、互換性あるんだからいいんじゃね？
- 255 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 14:36:28 ]
- どの互換性を軽視だって？
- 256 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 14:45:12 ]
- >>255
write once compile any version が出来ない、
もしくは無理にやろうとすると、新機能使えなくて不便になるって話。
- 257 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 15:03:26 ]
- 内部でクロージャが使えない、とかは我慢すれば良いとしても
古いバージョンもサポート対象に入ってて JSR-308みたいのが使えないと
新バージョンで使う時に型情報が減るからな。
- 258 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 15:22:20 ]
- >>256
（ ﾟдﾟ）ﾎﾟｶｰﾝ
- 259 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 15:38:30 ]
- >>256
まぁ、言語として複数バージョンに対応するための配慮なんかは一切無いな。
#ifdef 使えばソース汚くても複数バージョンに対応できるみたいな救済策もないし。
- 260 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 15:39:23 ]
- 相手に合わせようとするのは、JAVAらしくないな。
逆に、相手がJAVA（JVM）に合わせろってところにJAVAの互換性がある。
- 261 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 15:40:54 ]
- >>256
クラスワーキング・ツールキット: 古いJVMでJ2SE 5.0の機能を使う
www-06.ibm.com/jp/developerworks/java/050819/j_j-cwt07065.shtml
JavaのGenericsに関しては、上位互換性(下位互換性ではなく！)を満たすために
Erasure方式で実現したから、コンパイルオプション指定でJDK1.4でも動くはずだが。
- 262 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 15:40:54 ]
- >>257
まず型ありきの言語で型情報減るのは痛いよな。
- 263 名前：261 mailto:sage [2007/08/09(木) 16:02:17 ]
- javac -source 1.5 -target 1.4 Test.java
javac: リリース 1.5 のソースにはリリース 1.5 のターゲットが必要です。
と言われてしまった。偽情報スマソ。
一応、Retroweaverを使えば可能なようだが．．．
Retroweaver supports most 1.5 features while running on 1.4.
* generics
* extended for loops
* static imports
* autoboxing/unboxing
* varargs
* enumerations
* annotations
JDK1.4でコンパイルされたライブラリを、
JDK1.5 以降でGenericsなライブラリとして利用するのは可能だよな．．．
というかこれが無理なら何のためのerasure方式採用なんだよって感じだが。
- 264 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 16:02:53 ]
- >>261
-target jsr14 だっけ？ 文書化されてないんだよね、これ。
- 265 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 16:05:35 ]
- >>263
> JDK1.4でコンパイルされたライブラリを、
> JDK1.5 以降でGenericsなライブラリとして利用するのは可能だよな．．．
可能っちゃ可能だけど、パラメタ型の情報無いよ
- 266 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 16:14:57 ]
- >>264
-target jsr14を使うと可能でした。ｔｈｘ。
Java の理論と実践: Java 5 の言語機能を以前の JDK で使う
www-06.ibm.com/jp/developerworks/java/library/j-jtp02277.shtml
列挙型以外はほぼ問題ないようだ。
- 267 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 17:24:49 ]
- >>266
JDK5以降のライブラリや、メソッドを使うときに注意。
Autoboxingなどはちゃんと処理される。
- 268 名前：デフォルトの名無しさん [2007/08/10(金) 01:25:21 ]
- win32 apiとか触るの面倒だし、だれかjvm上で.netが動くの作ってくれないかな
C＃をインタプリタ実行するのでもいいからさ
- 269 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 01:26:53 ]
- >>268
それはそれで凄まじいな
……考えてみるか。
- 270 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 01:51:45 ]
- C# を Java バイトコードにコンパイルする方が楽じゃない？
- 271 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 02:08:05 ]
- エスケープ解析は、*.javaに対して行っておくほうが実行効率がいいけど、その情報を*.classに残す手段がないので、実行時の最適化でしか使われていない
- 272 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 02:12:52 ]
- >>249
>>247だが、実際にソースまで追って確認したわけじゃないので
そういう表現になっただけで、JITコンパイル段階でやってるのは
ほぼ間違いないよ。まあ、厳密に言えばインタープリタモードでも
やってる可能性もあるけど、メリットが考えられない。
- 273 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 03:03:50 ]
- 手段がないわけじゃないと思うけど。
stackmapっぽい新しい属性をクラスファイルに追加すればいいんだし。
ただ、静的に解析しても効果が弱いと思う。
メソッドの非仮想化やインライン展開を終えた後にやる方がいい。
- 274 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 03:17:31 ]
- >>273
それは、メソッドの非仮想化とインライン展開がエスケープ解析に与える影響がすごく大きいってこと？
そうは思えないんだけど。
- 275 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 03:46:33 ]
- >stackmapっぽい新しい属性をクラスファイルに追加すればいいんだし。
これは上で出てきたstructをJava言語でサポートするんじゃなくて、
JVMでサポートするってのに実質的に近いんじゃないか？
- 276 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 03:55:03 ]
- >>274
例えばさ、
public Object[] foo()
{
Vector v = makeVector();
v.add("bar");
v.add("hoge");
return v.toArray();
}
public Vector makeVector()
{
return new Vector();
}
みたいなコードがあったとするじゃない。 (例がやや作為的だけど、そこは目を瞑っていただきたい。)
いっけん v は foo の外にエスケープしてないように見えるけど、add とか toArray とかの中で this をどこかの static 変数に保存しているかもしれない。
誰も Vector クラスのソースを見たことあるわけじゃないし (あるかもしれないが)、 Vector がそういう変な実装になってないとは断言できまい？
そういうわけで、この時点では v をスタック上にアロケートしてしまうわけにはいかない。
(this をどこかの static 変数に保存したりできなくなってしまう。スタックは foo を抜けたら消滅するんだし。)
でも add とか toArray とか makeVector とか Vector コンストラクタを全部インライン展開できれば、v が foo の外にエスケープしてないかどうかがはっきりする。
エスケープしてないと判れば、もう別に Vector を new する必要なんかなくなって、 Vector の全フィールドをみんなスタック上に展開してしまえる。
makeVector は final じゃないから実はオーバーライドされてて他のクラスを返してるかもしれないが、これも非仮想化されてればインライン展開できる。
・・・って思ってるんだけど、現実のJVMがどこまでやってるかは知らない (´･ω･`)
- 277 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 04:44:16 ]
- >win32 apiとか触るの面倒だし
ここらへんあるから実質C#はマルチプラットフォームじゃないよね。
- 278 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 09:53:41 ]
- >win32 apiとか触るの面倒だし
それだけだったら、win32 api を触らなくて済むようなGUIフレームワークとかを使えばいいだけと違うん？
- 279 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 09:56:34 ]
- >>273
> ただ、静的に解析しても効果が弱いと思う。
> メソッドの非仮想化やインライン展開を終えた後にやる方がいい。
二行目は静的/動的と関係ないじゃん。
- 280 名前：278 mailto:sage [2007/08/10(金) 09:57:41 ]
- って、.C# か・・・ じゃあ GTK# とか・・・ びみょかな・・・
- 281 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 11:35:35 ]
- >>279
静的に＝.javaのコンパイル時にって意味で書きました
.javaコンパイル時に非仮想化・インライン展開とかできないでしょ
わかりにくくてごめんなさいね
この暑さでちょっと疲れてるんだ
- 282 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 11:49:09 ]
- 出来ないことないじゃん。もうInner classあるんだから。
- 283 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 11:54:25 ]
- Inner class って、なんか関係が？
- 284 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 11:59:12 ]
- インナー・クラスの非仮想化・インライン展開はソース・コンパイル時に出来る。
- 285 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 12:21:17 ]
- --- Outer.java ---
public class Outer {
class Inner {
int foo( ) { return 1; }
}
void bar( Inner inner ) {
System.out.println( inner.foo( ) );
}
}
インナークラスってこういうのでしょ。
inner.foo( ) をインライン展開するつもり？
--- Main.java ---
public class Main {
public static void main( String[] args ) {
Outer outer = new Outer( );
Outer.Inner inner = outer.new Inner( ) {
int foo( ) { return 2; }
};
outer.bar( inner ); // → 2 を出力する
}
}
- 286 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 12:42:11 ]
- そもそもprivate:ならインライン展開し放題じゃない。
- 287 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 12:45:06 ]
- それはまぁね。
- 288 名前：デフォルトの名無しさん [2007/08/10(金) 17:18:14 ]
- で、実際デフォルトで（知らないところで）インライン展開はされているのか？
それも、メモリ上に展開なのか、ソースコード（.class）のバイト数が増加しているのか。
- 289 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 17:20:42 ]
- > で、実際デフォルトで
（ ﾟдﾟ）ﾎﾟｶｰﾝ
- 290 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 17:45:00 ]
- はいはい、あげあし君はさようならで
- 291 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 17:58:23 ]
- 似たようなことを議論してるよ。
stack allocateについては、
アノテーションで指示するか、
ByteBufferでアドレッシングしてくれってことのようだ。
bugs.sun.com/bugdatabase/view_bug.do?bug_id=4820062
- 292 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 18:31:07 ]
- >>291
そこの議論の対象はC/C++の struct で作られたような
データ構造にアクセスする事であって、
言語仕様的に stack allocated object が欲しい場合は
bugs.sun.com/bugdatabase/view_bug.do?bug_id=4213096
bugs.sun.com/bugdatabase/view_bug.do?bug_id=4809540
どっちかにvoteしろって書いてあるよ
- 293 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 18:35:28 ]
- C# だと各メンバに FieldOffset が指定できるよね
>>291 はそういう話じゃないの？
- 294 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 18:54:29 ]
- >>292
で、君はそっちのREFをチェックしてからものを言ってるわけなのかな？
>>293
C#がどうしたって？
ざっとみてスタックがどうとか言う議論になってたから似たようなの出してみたのだけど。
- 295 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 19:02:35 ]
- いや、データをバイト列にパックする話とスタックアロケーションは別の問題だから。
- 296 名前：デフォルトの名無しさん mailto:sage [2007/08/11(土) 03:07:02 ]
- 君の都合にあわないからといって、いちいち相手にｹﾁをつけるところは君の悪い癖だな
- 297 名前：デフォルトの名無しさん mailto:sage [2007/08/11(土) 16:11:19 ]
- なあ、全員「デフォルトの名無しさん」じゃねえか
同一人物間でケンカ自演してるのってどうよ
って突っ込んでるオレも同一人物な訳だが
- 298 名前：デフォルトの名無しさん mailto:sage [2007/08/11(土) 16:22:00 ]
- 夏休み的なツッコミだな
- 299 名前：デフォルトの名無しさん mailto:sage [2007/08/11(土) 19:00:47 ]
- ボケだろ、ボケ
- 300 名前：デフォルトの名無しさん mailto:sage [2007/08/13(月) 15:24:33 ]
- ノリツッコミか
- 301 名前：デフォルトの名無しさん mailto:sage [2007/08/18(土) 04:47:25 ]
- JDK7 build18
download.java.net/jdk7/changes/jdk7-b18.html
download.java.net/jdk7/binaries/
細かいバグ修正とか。
- 302 名前：デフォルトの名無しさん mailto:sage [2007/08/19(日) 07:15:13 ]
- java LnFっていずれocanからSwing new LnFと謳ってるNimbusになるのかね？
- 303 名前：デフォルトの名無しさん mailto:sage [2007/08/19(日) 08:19:46 ]
- Nimbusはスクロールバーがヤだ
- 304 名前：デフォルトの名無しさん [2007/08/19(日) 15:38:42 ]
- 確かにへぼいな
- 305 名前：デフォルトの名無しさん mailto:sage [2007/08/19(日) 16:52:27 ]
- javaのスレでC#の話をするなボケども
- 306 名前：デフォルトの名無しさん mailto:sage [2007/08/19(日) 17:31:28 ]
- JSR 310ってどうよ
- 307 名前：デフォルトの名無しさん mailto:sage [2007/08/19(日) 19:22:01 ]
- >>302
Nimbusはごっつい雰囲気が強すぎて微妙ー
Aquaとかみたいな甘いデザインにしてくれと思う。
>>306
各所のブログでJSR 310は入れてほしくないと言われているな。
どうなんだろう・・・
- 308 名前：デフォルトの名無しさん mailto:sage [2007/08/19(日) 19:34:49 ]
- 使うことはあまりないだろうな。
- 309 名前：デフォルトの名無しさん mailto:sage [2007/08/19(日) 20:46:56 ]
- >>306
オレは JSR-310 スライドに入ってる
> What's wrong with Date?
> ・Uses two digit years from 1900
> ・January is 0, December is 11
のセンスを見て、なんだかなー と思った。
この辺って、たぶん Cの標準ライブラリの
struct tm と同じ方式になってるだけでしょ。
きちんと文書化してあれば大して問題になるとも思えんし……
- 310 名前：デフォルトの名無しさん mailto:sage [2007/08/19(日) 21:28:31 ]
- >>306
https://jsr-310.dev.java.net/nonav/javadoc/index.html
- 311 名前：デフォルトの名無しさん mailto:sage [2007/08/20(月) 17:49:33 ]
- >>309
いや、正直、1月が0とかは文章にしていてもあり得ない。
使うたびにAPIをその仕様で設計したヤツに殺意を覚える。
ライブラリの使い方からCと違うんだから中途半端にわかりにくくしてるだけ。
- 312 名前：デフォルトの名無しさん mailto:sage [2007/08/20(月) 18:02:22 ]
- 文章化してあるから問題なしって・・・
- 313 名前：デフォルトの名無しさん mailto:sage [2007/08/20(月) 18:56:22 ]
- >>311
分かりにくいっても、C言語使った事あれば1月が0になる事もあるってのは予測可能だし。
不勉強な上に不注意な連中が躓く原因であるのは確かだろうけど、
たぶん、そういう連中は 月フィールドが 1オリジンになったら Calendar と互換性なくなって躓くだろう。
ゼロから新しいAPIを作るならともかく、既存の Calendar と共存するつもりなら、
新しいクラスを作って、そのクラスの月フィールドを 1オリジンにしたぐらいじゃ幸せにはなれない。
- 314 名前：デフォルトの名無しさん mailto:sage [2007/08/20(月) 19:37:12 ]
- >>311
まぁ有り得ないとか殺意を覚えるってのは程度の差だからなんとも言えんけど。
オレとしては 1月を 1 にしたければ、とりあえずユーティリティメソッド1つ作れば良いと思うんだわ。
で、オレの感覚からすれば、ユーティリティメソッド1つで解決するような問題を掲げて
わざわざ新API作ろうって感覚の方が有り得ないんだわ。
スライド見て感じた事ってのはそーゆー事。
- 315 名前：デフォルトの名無しさん mailto:sage [2007/08/20(月) 19:43:10 ]
- 今から新しく作るんなら、enumにすればいいんじゃまいか。
public enum Month { JANUARY, FEBRUARY, ... }
- 316 名前：デフォルトの名無しさん mailto:sage [2007/08/20(月) 21:05:04 ]
- そして旧暦閏月で困ると。
- 317 名前：デフォルトの名無しさん mailto:sage [2007/08/20(月) 21:21:43 ]
- 閏月対応してるクラスってあったっけか？
- 318 名前：デフォルトの名無しさん [2007/08/20(月) 23:19:30 ]
- Timeの方は刹那とかに対応しないかなと思ってみたりｗ
10^-18なんて精度表せないだろうが。単位として扱えたら面白そう。
- 319 名前：デフォルトの名無しさん mailto:sage [2007/08/20(月) 23:25:25 ]
- 誰が使うんだ、そんなもん……
- 320 名前：デフォルトの名無しさん mailto:sage [2007/08/20(月) 23:41:02 ]
- ナノ時間取得はコストが高すぎるんだよな・・・
|
 |
