アカウント名:
パスワード:
これに先だって、クライアントサイドで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 (スコア:2, 興味深い)
いろいろ違うと思います。JavaアプリでのGUIはWin32アプリと比べて
明らかにもっさりしていました。SwingもJDK1.4くらいまでは
かなーり遅かったです。
アプレットの場合JVMの起動が遅くてブラウザでアプレットを含むページに
アクセスするとイライラしました。MS製のJVMが悪いのはアプレット用VMの
話で、独自拡張のせいでSUNのJVMでは動かないアプレットが作られました。
しかもJDK1.1ベースでバージョンアップしなかったのでJDK1.2以降をターゲットにした
アプレットはSUNのJVMでないと動かない、でも入れ替えると独自拡張を使った
アプレットは動かないという状況になりました。私の会社ではこういった混乱に
備えてMS独自拡張を禁止していたのですが、顧客からは「お前のとこの推奨のJVM
入れたら今まで使ってたアプレットが動かなくなったぞふざけんな」という
クレームが来るのです。
ActiveXべったりの韓国ならともかく、日本にもMS独自拡張を使うベンダが結構
いたことに驚きました。アプレットが流行らなかった一番の理由はこれだと思います。
今ならFlash同様に「とりあえず最新にしとけばOK」なんで大丈夫なんじゃないでしょうか。
Re:コンシューマJava (スコア:1)
Re: (スコア:0)
Re: (スコア:0)
おかげでMSDNでWindows2000がダウンロードできねぇ。
Re:コンシューマJava (スコア:1)
因果関係からするとMSの自業自得でしかない。
また、MSのJavaVMが更新されないのは裁判でそういう条件で和解したからなので
これまたSUN(だけ)を責めるのは間違い。
当時のSUNのJavaのパフォーマンスが悪かったのは事実だけどもそれは別問題。