SunがWinXP/IE6用のJavaVMを開発中 33
ストーリー by wakatono
Sun製とMS製、あなたが使うのはどちら? 部門より
Sun製とMS製、あなたが使うのはどちら? 部門より
C-D-W 曰く,"BiztechによるとSunがWinXP及びIE6用の
JavaVMを開発中との事。
これはM$がWinXPとIE6にはJavaVMを搭載しないとの発表を受けてSun側が対応するVMを開発中であると明らかにしたと報じています。
実際にはM$はM$製JavaVMをダウンロードさせIE6に組み込む事ができるようにするらしいけど私はSun製のJavaVMを入れるだろうな~
Sun製のJavaVMの方が最新バージョンだしぃ"
Re:間に合わないらしいけど・・・ (スコア:3, 参考になる)
"Quidquid latine dictum sit, altum videtur."
Re:Javaの今後を考えると… (スコア:3, 参考になる)
>そのような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++のバージョンが変わるたびにソースをちょこちょこいじって再コンパイルしているのとあんまり変わらないと思うのだけどなあ。
JavaがSunとMSを引き離しているのか (スコア:2)
Sunの言うJavaは、マルチプラットフォームがウリのはず。それをMSはいつぞやのapplet時代にJVMのパフォーマンスばかり追いかけすぎて、ウリのはずの互換性がおざなりになってしまった。これじゃあコストパフォーマンスが良い他の言語で書いた方がよっぽどマシということも考えられる。
いつからJavaはケンカのタネになったんだろう。問題は、MSがJavaを「言語」としてしか見ていなかったということだろうか。要はコンパイル後はMSプラットフォームで動けば他のプラットフォームなんてどうでもよかった。それは今のC#(元ネタはVisual J++と推測)に強く現れている。
Re:Javaの今後を考えると… (スコア:2)
これについてちょっと茶々いれようかと思ったのですが、なかなかまとまらなかった。これって、「(クライアントサイドよりも)サーバサイドでJavaが使われることが多い」って言えばいいだけの話なのに。要するに「必要無い」んじゃなくて、需要が小さいと。Re:Javaの今後を考えると… (スコア:2, すばらしい洞察)
世の中には「できる技術者は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でも動くくらいにして下さい。
Re:Javaの今後を考えると… (スコア:2)
同感。(ACでコメントはもったいないと思う。デフォルトスコアが0だからね。)
Javaの仕様の変化に追いつける技術者ってどのくらいいるのでしょうか。なんだかこのコメントから、当初「Write Once, Run Anywhere(一度書けば何処でも動く)」なのが、いつのまにか「Write once, fix always(一度書いたら毎回修正)」になったんではないかと勘ぐってしまいそうです。
普通、Webアプリを作るときはメジャーなブラウザで見れるように確認すると思います。(そうしないところもありますが。それは普通じゃないと言うことで。)Re:Javaの今後を考えると… (スコア:2)
ちょい補足入れますが、サーバーサイドでJavaの処理をさせてしまう理由の一つに、毎回JVMを起動するとオーバーヘッドがデカくてイライラするので、サーバ上にデーモンとして常駐させておくほうが賢いし、Servletの場合はCGIと違って、毎回処理単位でプロセスを起動するのではなくて、デーモン上のスレッドをアクティブにするという方法なので、CGIに比べると幾分負荷が小さいようです。(私は試したことはありませんが。)Servletはスレッドがわかってないと作れないのはこのためでしょう。
Re:Javaの今後を考えると… (スコア:2)
まあ、ブラウザの立ち上がりを速くするためにタスクトレイに常駐、という技が許されるのだから、メモリ消費とか気にしなければJVMの起動速度はこのままでもいいのかという気もちょっとする。
サーバーで何でも処理しようというのは、ネットワークがそこそこ速くてサーバーもリッチならそうなんでしょうけどね。例えば入力項目の適切性チェック(数値範囲の確認とか、必須項目の入力洩れチェックとか)みたいな作業はいちいちPOSTせずにクライアントのアプレット内でサッサとできたほうがUI的にはいいんですよね。HTMLのFORMがもっと賢ければいいのかも知れないけど。XMLベースで高度な記述の可能なFORMが書ければ、それが動くブラウザさえあればその方がいいのかな。
Re:Javaの今後を考えると… (スコア:2)
>(数値範囲の確認とか、必須項目の入力洩れチェックとか)
>みたいな作業はいちいちPOSTせずに
>クライアントのアプレット内でサッサとできたほうがUI的にはいいんですよね。
>HTMLのFORMがもっと賢ければいいのかも知れないけど。
>XMLベースで高度な記述の可能なFORMが書ければ、
>それが動くブラウザさえあればその方がいいのかな。
えーっと、ご存知の方がおられましたら教えていただきたいのですが、XULってこういう用途に使えます?
Re:Javaの今後を考えると… (スコア:2)
>>ハイパーカードみたいなの? → こいつも遅いですから,やっぱり別のマシンを起動するのは時間
>>がかかるんですね。
>
>上3行、文意がよく分からない感じですぅ。
んー、わかんないけど
と
という意味?でもHyperCard持ち出す意味ないよね。
Java Byte-Code=HyperTalkみたいなイメージで言ってるのかな?
Re:Javaの今後を考えると… (スコア:2)
OS X環境の中からHyperCardを呼び出すと、まずClassic環境が起ち上がってくる
という意味かな?
#連続投稿失礼。
Re:Javaの今後を考えると… (スコア:2)
>MSが言ってるだけで、他の誰もそんなこと信じてないでしょう。
>今まで通りMSVM入れてリリースするようにしてたら何も起こらず今まで通りだったはず。
http://www.zdnet.co.jp/news/0108/23/e_mcnealy.htmlに
マクネリの書いた記事が日本語訳されています。
フォードの「黒でさえあればどんな色でも」のくだりはなかなか面白い。
Re:Javaの今後を考えると… (スコア:2)
Product Activationの誤動作で出張中一切Officeが使えない、なんてひどい目にあった後でも変わらずMicrosoftの味方をするんだな、Courseyは。この忠誠心はいったいどこから来るのだろうなあ…。
間に合わないらしいけど・・・ (スコア:1)
IEのappletタグに対応にするソフトなら、以前誰かが作ってたような気もするな・・・。
しばらくは XPもバグだらけだろうから、JavaVMの開発が遅れてもたいしたことないかもしれない。完成してからでもプリインストールはしてほしいかも。
okome
Re:間に合わないらしいけど・・・ (スコア:1)
Sun の開発が間に合わないというか、本来なら IE が JVM を選べるように実装されてるべきでは。Netscape の OJI みたく。
Javaの今後を考えると… (スコア:1)
最後に、元記事では「Javaアプリケーションの殆どはサーバーで処理できるから必要ないかもしれない…」ような意見を紹介して完結していますが、Java…って「クライアントによる負荷の分散」も目的の一つじゃなかったでしたっけ? なんか、的を得ていないような気がします…。
がんばれ司法省 (スコア:1)
もっとも、M$側も出荷を急ぐことで請求させない様にしているようですが。
#急げばまた、バグのオンパレード。
#結局、不利益を受けるのは消費者なんだよねぇ…。
Re:Javaの今後を考えると… (スコア:1)
JavaVMが起動がもう少し早ければなんとか成るかも知れませんが。
個人的には
http://www.atmarkit.co.jp/fxml/rensai/frontier03/frontier03.htmlの様な方向がJavaの生きる道の様な。
-----------------
#そんなワタシはOS/2ユーザー:-)
Re:Javaの今後を考えると… (スコア:1)
あ、これは、コンピュータに触れる機会が多いだけ、ネット上に流れる話題等から一般の人より使っている人が多いだろうって意味合いで書いたつもりです。私の知り合いには「Mozilla」ってなに? …って人も多くいますので^^;
誤解を招いたようでしたら申し訳ありませんm(__)m
あと、ブラウザに関しては別にどれを使っても良いと思います。現に3つとも使っているし^^; それに、どんなブラウザにも多かれ少なかれセキュリティーホールはありますから。一番大事なのはブラウザの設定の方だと思いますし…ね。ただ、ネット上のニュースを見ていてIEの方が過去に危険なセキュリティーホールの記事が多かったような気はします^^; リンクでハードディスクのデータを消されたり…とか。ま、ユーザが多いので目に付くことが多いのかも知れませんが。
>>せめて、503であればFでもNでもPでも動くくらいにして下さい。
ここら辺は、DoComoの仕様に曖昧な点が多くて、細かい動作に関しては各社任せになっていることが原因らしいです。過去の日経バイトか何かの記事で読んだ記憶があります。
いろいろと興味深いお話、ありがとう御座いました…m(__)m
Re:Javaの今後を考えると… (スコア:1)
Re:Javaの今後を考えると… (スコア:1)
Re:Javaの今後を考えると… (スコア:1)
-- LightSpeed-J
WinXPで「先行者」ゲームは動くか???(ややオフトピッ (スコア:1)
http://www.hinden5.com/senkousha/
で公開されている「先行者」Javaゲームって、
最近のヴァージョンは、基本的にWindows版IEでないと動かないんですよね。
プログラミングはズブの素人なので、何故かは分からないけれど。
というわけで、密かに「果たしてWindowsXPで「先行者」は動くのだろうか?」と心配していたのですが、MSがまた何かやらかさない限りは(っていうかやらかしそうだけど)
MS製のJavaVMも一応用意されるということで、WinXP登場とともに「先行者」ゲームが過去の遺物になるということは避けられそうな気配ですね。
#ただし、僕自身は当分Win98SEを使い続けることになりそうなので関係のない話だったりもする。
gy0
Re:Javaの今後を考えると… (スコア:1)
>でやろうとしていたことは,フラッシュで置き換えられている
え?
http://www.hotwired.co.jp/news/news/technology/story/20000509304.html
>(Javaは)セキュリティー上の問題もある。フラッシュはほ
>ぼ絶対間違いが起こらない。単なる画像にすぎない。扉
>を開ける鍵がないのだ
ということですから、汎用プログラミングは無理、ということですよねフラッシュって。
そんなに、クライアント上での汎用(というほどのもんでもないが)プログラミングの
ニーズは少なかった、ということなのでしょうか?なんか意外な感じがします。
キギョーな世界では、サーバー側のJavaと呼応するためにクライアントでも動かす、
という感じは多いのかも、という気がします。
#というか、次の仕事、それになりそうだし(笑)
>ウェッブブラウザそのものの代替として,の方が適当だと思うのですが。
代替というより、Net経由でなんかかんかをやる別の何か、なような気はします。
>イメージとしてはMacOSXのクラシック環境で動く
>ハイパーカードみたいなの? → こいつも遅いですから,やっぱり別のマシンを起動するのは時間
>がかかるんですね。
上3行、文意がよく分からない感じですぅ。
あのー。ハイパーカードとブラウザじゃえらく違うと思うんですけど(^^;。
遅いとか時間とかいうのはVMを立ち上げる遅さの問題の話ですか?
そんなに話題になることかな (スコア:1)
だって、JDK1.1時代の古いVMがデフォルトでは動かなくなっただけでしょ?良くも悪くも、NetscapeとIEの古いVMは最近になってはJava浸透の妨げになっていた部分もあったと思う。それを期にSunがJDK1.3以降の新しいAPIを浸透させようとする意図は十分に理解できますし、安定するなら大賛成です。
個人的には、むしろLiveConnect相当の機能がどうなるかが心配です。
Re:Javaの今後を考えると… (スコア:1)
Docomoのやつは独自仕様ですからねえ。仕様的な漏れもありますし、ScratchPadみたいに「クラックしてください」といわんばかりの部分もあります。あれはJavaの責任というより先走りすぎのDocomoの責任の部分が多いんじゃないかと思います。
結局、ベンダーの思惑で変わってしまうようではSunが必死でコントロールしてもうまく言ってないなあという印象は受けます。その点、サーバーサイドではうまくいっているようではありますが。
それより、MIDPをほっぽってかってに独自仕様APIを大々的に売り出しているDocomoを訴えないのは、Sunにとってはこの間の訴訟は結局マイクロソフト憎しだったのかと思えてちょっとブルー。
# あるいは、次はMIDPになってiアプリ自体即効で消え行く可能性もありますが。
Re:Javaの今後を考えると… (スコア:1)
何を言いたかったかともうしますと,「あの程度のことができれば十分で」「プロセッサやOSにもよらず」「15年(?)も昔のユーザプログラムが」「実は結構快適に動く」「で,ライブラリも別に配布できたり(で,かつ環境設定に潜り込ませることもできて,ばらけたファイルで存在しないのでユーザにぶっ壊されることもないですし)」「一つのウインドウの中だけでうごくように作るのが基本なのでユーザが混乱しない」みたいなあたりでした.
主題は起動が早いとか遅いとか,クラシック環境が具体的にどうしたとか,開発言語がよいとか悪い,ではありません.
あと,フラッシュの件ですが,CSS系のクライアントとして利用できるとも聞いています.「絵だけ以上」になりつつあると思っていますが,実際どうなのでしょう.識者の方ご指導の程.
-- LightSpeed-J
Re:Javaの今後を考えると… (スコア:1)
うーみゅ。誤解つーか、なにも理解できなかったのよね…。
つまり、セットアップは楽な一方で処理(起動)は重いVMが介在するぞ、
という話ですか?
やっぱりVMは常駐させたいもんですね。
OSそのものが巨大な常駐ソフトなわけで、アプリ1つ立ち上げるごとに
OSをリブートするなんていう使い方(VMWareとかの感じを想像してください)は、
誰もしたがらないでしょうね。でも現状ではそうしちゃってるんだよなあ。困ったもんで。
Unix風にいえば鯖プロセスってとこ?
他から依頼を投げるときには、ダミーのプログラムからプロセス間通信で
依頼内容を通知してもらう、みたいな。
Re:そんなに話題になることかな (スコア:1)
意図してるのかどうかは知りませんが、意図しなかったとしても1.3に上がるのは嬉しいですね。
ひょっとしてMIDI(MIDIファイルじゃないよ)が使えるようになるのかな :-D~~
つまり、なんか途方も無く長い時間待たされたような気がする、
まともな鍵盤アプレットが作れるようになるってことかな?だったらいいなぁ。
昔あった鍵盤アプレットって、たしかPCM音ファイルを鍵盤押されたらPlayするという
おまえはメロトロンかよ?的な代物だったもんなあ。がっくりきた記憶があるぞ。
#オフトピ。Java Sound APIをマヂに使ったソフトってどれくらい有るもんなんでしょう?>識者
#あの良くも悪くもゴージャスなAPIでMIDIシーケンサとか作ったらどうなるんだろう?
#ガベコレが祟って録音詰まったりしないのかな?
Re:間に合わないらしいけど・・・ (スコア:1)
これだとできるのでは?(^^;
okome
Re:間に合わないらしいけど・・・ (スコア:1)
そういえば JavaPlug-in って object タグ使ってたような。わざわざ XP 用のを開発するってことは、
のどれか(又は複数)ってとこでしょうか。上2つだと、MS が妨害してる可能性もありますな。
Re:Javaの今後を考えると… (スコア:0)
というProcessの制約は(重さ的にも設計的にも)痛いし、
Javaなら同一JVM上に複数のObjectやClassをだらしなく(^^;配置しても、
Processと違って互いに悪干渉をする心配は無いし。
というわけで、サーバーに限らずクライアントでも、JVMを上げっぱなしにしといて、
その上でJavaShellとでもいうべきものを上げておいて、そいつ経由で
Objectの生成やClassのLoadを命令するようにすれば、結構軽くなるよね。
やっぱりJavaOSがいいなぁ…
>Servletはスレッドがわかってないと作れないのはこのため
「スレッドがわかる」っていうけど、冷静になって考えれば、
理屈はProcessより簡単だと思うんだよな。
Object間の参照をうまく使えば、Object間通信(???)なんて
(Processのそれと違って)楽勝なんだし。
Re:Javaの今後を考えると… (スコア:0)
ってところが本気なのか、実は自分ところの Java に疎いのか、どっちなんだろうとか思ったり。
「どこか一つの企業」に、「Sun」ってのを当てはめても意味が通ってて、「『一度書けばどこでも動く』という Java技術の魅力は、いまだ実現されていないが Sun 一社によって実現を阻止できるほど柔ではない」とも考えることができるのは皮肉なこと。
とっとと Java をSun一社の支配から脱却させて、本当に一度書けばどこでも動くのを実現させてよ、と言いたい。