アカウント名:
パスワード:
どっちがオープンかというのは多分に印象論になりがちなので、それはそれとして、MSのJavaVMについては、Sunからライセンスを受けた際の条項に抵触した実装を続けたと、Sunが起こした訴えを裁判所が認めて停止命令を出した結果でしょう。特に問題視されたのは、JNIではない独自のインタフェース(J/Direct)を用意し、透過的にWindows APIと結び付けていた点だったかなぁ..。MS VMにはこの裁判所命令に沿った警告文がCDに添付されていた記憶があります。
MSのJavaVMの独自拡張は、使うかどうかは自由であり、使わない限りにおいては互換性がちゃんと取れていた。
この辺りは当時のMSの狡猾さがにじみ出ていて、Visual J++で(これをエディタとしてのみ使うなら別として)アプリケーションを作ると自動的に使ってしまうということも問題となってました。MS VMへの命令とともに、Visual J++がデフォルトでこの機能を有効としないこと、使用する場合には警告表示を行い、使用者の同意を得てから有効にするようにということになっていました。
一方で、MS VMはJNIをサポートしておらず、ネイティブコードの呼び出しに関しては互換性がありませんでした(裁判やSunとの和解ののちにMS VMにJNIを追加しました)。
デスクトップ領域でのJavaの伸び悩みは当時のJavaの完成度や互換性の低さが原因であり、MSが扱うかどうかは大きくは影響しなかったのではないかと思います。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
マイクロソフトは意外とオープン (スコア:1, おもしろおかしい)
マイクロソフトはSunのオープンを信じてJavaVMを作りましたが、それに対してSunはJavaVMをクローズドに保つためにマイクロソフトのJavaVMを潰しました。Sunよりもマイクロソフトのほうがオープンなのは明らかですね。
Re: (スコア:2, 参考になる)
どっちがオープンかというのは多分に印象論になりがちなので、それはそれとして、MSのJavaVMについては、Sunからライセンスを受けた際の条項に抵触した実装を続けたと、Sunが起こした訴えを裁判所が認めて停止命令を出した結果でしょう。特に問題視されたのは、JNIではない独自のインタフェース(J/Direct)を用意し、透過的にWindows APIと結び付けていた点だったかなぁ..。MS VMにはこの裁判所命令に沿った警告文がCDに添付されていた記憶があります。
Re:マイクロソフトは意外とオープン (スコア:0)
(むしろ、独自拡張ではない部分、文字コード絡みとかAWTの仕様が不明瞭で振る舞いが違うとかのほうが厄介だった。)
Javaでコードを書く側に自由に選択を任せればいいのに、SunはJavaVMの機能について独裁者だったね。
SunがMSを訴えた結果、WindowsやIEへのMSのJavaVMのバンドルがなくなり、わざわざSunのJavaVMをインストールせねばならないということになり、デスクトップでのJava利用は急激に萎えた。
その後、SunのJavaVMの実装は、かつてのMSよりも脆弱だということが露見したり、JREのバージョン違いやら何やらでグダグダしたりで、結局、MSのJavaVMを潰したのは裏目に出てる。
Re: (スコア:0)
この辺りは当時のMSの狡猾さがにじみ出ていて、Visual J++で(これをエディタとしてのみ使うなら別として)アプリケーションを作ると自動的に使ってしまうということも問題となってました。MS VMへの命令とともに、Visual J++がデフォルトでこの機能を有効としないこと、使用する場合には警告表示を行い、使用者の同意を得てから有効にするようにということになっていました。
一方で、MS VMはJNIをサポートしておらず、ネイティブコードの呼び出しに関しては互換性がありませんでした(裁判やSunとの和解ののちにMS VMにJNIを追加しました)。
デスクトップ領域でのJavaの伸び悩みは当時のJavaの完成度や互換性の低さが原因であり、MSが扱うかどうかは大きくは影響しなかったのではないかと思います。