アカウント名:
パスワード:
これに先だって、クライアントサイドでJavaの利用を促すために、高速化をはかったコンシューマJavaこと、 Java SE 6 Update 10 [sun.com]が10月23日に公開されてますね。
ケータイではよく使われるJavaですが、PCやウェブブラウザ上での復活はあるんでしょうか?ハードウェアの性能も上がってますし、ソフト的に高速化が計られるのなら、Javaのクライアントサイドでの利用も悪くないかなと思うのですが。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家
コンシューマJava (スコア:2, 興味深い)
これに先だって、クライアントサイドでJavaの利用を促すために、高速化をはかったコンシューマJavaこと、 Java SE 6 Update 10 [sun.com]が10月23日に公開されてますね。
ケータイではよく使われるJavaですが、PCやウェブブラウザ上での復活はあるんでしょうか?ハードウェアの性能も上がってますし、ソフト的に高速化が計られるのなら、Javaのクライアントサイドでの利用も悪くないかなと思うのですが。
いつも主観で書き込んでいます
Re: (スコア:1, 興味深い)
むしろ処理は速かったです。
うまくいかなかった原因はAWTだと思います。
最初のAWTで酷い目にあった開発者たちは、一番メジャーなWindowsだけをサポートすべき、という考えをさらに固めてしまいました。
マイクロソフトのJavaVMが邪悪だったとか、そういう話をする人もいますが、
たしかに、マイクロソフトのCOMとのインターオペラビリティ部分は勝手な拡張でしょうが、
AWTについては、どの環境でも同じ見た目と動作をするような仕様にしなかったSunが悪いのです。
Re:コンシューマJava (スコア:1, 興味深い)
それからSwingも原因だな。
表示されるまで何十秒も待たせるファイルダイアログとか、
妙に太いフォントとか、プラットフォームを無視してダッサいUIを表示して、
いかにも使えないというイメージを決定付けたと思う。
むしろ、プラットフォームごとに本来のルックアンドフィールを実現できるAWTの方が評価できると思う。
まずかったのは実装じゃないのかな。