- 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/
- 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 ]
- ナノ時間取得はコストが高すぎるんだよな・・・
- 321 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 01:23:50 ]
- >>319
坊さん用ソフト開発なプログラマｗ
24時間=30牟呼栗多=900臘縛=54,000怛刹那=6,480,000刹那という変換するとか。
スウォッチインターネットタイムも欲しいな。
- 322 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 01:33:32 ]
- 坊さん用なら卒塔婆プリンタの方が喜ばれそうだが。
っつか、Wikipedia漁って適当な事言ってるだけじゃね？
- 323 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 08:50:41 ]
- www.atmarkit.co.jp/news/200708/20/httpcomp02.png
同じくフォーチュン1000企業のWebサイトを対象とした調査で、
アプリケーションサーバのシェアはASP/ASP.NETがトップで51.5％のシェアと2年前から7.9ポイントの上昇。
J2EE、JSP、WebLogic、WebSphere、TomCatなどのJavaプラットフォームが2位で12.7％。
そのほか、PHP（6％）、ColdFusion（3.2％）、Perl（1.9％）、Python（0.2％）などとなっている。
とりあえず、ASP.NETの普及が断トツに進んでいる。
Javaは新規プロジェクトで採用される可能性はほとんどなくなってきてるしな。
- 324 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 09:53:51 ]
- そろそろJava終了のアナウンスがSunからあるのかな
まぁいい思い出になったよ
- 325 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 10:20:43 ]
- >>323
ASPとASP.NET合計で51.5％か。意外に低シェアだな。
>>324
Sunあぼーんして、IBM & Google が実権を握ってくれる方が嬉しいなぁ。
- 326 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 10:23:58 ]
- >>315
一応、Calendar.JANUARYとか定数ならあるよ。
そっち使うでしょ普通。
- 327 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 10:24:54 ]
- あ、そっち使うでしょ、ってのは0とか1とかじゃなくて、って意味。
enumならなおよろしいけど、互換の問題がねぇ・・・。
- 328 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 13:37:56 ]
- >>327
日付扱うときは、だいたいユーザー入力だから無意味。
プログラム中でJANUARYとか指定することなんてあまりないんじゃね？
- 329 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 16:31:57 ]
- ユーザー入力を文字列として持ち回すと難儀だよね。
でも、WEBアプリにしろSwingにしろ、フレームワークとか
日付入力コンポーネントとかでDate型で最初から
扱える奴あるし、今時大概そうじゃないのかな。
プログラムの中で月決め打ちってのは確かにあまりないですね。
テストコードくらいか。
- 330 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 17:51:54 ]
- >>314
いや、ラッパークラスを用意すればいいってのはユーザ側の対応になる。
それはつまり、現状のDate型の変更に依存する訳だし
自分が書いたコードはラッパークラスを必ず含まなくてはならなくなる。
それならコアAPIに入っててくれよ、と思わないか？
今のDate型の実装だと、実装者自身が作り直したいと考えても
仕方がないような作りが多々ある。Calendarを追加して手当したけど
時間、日時を扱う場面は多くある。
これだけJavaが使われてその問題点が明らかになったんだから
新しくより合理的なAPIができてもいいと思う。
言うなればJava3とでもいうものへのへの緩やかな変化。
基本的なモノだからこそ改良が重要になってくるとは思うんだ。
アトは失敗しないようにしっかりと作ろうってところだろうか。
- 331 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 18:15:12 ]
- Calendarいらないってがんばっている人もいる。
tp://d.hatena.ne.jp/nowokay/20070628
tp://d.hatena.ne.jp/nowokay/20070630
これが本当に通ってくれれば
憂いなしで嬉しいな。
- 332 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 18:29:39 ]
- つか、きしださんまで月間違ってるし！
- 333 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 19:05:53 ]
- >>330
ラッパークラスで解決しようというのはダメだろ。
Calendar の set やら get を ラップして 1月が1になるようにしても、
自分の目の届く範囲だけなら構わないけど、
第三者が作ったクラスに渡す場合には、そのまま渡したら 1ヶ月ずれる。
そんなゴミをコアAPIに入れられたら、 Calendar をやり取りする
メソッド作る場合に、必ず instanceof とかでチェックしなきゃいけなくなる。
- 334 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 19:08:21 ]
- >>331
無理じゃね？
java.util.Date は Serializeable だし、
Date の TimeZone対応とかやったら、
シリアライズされたデータの互換性なくなるんじゃないか？
- 335 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 19:10:30 ]
- W3C-DateTimeからRFC2822-DateTimeに用意に変換できるようなものが欲しい。
RFCのほうはCWFSのおかげでやたらパースがしにくい。
- 336 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 19:23:34 ]
- >>330
> これだけJavaが使われてその問題点が明らかになったんだから
> 新しくより合理的なAPIができてもいいと思う。
あっても良いけど、closure とかに比べると優先度は低いよね。
それに「問題点」ってのも個人個人で違うわけで、1月 が 0 なのがダメなのか、
setter の戻り値の型が void だから、1行に詰め込んで書けないのが問題なのか
それ以外なのか。
現状では愚痴とか不満は出てるけど、
それらを一つに纏めて、多くの人が納得でき、多くの人が幸せになれるような
解決策が提示されているかっていうと、少なくとも JSR-310 は違うと思う。
- 337 名前：デフォルトの名無しさん [2007/08/21(火) 20:22:16 ]
- >>335
まえにjavascriptの実装がどっかのブログで公開されてたぞｗ
|
 |
