HMDT - Back Number / June, 2000

June 19, 2000

[Mozilla Study] - Netscape Portable Runtime API (NSPR)

さて、予告通り Mozilla の study です。まずは NSPR から見てみますか。

NSPR は、低レベルな OS 非依存サービスを提供する API です。つまり、上位のモジュールは OS のサービスを直接呼ばずに NSPR を呼ぶことによって移植性を保つわけね。だからここは Mozilla のモジュールのコアに近いところです。

まず、mozilla/nsprpub/pr/include/nspr.h ファイルを見てみましょう。このファイルを include すれば、NSPR のすべての Public API が使えるはずです。そこで include されるファイルは以下の通り。

Core Types and Information:

System:

Memory Allocation:

Thread Handling and Synchronization:

File I/O:

Network:

Data Structure:

Error Handleing and Debugging:

Utility:

だいたい一般的かな。Queue がないのがちょっと不便かも知れない。あと、String クラスとか、一般的なリストもないよね。

ここのヘッダで定義されている関数は、全て C 関数になっています。クラス化はされていません。あと、マクロがたくさんあります。つまり、まったくオブジェクト指向的にはなっていないということですね。どうせ、ここ以外はクラスを使っているんだから、NSPR もきっちりクラス化をすればよかったのに、と思うけどね。

June 18, 2000

Mozilla Study

Mozilla の Milestone16 が出たね。mkino はまだ試していないけどね。

Mozilla は着実に毎回 Milestone を出してくるよね。これは、確かに少しずつ Mozilla が完成に向かっていることだと、高く評価していいと思うんだ。

さて、ひるがえって Mac 版 Mozilla だけど、Web を見ている限り、あまりいい評価は見られないね。少なくとも、Mozilla を熱狂的に支持していて、毎日の Web Browsing は Mozilla でしかしませんよ！、という人は見たことない（笑）。Mac では、IE よりも Netscape の方が人気があったように思ったから、ちょっと妙な現象だよね。

なぜか？まぁ Mozilla がまだベータ版（というかほとんだアルファ版）だから、不安定だから使わない、というのもあるだろう。それもあるだろう。でも、一番大きいのは、Mozilla の Policy にあるんじゃないだろうか。Mozilla は完全なクロスプラットフォームブラウザを目指すために、独自の UI を取り入れている。確かに、開発者にとっては OS に依存しない UI セットを使うことによって、非常に抽象度の高いソースを書くことができるから、いいことだろう。しかし、ユーザから見ると不便を感じるかも知れない。ぼくが欲しいのは、単に Macintosh の UI に馴染んだ、軽量、安定したブラウザなんだ。ただそれだけなんだ。ユーザは、デベロッパの理想なんかどうでもいいんだ。いや、mkino もデベロッパの端くれだから、気持ちはとってもよく分かるんだけどね。

もう一つ。Mac 界は Mac OS X のリリースをいまかいまかと待ち受けているよね。これから一年間は X への移行が一気に起きるときだと思うんだ。そのときに、Classic 環境で動く Mozilla は、はっきりいって魅力が薄いんだ。Mozilla を Carbon に対応させるプロジェクトがあることはしっているよ（Fizzila だっけ？）。でも、その活動は寡聞にして聞こえてこない。ぼくが欲しいのは、少なくとも Carbon 対応、それよりも Cocoa に対応したブラウザなんだ。

さて、ここで愚痴をいっていてもしかたないよね。不毛な議論に時間を費やすよりは、行動しよう。なにをいうにも Mozilla は Open Source。これはすべての可能性が開けていることを意味する。上に書いたようなブラウザが欲しいんだったら、じゃあ作ってみようじゃないか！なんだ、簡単な話だよ！

とはいうものの、mkino はそんなにスキルの高いデベロッパじゃないから、できるかどうか分からない。でも study ぐらいはやってみても悪くないだろ。今の Mozilla を勉強して、Cocoa にするのはどのくらいの難易度なのか？どのくらいの作業量なのか？ほんとに恩恵はあるのか？Mozilla のコードベースは今後何年ぐらい耐えられるのか？まぁ、見てみようじゃないの！

てなわけで、今後 Mozilla の Study をやってみます。折に触れ、この場でレポートしますね。

June 11, 2000

Java One と Steve（後編）

昨日は Java に関する明るい話をしたよね。今日はちょっと疑問を投げかける話だ。

前にも書いたけど、Mac OS X では、Java を使ってアプリケーションを作れるっていう話だよね。つまり、Java を一つの開発言語として使うんだ。Java プログラムに興味のない人は、「それがどうしたの？」って思うかも知れないけど、これは一つの議論の種なんだ。

Java が今までずーっと持っている、強いウリは、「Write once, run anywhere」だ。一回書けば、どこでも動くっていうことね。これを実現するために、Java プログラマは JDK で提供されているパッケージ（ライブラリのことね）以外の機能を使うことに、強い抵抗があるはずなんだ。

さて、Mac OS X での Java サポートだけど、AppKit を Java でプログラムできるのを売りにしているよね。これに既存の Java プログラムがどう反応するかが、見物だ。書いても誰も使ってくれない Java アプリよりは、Mac OS X と Aqua に特化した Mac OS X アプリを書く方がいいかもしれない、と考える人も出てくるかもね。

また、これは Apple による独自の Java 環境と見ることもできる。結果として、Apple による Java 開発者囲い込みが起こるかも知れない。同じ日のニュースに、MS が過去にそれをやろうとして、Apple と相談した、っていう記事があったよね。片方はこれで裁判に訴えられ、片方は Java One で絶賛される。この温度差はどこから出てきちゃったんだろうね？

June 10, 2000

Java One と Steve（前編）

先日は Java One があったよね。いきなり Steve が登場したので、びっくりした人も多かったと思う。mkino はびっくりした。

Steve の話は、Mac OS X に Java2 を搭載する、っていうことで、WWDC の話とそんなには大差なかったよね。ただ、「主流の OS で Java2 を標準搭載するのは Mac OS X だけだ」っていう言い方をしていたよね。「主流の OS」っていう言い方をしているけど、要は Win2000 は Java2 を搭載していないよ、っていうことがいいたかったんだと思う。Linux を忘れるな！って？Linux が主流かどうかはおくとしても、Java2 を標準でどのディストリビューションもサポートしてる、っていうことはないよね。

これって、デベロッパにとっては結構うれしいことだと思う。いままで Java はサーバ側での利用法ばかりクローズアップされていて、クライアント側での利用はあまり語られていなかったよね。まぁ、パフォーマンスがでないとか、キラーアプリがないとかいろいろ理由があったんだけど、ユーザの環境が整っていない、というのが結構大きかったと思う。つまり、ユーザがどのバージョンの Java を使えるか特定できない。この場合、デベロッパがとる道は 2 つあって、予想できる最低のバージョンに合わせるか、JDK（または JRE）をダウンロードしてもらう。後者はユーザにとって結構要求が大きいよね。なにせ JRE のファイルは大きいから＾＾）。そこで前者を取るわけだけど、どっちにしても Sun の Java は今まで Windows でも Mac でも標準でついてこなかったんだ。だから開発環境が JDK だとしても（まともなデベロッパなら JDK を使うと思う）、テストは MS の Java や MRJ で行わなくてはいけない。これは結構ストレスがたまることだと思うんだ。

Mac OS X では、どうやらかなり熟成された Java2 がのるらしい。いままで MRJ で置いていかれていた分を一気に取り戻そうというところだ。しかも、すべてのクライアントにのることが保証される。これで、Java2 のインストールベースはずっと増えるだろう。さらに、Mac OS X ユーザを対象にした Java クライアントアプリケーションがずっと作りやすくなるんだ。これで Java デベロッパが Mac OS X への参入の敷き居をぐっと下げたことになると思うんだ。

June 8, 2000

Fahrenheit 続報

昨日 Fahrenheit のことをちらっと書いたんだけど、ちょっと調べてみたよ。

SGI のサイトに Fahrenheit の情報を提供するページがあるんだ。そこを見ると、なんと SGI はすでに Fahrenheit プロジェクトから撤退していたよ。知らなかった。

このページによると、SGI は今後 Linux にも注力していくので、Linux 版が提供されない Fahrenheit は同社の戦略に合わない、って書いてあるね。もし Fahrenheit が出るとしたら Windows only だろうと。でも、すでに DirectX をもっている MS がさらに High Level API を提供するとは思えないな。

ま、そういうわけで、High Level 3D API の標準化はまた一つなくなりました。ほんと QuickDraw3D API がつけいる隙はあったんじゃないの？＞Apple

June 7, 2000

Mac OS X と Open GL

やぁ、今度は Open GL のことについて考えてみよう。

OS X のグラフィック環境は、Core Graphics の上に 3 つの API がのっかっている構造になっているよね。PDF を担当するのが Quartz、時間軸上のグラフィックを担当するのが QuickTime、そして 3D Graphic を担当するのが Open GL だ。

よくいわれていたことだけど、Apple は昔、常に純正技術にこだわっていたんだ。Adobe の PostScript を画面描画に採用せずに TrueType を開発したり（ま、Adobe のライセンス形態も問題だったんだけど）、Open GL を採用せずに QuickDraw3D を開発したりね。OS X になって、積極的に業界標準を取り入れようとしているのが分かるよね。QuickTime は Apple 純正の技術だけど、デファクトスタンダードといっていいだろう。

ところで、開発が中止されてしまった QuickDraw3D についてちょっと話してみよう。ユーザにとってはあまり目に見えるメリットがなかった技術だと思うんだ。でも、QD3D にはいろいろ面白い点があった。例えば、共通ファイルフォーマット 3DMF (3D Meta File) を定義していたところ。いまの OpenGL には決定的なデータフォーマットがないんだ。当然、あるデータフォーマットに対する API も OpenGL では用意されていない。QD3D には 3DMF があったから、データのやりとりが凄く容易だったんだ。しかも、リソースに含めることもできた！他にも、3DMF を簡易ブラウズする API も用意されていたんだ。これを使えば、いろんなアプリケーションで簡単に 3D データを扱えたんだ。スクラップブックにその名残りが見れるよね。

じゃあ、OpenGL になって、こういう利点はどうなるんだろう。 OpenGL っていうのは、結構 Low Level の API なんだ（誤解のないように言っておくけど、Low Level というのは程度が低いということではなくて、ハードやドライバに近いレベルの API だ、っていうことね）。もっと楽にアプリケーションが作れる High Level API の定番はないんだ。Open Inventor があるけれど、あれはフリーじゃないしね。そのために、SGI と MS が Fahrenheit っていう API をつくる、っていう話があったけど、最近話題を聞かないよね。MS としては Direct3D で充分、と思っているのかな？

OS X で OpenGL が採用されると、利点としては他からの移植がしやすいことや、グラフィックカードの対応が容易くなる、ということがあげられると思う。でも、QD3D の持っていた利点がなくなっちゃうのは寂しいよね。新規のデベロッパの参入や、非 3D グラフィックアプリから 3D データを使うのに、敷き居がすごく高くなっちゃう。Apple はここにつけいる隙があると思うな。OpenGL をベースとして、QD3D ライクな High Level API を提案できないだろうか？かつ、これをオープンにして、他の環境への移植を容易にしておく。そうすれば、さまざまなアプリの 3D 利用が進むと思うな。

June 5, 2000

Mac OS X Server の Java を使って Yellow API を使う

じゃぁ、X Server の Java を見てみよう。Java を使って X Server の Yellow API（いまとなっては Cocoa だけど）を叩けるのか？

とりあえず、ドキュメントを見てみる。そうすると、確かにあるね。まず、AppKit から見てみよう。AppKit は、com.apple.yellow.application っていうパッケージ名になっているね（これって cocoa に変わるのだろうか？）。そして、その下に NS*** クラスがあるわけだ。

ちょっといくつかのクラスをのぞいてみると、Description のところには、「詳しいことは Object-C の方を見ろ」って書いてあるだけだんなだよね。これはやっぱり単なる Wrappter として機能しているだけなんだろうね。

Java を Objective-C の Wrapper として使うことは問題ないんだろうか？見ると、まず Obj-C のクラスメソッドは Java の static 関数として定義されていることが分かる。他に気になるのは、id は java.lang.Object として、SEL には com.apple.alpha.core.Selector っていうクラス（インタフェース？）が用意されていることが分かる。これはもうちょっと調べてみよう。

June 4, 2000

Mac OS X と Java のこと

Mac OS X では、Java が主要な開発言語としてフィーチャーされている、っていうことは、もうだいぶ前からみんな知っていると思うんだ。いままでの Mac OS 8、9 では、MRJ (Macintosh Runtime for Java) が JavaVM 環境を提供していたんだけど、これがあんまり使いやすいものではなかったよね ^^)。Developer にとっては。特に初期の頃は、すごく遅いし、AWT の表示は乱れるしとてもじゃないけど大変だった。Sun も JDK for Mac のサポートはすぐにやめちゃったし、JIT (Just-In-Time compiler) を使って、どんどん早くなっていく Windows の Java を指を食わえて見ているしかなかったんだ。というか、ほんとに Java で開発する人は、さっさと Mac 環境に見切りをつけて、Win 環境に移ったと思う ^^)。OS 非依存を華々しく売りにしていたけど、実態はこんなものだったよね。

さて、X が出てきてようやく Mac での Java 開発もトレンドに追いつけそうな雰囲気になってきた。どうやら Java 2 がようやく実装されるらしい。これは素直に喜んでおこうよ。さらに、Objective-C とともに、主要開発言語の 1 つとなるらしい。これもだいぶ前から Jobs が言っていたよね。Java を使って Mac OS X 用アプリが書けるって。でも、ちょっと待って。これって Java の考え方とはちょっと違うんじゃないの？

Java っていうのは、前述の通り、OS 非依存が売りの一つだ。これをどうやって実現するかっていうと、Java からは、今動いている環境の OS の関数はあまり呼ばないようにしよう、っていうことにしてるんだ。いや、もちろん呼ことはできるよ。native メソッドを呼ぶための機構はちゃんと用意してある。でもそれらはなるべく、Core JDK だけが呼ぶようにして、アプリケーションレベルでは使わないようにしようと。これが一番簡単な OS 互換性の取り方だ。

余談だけど、初期の Java で一番非難が集中したのは AWT だった。Abstract Window Toolkit のことで、GUI を提供するパッケージ（ライブラリ）のことね。これを使えば、OS に依存しない Window GUI が作れるっていうことだったんだけど、実際は OS ごとに実装がむちゃくちゃ違っちゃったんだ。結構致命的だったのが OS ごとに GUI 部品の大きさが異なること。だからある OS ではちゃんと見えるのに、他の OS だとボタンがどっかいっちゃうっていうことがよく起こった。これを防ぐには、相対的な LayuoutManager を使えばいい、っていうことだったんだけど、これ結構めんどくさいし、RAD ツールで WYSIWYG にレイアウトすrのには相性が悪いと思う。それで Sun が開発したのが Swing だったんだ。これは Java で一から書き直した GUI 部品群だ。これだとかなり互換が取れるんだけど（フォントの問題は残る）、とにかくこれ重かったんだ。メニューなんかは使用に耐えない程遅い。Sun は Swing のことを、OS の API を使用せず、Core Java の上に乗っているから、'Light Weight GUI' って呼んでたんだけど、どこが Light Weight なんだ、って突っ込んだ記憶のある人は多いはず '')／。個人的には Mac OS X の上で、Swing がどのくらいのパオーマンスを得るかは興味があるね。でも、あの Aqua の中に、いまとなっては野暮ったい感のする Swing Metal が出るのはちょっと嫌かも。

話を戻すと、そういう訳で、Java で開発するときはできるだけ Pure Java でいこう、っていう空気があるんだ。Microsoft が Swing（の前身 JFC）に対抗して AFC (Application Foundation Class）っていうライブラリを出したとき、これは強烈な Windows 依存だったから、いっせいにそっぽを向かれた、っていうこともあった。じゃあ、Mac OS X の Java 環境はどうかっていうと、Java 2 環境は当然あるけど（つまり Java native）、Apple は YellowBox（今は Cocoa だよね）を Java から呼べる、っていうことを売りにしているようなんだ。つまり、Mac OS X でしか動かない Java プログラムを宣伝しているわけ。この問題って、前に Jobs が Java 戦略を発表したときも少し話題になったけど、なにせものが出ていないし、Apple のシェアは落ちているときだからみんなあんまり気にしなかったと思う。だけど、もうすぐパブリックベータがリリースされるわけだし、もうちょっと議論してもいいんじゃないかな。