パスワードを忘れた? アカウント作成
866 story

SunがWinXP/IE6用のJavaVMを開発中 33

ストーリー by wakatono
Sun製とMS製、あなたが使うのはどちら? 部門より

C-D-W 曰く,"BiztechによるとSunがWinXP及びIE6用の JavaVMを開発中との事。
これはM$がWinXPとIE6にはJavaVMを搭載しないとの発表を受けてSun側が対応するVMを開発中であると明らかにしたと報じています。
実際にはM$はM$製JavaVMをダウンロードさせIE6に組み込む事ができるようにするらしいけど私はSun製のJavaVMを入れるだろうな~
Sun製のJavaVMの方が最新バージョンだしぃ"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by crouton (9) on 2001年08月22日 11時10分 (#15843)
    Java VM Selectorのことかな?
    --
    "Quidquid latine dictum sit, altum videtur."
  • by Dot.Zeile (1169) on 2001年08月22日 14時33分 (#15891) 日記
    >今回だって、SunがMSに最新のJavaVMを使うことを禁止したことから発展した問題だし、
    >そのようなSunのJavaVMを武器にしてWindowsXPの発売を妨害する可能性を危惧したMSが外しちゃうのも、ある程度は理解できます。

    うーん、ここだけ取り上げて何か言うのはやばいかも知れないけど、あんまり同意できないので一応。

    SunはMSがJavaの互換性を意図的にスポイルしようとしたから「そういうことはするな」と言っただけだと思うんですよね。結果的にMSがJavaの使用権を剥奪されたのは合意が得られなかったからでしょう。(ライセンスベースの話なんだから当たり前。)MSは最新のJavaではなくて自分達に都合のいいJavaを使いたがってただけですから。言い換えればMSは『「それでしか動かないJavaアプレット」なんての』(「それ」=「Windows/IE」)をどんどん増やそうとしたわけだ。SunはできることならMSにも最新仕様準拠のJVMを使って欲しかったと思ってると思うよ。

    ましてや、「SunがJavaVMの問題を盾にWindows XPの発売を妨害する」なんてMSが言ってるだけで、他の誰もそんなこと信じてないでしょう。今まで通りMSVM入れてリリースするようにしてたら何も起こらず今まで通りだったはず。

    あと、言語の仕様は熟成やニーズの変化に伴って変わっていくのは当たり前で、そんなのCでもC++でもずっと同じことをやってましたよね。そうそう単純に後方互換性維持ってわけにもいかないですし。Javaは仕様が管理されているから管理しているほうの責任を追及したくなるのは事実ですけど、「自称K&R準拠」Cコンパイラ乱立時代の苦労を考えたら百倍くらいましです。仕様が変わるたびに作り直すのがいやって言っても、VC++のバージョンが変わるたびにソースをちょこちょこいじって再コンパイルしているのとあんまり変わらないと思うのだけどなあ。
  • Sunの言うJavaは、マルチプラットフォームがウリのはず。それをMSはいつぞやのapplet時代にJVMのパフォーマンスばかり追いかけすぎて、ウリのはずの互換性がおざなりになってしまった。これじゃあコストパフォーマンスが良い他の言語で書いた方がよっぽどマシということも考えられる。

    いつからJavaはケンカのタネになったんだろう。問題は、MSがJavaを「言語」としてしか見ていなかったということだろうか。要はコンパイル後はMSプラットフォームで動けば他のプラットフォームなんてどうでもよかった。それは今のC#(元ネタはVisual J++と推測)に強く現れている。

  • 元記事では「Javaアプリケーションの殆どはサーバーで処理できるから必要ないかもしれない…」ような意見を紹介して完結していますが...

    これについてちょっと茶々いれようかと思ったのですが、なかなかまとまらなかった。これって、「(クライアントサイドよりも)サーバサイドでJavaが使われることが多い」って言えばいいだけの話なのに。要するに「必要無い」んじゃなくて、需要が小さいと。

  • by Anonymous Coward on 2001年08月22日 13時26分 (#15876)
    技術者だからNetscape使うとか、そういうことは決まってないと思いますよ。
    世の中には「できる技術者はIEなんて使わない」とか思ってる人いるみたいですけど。
    それに「技術者」にもいろんな種類があるし。

    それはさておき、確かにJavaはプログラミング言語としてはいいものです。C++を途中で投げ出した私でも理解できたし。
    でも、セキュリティホールが出てきて、それを修正するために仕様が変わり、最初に書いたソースも変更を余儀なくされました。その結果、最新のJavaVMでは動かない、実現できないようになってきたので嫌になってしまい、そこでJavaを捨てました。
    たぶんいろいろ勉強すれば現在のJavaVMでも動いたのかもしれないですが、仕様が変わるたびに作り直すってのが嫌だったのです。

    Sunの失態・失策でJavaは廃れていくのではないかと私は思っています。Sunがもっとちゃんとしていれば、いくらMSがWindowsXP,IEからJavaVMを除いたりC#なんて打ち出したりしたとしても全然平気だと思います。
    今回だって、SunがMSに最新のJavaVMを使うことを禁止したことから発展した問題だし、そのようなSunのJavaVMを武器にしてWindowsXPの発売を妨害する可能性を危惧したMSが外しちゃうのも、ある程度は理解できます。

    もちろん、まだまだSun&Javaにもチャンスは残っていますが、数年ものあいだ進歩が見られない上に、携帯電話のJavaでもわかるようにどんどん「それでしか動かないJavaアプレット」なんてのが増えてる今、期待はしていないです(というかできない)。せめて、503であればFでもNでもPでも動くくらいにして下さい。
  • 同感。(ACでコメントはもったいないと思う。デフォルトスコアが0だからね。)

    Javaの仕様の変化に追いつける技術者ってどのくらいいるのでしょうか。なんだかこのコメントから、当初「Write Once, Run Anywhere(一度書けば何処でも動く)」なのが、いつのまにか「Write once, fix always(一度書いたら毎回修正)」になったんではないかと勘ぐってしまいそうです。

    技術者だからNetscape使うとか、そういうことは決まってないと思いますよ。 世の中には「できる技術者はIEなんて使わない」とか思ってる人いるみたいですけど。 それに「技術者」にもいろんな種類があるし。

    普通、Webアプリを作るときはメジャーなブラウザで見れるように確認すると思います。(そうしないところもありますが。それは普通じゃないと言うことで。)

  • ちょい補足入れますが、サーバーサイドでJavaの処理をさせてしまう理由の一つに、毎回JVMを起動するとオーバーヘッドがデカくてイライラするので、サーバ上にデーモンとして常駐させておくほうが賢いし、Servletの場合はCGIと違って、毎回処理単位でプロセスを起動するのではなくて、デーモン上のスレッドをアクティブにするという方法なので、CGIに比べると幾分負荷が小さいようです。(私は試したことはありませんが。)Servletはスレッドがわかってないと作れないのはこのためでしょう。

  • JVMの起動スピードは、本当に速くしたいという要望が強いのなら、改良されるかなあ、とか思ってるんですけどね。要望が強くないということ自体がClient-Side Javaの現状を物語っているのでしょうけど。
    まあ、ブラウザの立ち上がりを速くするためにタスクトレイに常駐、という技が許されるのだから、メモリ消費とか気にしなければJVMの起動速度はこのままでもいいのかという気もちょっとする。
    サーバーで何でも処理しようというのは、ネットワークがそこそこ速くてサーバーもリッチならそうなんでしょうけどね。例えば入力項目の適切性チェック(数値範囲の確認とか、必須項目の入力洩れチェックとか)みたいな作業はいちいちPOSTせずにクライアントのアプレット内でサッサとできたほうがUI的にはいいんですよね。HTMLのFORMがもっと賢ければいいのかも知れないけど。XMLベースで高度な記述の可能なFORMが書ければ、それが動くブラウザさえあればその方がいいのかな。
  • >例えば入力項目の適切性チェック
    >(数値範囲の確認とか、必須項目の入力洩れチェックとか)
    >みたいな作業はいちいちPOSTせずに
    >クライアントのアプレット内でサッサとできたほうがUI的にはいいんですよね。
    >HTMLのFORMがもっと賢ければいいのかも知れないけど。
    >XMLベースで高度な記述の可能なFORMが書ければ、
    >それが動くブラウザさえあればその方がいいのかな。

    えーっと、ご存知の方がおられましたら教えていただきたいのですが、XULってこういう用途に使えます?
  • >>イメージとしてはMacOSXのクラシック環境で動く
    >>ハイパーカードみたいなの? → こいつも遅いですから,やっぱり別のマシンを起動するのは時間
    >>がかかるんですね。

    >上3行、文意がよく分からない感じですぅ。

    んー、わかんないけど
    Webブラウザの中で起動されて起動時間のかかるJavaVM

    OS X環境の中で起動されて起動時間のかかるClassic環境
    という意味?でもHyperCard持ち出す意味ないよね。
    Java Byte-Code=HyperTalkみたいなイメージで言ってるのかな?
  • それとも
    OS X環境の中からHyperCardを呼び出すと、まずClassic環境が起ち上がってくる
    という意味かな?
    #連続投稿失礼。
  • >ましてや、「SunがJavaVMの問題を盾にWindows XPの発売を妨害する」なんて
    >MSが言ってるだけで、他の誰もそんなこと信じてないでしょう。
    >今まで通りMSVM入れてリリースするようにしてたら何も起こらず今まで通りだったはず。

    http://www.zdnet.co.jp/news/0108/23/e_mcnealy.html
    マクネリの書いた記事が日本語訳されています。
    フォードの「黒でさえあればどんな色でも」のくだりはなかなか面白い。
  • http://www.zdnet.com/anchordesk/stories/story/0,10738,2806840,00.htmlにこのマクネリの記事を批判するDavid Courseyの記事が出てます。
    Product Activationの誤動作で出張中一切Officeが使えない、なんてひどい目にあった後でも変わらずMicrosoftの味方をするんだな、Courseyは。この忠誠心はいったいどこから来るのだろうなあ…。
  • SunのjavaVMはXPの発売日に間に合わないので、最初はプリインストールはされないようだが、IEに対応する以外、JREと何か違いが出てくるのかな?
    IEのappletタグに対応にするソフトなら、以前誰かが作ってたような気もするな・・・。
    しばらくは XPもバグだらけだろうから、JavaVMの開発が遅れてもたいしたことないかもしれない。完成してからでもプリインストールはしてほしいかも。
    --
    okome
  • Sun の開発が間に合わないというか、本来なら IE が JVM を選べるように実装されてるべきでは。Netscape の OJI みたく。

  •  …正直言って頭が痛いです^^; おそらく、現在Windows上で使われているブラウザの多くは「IE」だと思います。技術者なら「Mozilla」とか「Netscape」を利用されている方も多くいるとは思いますが(…とはいっても、最近では技術者でも「IE」使っている人多いんですよねぇ^^;)ごく一般の方で、わざわざダウンロードしてまで他のブラウザを利用している人は少ないと思います。ブラウザですらそんな状態なのですから、Javaだとなおさらに…。今後、標準搭載されなくなることで(似非で古いとはいえ、曲がりなりにもJavaでしたので…^^;)一般に普及すると言うよりは、一部の技術者向けの… 私のような物好き(…と言われることが多い^^;)技術になってしまわないことを祈ります(ちなみに…M$は技術にあまり詳しくない、お偉いさんへの洗脳は上手いようで^^; 現在、上層部の「.NET」プレッシャーと対立していたりします。この苦痛から逃れるためにも頑張って欲しいところです^^;)。どうか、普及が携帯電話だけで終わりませんよーに…(^人^)

     最後に、元記事では「Javaアプリケーションの殆どはサーバーで処理できるから必要ないかもしれない…」ような意見を紹介して完結していますが、Java…って「クライアントによる負荷の分散」も目的の一つじゃなかったでしたっけ? なんか、的を得ていないような気がします…。
  • by anything (2697) on 2001年08月22日 12時09分 (#15857)
    WinXPの販売仮差止め請求がでて認められれば間に合ったりして。
    もっとも、M$側も出荷を急ぐことで請求させない様にしているようですが。

    #急げばまた、バグのオンパレード。
    #結局、不利益を受けるのは消費者なんだよねぇ…。
  • ちゅーか、クライアントサイドでのJava、それもアプレットとしてのJavaはもう終わっているのでは。
    JavaVMが起動がもう少し早ければなんとか成るかも知れませんが。
    個人的には
    http://www.atmarkit.co.jp/fxml/rensai/frontier03/frontier03.html
    の様な方向がJavaの生きる道の様な。
    --
    -----------------
    #そんなワタシはOS/2ユーザー:-)
  • >>技術者だからNetscape使うとか、そういうことは決まってないと思いますよ。

     あ、これは、コンピュータに触れる機会が多いだけ、ネット上に流れる話題等から一般の人より使っている人が多いだろうって意味合いで書いたつもりです。私の知り合いには「Mozilla」ってなに? …って人も多くいますので^^;
     誤解を招いたようでしたら申し訳ありませんm(__)m

     あと、ブラウザに関しては別にどれを使っても良いと思います。現に3つとも使っているし^^; それに、どんなブラウザにも多かれ少なかれセキュリティーホールはありますから。一番大事なのはブラウザの設定の方だと思いますし…ね。ただ、ネット上のニュースを見ていてIEの方が過去に危険なセキュリティーホールの記事が多かったような気はします^^; リンクでハードディスクのデータを消されたり…とか。ま、ユーザが多いので目に付くことが多いのかも知れませんが。

    >>せめて、503であればFでもNでもPでも動くくらいにして下さい。

     ここら辺は、DoComoの仕様に曖昧な点が多くて、細かい動作に関しては各社任せになっていることが原因らしいです。過去の日経バイトか何かの記事で読んだ記憶があります。

     いろいろと興味深いお話、ありがとう御座いました…m(__)m
  •  …えっ、Javaの概念の一つに、「データをクライアント単位で処理することにより、サーバーへの負荷を減らそう」ってのがあると今まで思っていました^^; 最近はサーバーサイドでJavaの処理をさせてしまうんですね^^; ハードウェアの進歩のおかげなのかな? …ってことは、出来る限りサーバーで処理をさせてクライアントは最低限のことをさせる…結局、発想の回帰となってしまった感じですね。うーん。なるほど…。
  • by nsawa (497) on 2001年08月22日 18時44分 (#15956)
    僕はSwingで挫折しました。 1.1.xとawtでのJavaアプリケーション作成ははなかなか面白く、シンプルで気に入っていたのですが、1.2.xとSwingにはついていけませんでした。 特にSwingの複雑さは、これまでに見たツールキット(そんなに多くはありませんけど)の中でもトップクラスと感じましたが... Swingって、普及したのでしょうか。
  • 私も終わっているように思います。 性能面の問題もなのですが,概ねクライアントサイドのジャバでやろうとしていたことは,フラッシュで置き換えられている(若しくは置き換えられてゆく)ようにおもいます。 クライアントサイドで生き残る術があるとすれば,ウェッブブラウザそのものの代替として,の方が適当だと思うのですが。 イメージとしてはMacOSXのクラシック環境で動くハイパーカードみたいなの? → こいつも遅いですから,やっぱり別のマシンを起動するのは時間がかかるんですね。
    --
    -- LightSpeed-J
  • >実際にはM$はM$製JavaVMをダウンロードさせIE6に組み込む事ができるようにするらしいけど

    http://www.hinden5.com/senkousha/
    で公開されている「先行者」Javaゲームって、
    最近のヴァージョンは、基本的にWindows版IEでないと動かないんですよね。
    プログラミングはズブの素人なので、何故かは分からないけれど。

    というわけで、密かに「果たしてWindowsXPで「先行者」は動くのだろうか?」と心配していたのですが、MSがまた何かやらかさない限りは(っていうかやらかしそうだけど)
    MS製のJavaVMも一応用意されるということで、WinXP登場とともに「先行者」ゲームが過去の遺物になるということは避けられそうな気配ですね。

    #ただし、僕自身は当分Win98SEを使い続けることになりそうなので関係のない話だったりもする。
    --
    gy0
  • by G7 (3009) on 2001年08月22日 20時44分 (#15974)
    >概ねクライアントサイドのジャバ
    >でやろうとしていたことは,フラッシュで置き換えられている

    え?

    http://www.hotwired.co.jp/news/news/technology/story/20000509304.html
    >(Javaは)セキュリティー上の問題もある。フラッシュはほ
    >ぼ絶対間違いが起こらない。単なる画像にすぎない。扉
    >を開ける鍵がないのだ

    ということですから、汎用プログラミングは無理、ということですよねフラッシュって。

    そんなに、クライアント上での汎用(というほどのもんでもないが)プログラミングの
    ニーズは少なかった、ということなのでしょうか?なんか意外な感じがします。

    キギョーな世界では、サーバー側のJavaと呼応するためにクライアントでも動かす、
    という感じは多いのかも、という気がします。
    #というか、次の仕事、それになりそうだし(笑)

    >ウェッブブラウザそのものの代替として,の方が適当だと思うのですが。

    代替というより、Net経由でなんかかんかをやる別の何か、なような気はします。

    >イメージとしてはMacOSXのクラシック環境で動く
    >ハイパーカードみたいなの? → こいつも遅いですから,やっぱり別のマシンを起動するのは時間
    >がかかるんですね。

    上3行、文意がよく分からない感じですぅ。
    あのー。ハイパーカードとブラウザじゃえらく違うと思うんですけど(^^;。
    遅いとか時間とかいうのはVMを立ち上げる遅さの問題の話ですか?

  • だって、JDK1.1時代の古いVMがデフォルトでは動かなくなっただけでしょ?良くも悪くも、NetscapeとIEの古いVMは最近になってはJava浸透の妨げになっていた部分もあったと思う。それを期にSunがJDK1.3以降の新しいAPIを浸透させようとする意図は十分に理解できますし、安定するなら大賛成です。

    個人的には、むしろLiveConnect相当の機能がどうなるかが心配です。

  • 数年ものあいだ進歩が見られない上に、携帯電話のJavaでもわかるようにどんどん「それでしか動かないJavaアプレット」なんてのが増えてる今、期待はしていないです(というかできない)。せめて、503であればFでもNでもPでも動くくらいにして下さい。

    Docomoのやつは独自仕様ですからねえ。仕様的な漏れもありますし、ScratchPadみたいに「クラックしてください」といわんばかりの部分もあります。あれはJavaの責任というより先走りすぎのDocomoの責任の部分が多いんじゃないかと思います。

    結局、ベンダーの思惑で変わってしまうようではSunが必死でコントロールしてもうまく言ってないなあという印象は受けます。その点、サーバーサイドではうまくいっているようではありますが。

    それより、MIDPをほっぽってかってに独自仕様APIを大々的に売り出しているDocomoを訴えないのは、Sunにとってはこの間の訴訟は結局マイクロソフト憎しだったのかと思えてちょっとブルー。

    # あるいは、次はMIDPになってiアプリ自体即効で消え行く可能性もありますが。

  •  むちゃくちゃ誤解を招いてます.もうし訳ございません.
     何を言いたかったかともうしますと,「あの程度のことができれば十分で」「プロセッサやOSにもよらず」「15年(?)も昔のユーザプログラムが」「実は結構快適に動く」「で,ライブラリも別に配布できたり(で,かつ環境設定に潜り込ませることもできて,ばらけたファイルで存在しないのでユーザにぶっ壊されることもないですし)」「一つのウインドウの中だけでうごくように作るのが基本なのでユーザが混乱しない」みたいなあたりでした.
     主題は起動が早いとか遅いとか,クラシック環境が具体的にどうしたとか,開発言語がよいとか悪い,ではありません.
     あと,フラッシュの件ですが,CSS系のクライアントとして利用できるとも聞いています.「絵だけ以上」になりつつあると思っていますが,実際どうなのでしょう.識者の方ご指導の程.
    --
    -- LightSpeed-J
  • by G7 (3009) on 2001年08月23日 1時45分 (#16044)
    >むちゃくちゃ誤解を招いてます

    うーみゅ。誤解つーか、なにも理解できなかったのよね…。

    つまり、セットアップは楽な一方で処理(起動)は重いVMが介在するぞ、
    という話ですか?

    やっぱりVMは常駐させたいもんですね。
    OSそのものが巨大な常駐ソフトなわけで、アプリ1つ立ち上げるごとに
    OSをリブートするなんていう使い方(VMWareとかの感じを想像してください)は、
    誰もしたがらないでしょうね。でも現状ではそうしちゃってるんだよなあ。困ったもんで。

    Unix風にいえば鯖プロセスってとこ?
    他から依頼を投げるときには、ダミーのプログラムからプロセス間通信で
    依頼内容を通知してもらう、みたいな。
  • >それを期にSunがJDK1.3以降の新しいAPIを浸透させようとする意図

    意図してるのかどうかは知りませんが、意図しなかったとしても1.3に上がるのは嬉しいですね。
    ひょっとしてMIDI(MIDIファイルじゃないよ)が使えるようになるのかな :-D~~
    つまり、なんか途方も無く長い時間待たされたような気がする、
    まともな鍵盤アプレットが作れるようになるってことかな?だったらいいなぁ。

    昔あった鍵盤アプレットって、たしかPCM音ファイルを鍵盤押されたらPlayするという
    おまえはメロトロンかよ?的な代物だったもんなあ。がっくりきた記憶があるぞ。

    #オフトピ。Java Sound APIをマヂに使ったソフトってどれくらい有るもんなんでしょう?>識者
    #あの良くも悪くもゴージャスなAPIでMIDIシーケンサとか作ったらどうなるんだろう?
    #ガベコレが祟って録音詰まったりしないのかな?
  • APPLETタグは推奨されないので、OBJECTタグ使えばいいんですよね・・・。
    これだとできるのでは?(^^;
    --
    okome
  • そういえば JavaPlug-in って object タグ使ってたような。わざわざ XP 用のを開発するってことは、

    • そもそも J2SDK が XP 上で動かない
    • IE の PlugIn 仕様が変わった(QuickTime の例もあるし)
    • Sun が、applet タグでも J2SDK が動くようにしたがってる

    のどれか(又は複数)ってとこでしょうか。上2つだと、MS が妨害してる可能性もありますな。

  • by Anonymous Coward on 2001年08月22日 20時06分 (#15972)
    ProcessよりThreadのほうが軽量だし、「状態」を毎度毎度Diskに落とさないとならない
    というProcessの制約は(重さ的にも設計的にも)痛いし、
    Javaなら同一JVM上に複数のObjectやClassをだらしなく(^^;配置しても、
    Processと違って互いに悪干渉をする心配は無いし。

    というわけで、サーバーに限らずクライアントでも、JVMを上げっぱなしにしといて、
    その上でJavaShellとでもいうべきものを上げておいて、そいつ経由で
    Objectの生成やClassのLoadを命令するようにすれば、結構軽くなるよね。

    やっぱりJavaOSがいいなぁ…

    >Servletはスレッドがわかってないと作れないのはこのため

    「スレッドがわかる」っていうけど、冷静になって考えれば、
    理屈はProcessより簡単だと思うんだよな。
    Object間の参照をうまく使えば、Object間通信(???)なんて
    (Processのそれと違って)楽勝なんだし。
  • by Anonymous Coward on 2001年08月23日 23時28分 (#16342)
    「一度書けばどこでも動く」というJava技術の魅力は,どこか1つの企業に阻止できるほど柔なものではない。

    ってところが本気なのか、実は自分ところの Java に疎いのか、どっちなんだろうとか思ったり。
    「どこか一つの企業」に、「Sun」ってのを当てはめても意味が通ってて、「『一度書けばどこでも動く』という Java技術の魅力は、いまだ実現されていないが Sun 一社によって実現を阻止できるほど柔ではない」とも考えることができるのは皮肉なこと。

    とっとと Java をSun一社の支配から脱却させて、本当に一度書けばどこでも動くのを実現させてよ、と言いたい。
typodupeerror

クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人

読み込み中...