MOSA Multi-OS Software Artists

MOSAはソフトウェア開発者を支援します

  • iPhone/iPod touch アプリ紹介
  • MOSA掲示板
  • 活動履歴
  • About MOSA(English)

MOSA Developer News[MOSADeN=モサ伝]第100号

2004-02-10

目次

  • Cocoaでいこう! Macらしく  第38回  Yoshiki(DreamField)
  • 小池邦人の「Carbon API 徒然草」
  • 「Behind the WebObjects」  第13回  田畑 英和
  • ニュース・解説
  • MOSAからのお知らせ

MOSA Developer News 100号記念プレゼントを実施!

お陰さまでMOSA Developer News(モサ伝)は、今号で100号を配信する事ができました。
これまでのご愛読のお礼として、MOSA会員の皆様へ100号記念プレゼントを実施いたします。

【MOSA会員限定100号記念プレゼント!】
・WWDC 2003 Sessions DVD-ROMセット(アップルコンピュータ(株)ご提供)
 2003年のWWDCの全セッションを収録したDVDのセットをMOSA会員限定で2名様にプレゼント致します。

★★★応募は締め切りました★★★

・その他のプレゼント
以下のAppleCollection製品及びAppleTシャツをMOSA会員20名様へプレゼント致します。
このプレゼントは応募形式を取らず、MOSA会員を対象に事務局で抽選を行い、102号で当選者を発表致します。発表をどうぞお楽しみに!
Apple Panther Tシャツ      6名様
Coffee Cup & Saucer       2名様
Lexon CD Holder         2名様
Disk Case(Blue)         2名様
Apple Yo-yo           1名様
Eraser pack           1名様
See-Thru Pen           6名様
(Red/Green/Orangeいずれかの色)

Cocoaでいこう! Macらしく  第38回 Yoshiki(DreamField)

 ついにモサ伝も第100号。今日は最後に、Macらしさについて、自分なりの考えも述べようと思います。

座標の原点を左上にしよう

 今まで作ってきたTinyViewですが、ウィンドウを操作してみて不自然に感じたことは無いでしょうか。TinyViewを起動して適当な画像を開き、ウィンドウを縮めたり拡げたりしてみて下さい。中の絵がそのたびに上下しますね。つまり、左下が原点になっています(fig.01)。通常のMacのアプリではどうでしょうか。普通は左上が原点になっているはずです。こちらの方が動きとしてずっと自然です。何故なら、ウィンドウのサイズを変更するには、右下にあるresizeコントロールを操作します。この時、左上が原点になっていれば、見える範囲を調節するように感じるからです(fig.02)。もちろん、表示されている内容によっては、動作が違う方が良い場合もあるでしょうが、TinyViewの場合は左上原点の方がより自然でしょう。

[fig.01]resizeコントロールを操作すると、中身の絵は左下が固定の動きをする
http://www.remus.dti.ne.jp/~yoshiki/cocoa/ed1/38/images/fig01.jpg

[fig.02]左上が原点なら、resizeコントロールの操作は表示範囲の変更に見える
http://www.remus.dti.ne.jp/~yoshiki/cocoa/ed1/38/images/fig02.jpg

 この様に左上を原点としたい時、一番簡単な方法は、Viewを上下反転させてしまう方法です。NSViewのリファレンスを見て下さい。isFlippedというメソッドがあるはずです。これをオーバライドしてYESを返すようにすると、座標が上下反転します。では、実装してみましょう。MyImageView.mに、次のメソッドを追加して下さい。

- (BOOL)isFlipped{
    return YES;
}

 ビルドして実行してみましょう。適当な画像を開くと、あれ?何も表示されなくなってしまいました(fig.03)。resizeコントロールを操作すると、スクロールバーは左上原点の動きをしますから、これはうまくいっているようです(fig.04)。でも、画像が表示されないのでは意味がありません。何故表示されないのでしょう。これは、composite系のメソッドが、isFlippedの影響を受けないことに原因があります。つまり、原点が左上に行ってしまいましたから、そこを原点としてその上に描いてしまっているのです(fig.05)。ちなみに、composite系以外の、isFlippedの影響を受けるメソッドでしたら、左上を原点とした上下反転した画像が表示されます(fig.06)。

[fig.03]画像が表示されなくなってしまった
http://www.remus.dti.ne.jp/~yoshiki/cocoa/ed1/38/images/fig03.jpg

[fig.04]resizeコントロールを操作すると、中身は左下固定になっているのが
分かる
http://www.remus.dti.ne.jp/~yoshiki/cocoa/ed1/38/images/fig04.jpg

[fig.05]ウィンドウの外に描画してしまっている
http://www.remus.dti.ne.jp/~yoshiki/cocoa/ed1/38/images/fig05.jpg

[fig.06]composite系以外は、isFlippedの影響を受ける
http://www.remus.dti.ne.jp/~yoshiki/cocoa/ed1/38/images/fig06.jpg

では、これを解決するために、composite系で描画する原点を、描画範囲の左下に移しましょう。次の様にdrawRectメソッドを修正して下さい。

- (void)drawRect:(NSRect)rect {
    [ image compositeToPoint:NSMakePoint( NSMinX(rect), NSMinY(rect) + NSHeight(rect)) 
fromRect:rect operation:NSCompositeSourceOver];
}

 y座標に高さを足しています。左上が原点ですから、これで左下の座標になります。NSMakePoint()は座標を作る関数です(Xcodeを使っている方は、コマンドキー+ダブルクリックで実装されている場所に飛び、何をやっているのかを確かめてみて下さい)。さて、ビルドして実行してみましょう。今度は、きちんと表示されました(fig.07)。resizeコントロールを操作してみましょう。あれ?ウィンドウ内の画像の動きが左下原点の様に見えます。でも、スクロールバーを見ると、表示しているのは左上のはずです(fig.08)。スクロールバーを使って、下にスクロールしてみましょう。何だか滅茶苦茶になってしまいました(fig.09)。

[fig.07]ウィンドウの中に表示されるようになった
http://www.remus.dti.ne.jp/~yoshiki/cocoa/ed1/38/images/fig07.jpg

[fig.08]スクロールバーの位置と描画内容が合っていない
http://www.remus.dti.ne.jp/~yoshiki/cocoa/ed1/38/images/fig08.jpg

[fig.09]縦スクロールで画像が崩れてしまった
http://www.remus.dti.ne.jp/~yoshiki/cocoa/ed1/38/images/fig09.jpg

これはisFlippedをYESとしたために、今回はMyImageViewとimageの座標が等しく無いからです。具体的には上下逆転しています。そこで、これを補正するためのコードを追加します。drawRectを次の様に修正して下さい。

- (void)drawRect:(NSRect)rect {
    NSRect theFrame, theSrcRect;

    theSrcRect = rect;
    theFrame = [ self frame];
    theSrcRect.origin.y = NSHeight(theFrame) - NSHeight(rect) - NSMinY(rect);
    [ image compositeToPoint:NSMakePoint( NSMinX(rect), NSMinY(rect) + NSHeight(rect))
 fromRect:theSrcRect operation:NSCompositeSourceOver];
}


 ビルドして実行してみて下さい。今度は正常に動作したはずです。なお、座標が上下逆転しているのにfig.06の様に描画が上下逆転しないのは、先程も言ったように、composite系は描画に関してはisFlippedの影響を受けないからです。余談ですが、drawRectを次の様に実装すれば、isFlippedがYESでもNOでも動作するようになります。この方がより汎用的であると言えるでしょう。

- (void)drawRect:(NSRect)rect {
    NSRect theFrame, theSrcRect;

    theSrcRect = rect;
    if( [ self isFlipped]){
        theFrame = [ self frame];
        theSrcRect.origin.y = NSHeight(theFrame) - NSHeight(rect) - NSMinY(rect);
        [ image compositeToPoint:NSMakePoint( NSMinX(rect), NSMinY(rect) + 
NSHeight(rect)) fromRect:theSrcRect operation:NSCompositeSourceOver];
    }else{
        [ image compositeToPoint:rect.origin fromRect:theSrcRect operation:
NSCompositeSourceOver];
    }
}

 さて、今日まで随分とウィンドウの動作に手を入れてきました。この様に見栄えにこだわることが、それほど必要なことなのでしょうか。今まで実装して来たことを思い出してみて下さい。見栄えとは言っても、別段何かを飾り立てるようなことはしていません。求めて来たのは、ただひたすら、人間にとってより自然な動作になるように。これだけです。動作が自然になれば、ユーザはその部分に関して気を使う必要がなくなります。つまり、自分のやりたいことのみに集中することが出来るのです。Macのアプリが使いやすいのは、こういった地道な努力の積み重ねの結果だと、私は考えています。余計な所を飾らない、そしてこういった所で手を抜かない。これこそが、Macらしいアプリだと思います。
 なお、この様な努力の積み重ねの結果、動作がより自然になればなるほど、ユーザから見ると、何もやっていないように見えてしまいます。何だか報われないですね(^^;)。でも、それでもMacのプログラマは、使いやすい物を目指すのです。

(全てのサンプル画像は、ゆきみだいふくさんのご好意により、使用させていただいています。)

小池邦人の「Carbon API 徒然草」(2004/02/06)

アプリケーションの入り口に立つ

CarbonアプリケーションをC言語で開発する場合、その入り口のルーチン(関数)はmain()となります。この点については、他の環境でのアプリケーション開発と変わりありません。ちなみにC言語のプログラミング入門書を見ると、必ず最初に以下のようなサンプルコードが紹介されています。これはどうも、カーニハン&リッチー(伝説的C言語入門書)からの伝統のようです(笑)。

main()
{
    printf( "hello, world n" );
}

このソースをコンパイル&リンクして完成したアプリケーションは、標準出力へ”hello, world”と出力し、その後改行を1回実行します。ひと昔前のパソコンであれば(つまりMS-DOSがインストールされておりモニタにカーソルが点滅しているパソコン)このアプリケーションを実行することで、現状のカーソル位置に”hello, world”と表示できます。

昔は、こうした簡単な入門サンプルを見た人から「Macintoshで簡単に文字を表示したいだけなんですが、どうしたら良いでしょうか?」という質問をよく受けました。確かに、以前であれば(ある意味では今もなんですが)、ウィンドウをオープンし、そこに”hello, world”と表示するだけのために、ToolBox APIを含めて数多くの複雑な概念を勉強する必要がありました。まあ、それでも文字を表示するだけならそれほど困難ではないのですが、次のステップとして、文字入力、画像表示、ユーザインターフェースに伴うウィンドウやイベントのハンドリングと進んでいくと…「Macアプリの開発はハードルが高い」と言われた「所以」にぶつかることになります。このため、初期ユーザの中には、アプリケーションの入り口の段階で立ち往生したまま、Macintoshでのプログラミングを挫折した人も多かったようです。

しかし、皆さんもう心配いりません!MacintoshはMac OS Xの導入で大きく進化しました!アプリケーションフォルダからConsoleを起動して上記のCarbonアプリケーション(なのです)を起動してみてください、ちゃんとConsoleウィンドウに”hello, world”と表示されるではありませんか!Macも簡単になったものです(笑)。さて、冗談はさておき、Macintosh開発環境(XcodeやCodeWarrior)でも、標準出力用Consoleウィンドウを自動にオープンする仕組みがあり、別環境用アプリケーションの開発にも対応しています。また現状では、単純な処理であれば、Carbonなどの深い知識がなくても「Macintoshライク」なアプリケーションを簡単に開発できる環境がいくつも存在しています。

実は、カーニハン&リッチーからの伝統はXcodeでもしっかり守られているのです。XcodeにおいてUNIXのコマンドラインから実行するアプリケーションを開発する場合、新規プロジェクトテンプレートとして「Standard Tool」(リストの一番下)を選択します。保存されたプロジェクトで唯一のソースファイルには、以下のようにサンプルコードが記述されています。

int main (int argc, const char * argv[]) {
    printf("Hello, World! n");
    return 0;
}


先んじて紹介したソースコードとそっくりですが、main()に2つの引数が追加されていることが分かります。最初のargcには、実行されたUNIXコマンドのパラメータ数に1を足した値が代入されています。次のargvはポインタの配列で、コマンド名とパラメータ名の文字列が代入されています。例えば、あるファイルを別名称で複製するcopy(ふたつのパラメータを受け取る)と言うUNIXライクなコマンドを作成したとします。ターミナルから…

copy gozira.jpg gamera.jpg

と打ち込むと、argcには3が、argv[0]には”copy”が、argv[1]には”gozira.jpg”が、argv[2]には”gamera.jpg”が代入されてきます。これらを受け取ることで、アプリケーションは実際のファイルコピー処理を実現できるわけです。これは、ユーザからの「意志」をアプリケーション側に伝える仕組みです。太古から実装されているユーザインターフェースの一種とも言えるでしょう。この仕組みは単純なのですが、アプリケーションにとっては重要な意味を持っているわけです。これとまったく同じ仕組みではありませんが、Carbonアプリケーションにも、「ユーザの意志」をアプリケーション側に伝える仕組みは用意されています。それについては、後々詳しくお話しすることになりますので、今回のmain()の引数の話しをぜひ記憶しておいてください。

さて、先ほどのテンプレートソースを参考にすると(笑)、今回の「サンプルアプリケーションの入り口」であるmain()ルーチンは、以下のように記述されます。Macintoshでは使いもしないargcとargvが律儀に記載されていますので、main( int argc, char* argv[] )の部分は、main(void)と省略してもかまいません。

int main( int argc, char* argv[] )
{
    long    ver;

    if( ! Gestalt( gestaltSystemVersion,&ver ) )
    {
        if( ver >= 0x1020L )
            startApplication();
        else
            doErrAlert( 1 );
    }
    return( 0 );
}


これから紹介していくソースコードにおいて、名称の先頭が大文字のルーチンはCarbon Frameworkを含めたシステムが提供するAPIで、小文字の方は自作ルーチンとなります。次回は、このソースコードの内容(そんな大げさな内容ではないですが…)と意味についてお話したいと思います。

つづく

「Behind the WebObjects」  第13回  田畑 英和

 前回D2Wのアシスタント機能について紹介したときに”task”の説明をおこないましたが、今回はこの”task”について詳しくみていきたいと思います。D2Wが標準で生成する画面は、基本的にはEntityとtaskの組み合わせによって決められます。つまり、あるテーブルに対してどのような処理(task)を実行するかによって画面が生成されることになります。
 実際には各taskごとのテンプレートがD2Wのフレームワーク内に用意されており、このテンプレートはEntityに依存せず汎用的に使用できるようになっています。よって、どのようなデータベース(モデル)を用いた場合でもEntityとtaskに応じて画面を動的に生成することが可能になっています。

 それでは具体的にどのようなtaskがあらかじめ定義されているかをみていきましょう。D2Wのフレームワークでは各taskに対応する形でにはInterfaceが定義されていますのでそのInterface名も紹介しておきます。

・QueryAll(QueryAllPageInterface)
 標準ではログイン後に最初に表示される画面で使用されるtaskです。任意のEntityを任意のAttributeで検索することができます。ただし”Hidden Entity”に対して検索をおこなうことはできません。QueryAllでは任意のEntityに対して単一のAttributeでしか検索ができませんが、複数のAttirbuteで詳しく検索をおこないたい場合は”Query”を使用します。

・Query(QueryPageInterface)
 任意のEntityのすべてのAttributeでの検索をおこないます。QueryAllではリレーション先のデータは検索対象には含まれていませんが、Queryではリレーション先のデータで検索をおこなうこともできます。検索時に複数の条件を指定した場合にはAND検索がおこなわれます。

・List(ListPageInterface)
 任意のEntity内のデータを一覧表示し、QuerryAllあるいはQueryで検索した結果の表示で用いられています。データの一覧を任意のAttirbuteでソートすることもできます。

・Inspect(InspectPageInterface)
 任意のEntityの任意のデータ(1レコード)の詳細を表示します。Listではリレーション先のデータまでは表示されませんが、Inspectではリレーション先のデータも表示されます。このタスクではデータの表示をおこなうだけで、データの変更をおこなうには次の”Edit”を使用します。

・Edit(EditpageInterface)
 データの変更や新規登録をおこないます。リレーションの編集をおこなうには”EditRelationship”や”Select”などを使用します。

・EditRelationship(EditRelationshipPageInterfece)
 Select(SelectPageInterface)
 リレーションの編集をおこないます。リレーションの編集は対1と対多の両方に対応しています。実際にリレーションを設定する手順ですが、既存のデータをリレーション先として設定する場合はまず”Query”を用いて検索をおこない、検索結果一覧の中からリレーション先を選択します。このとき検索結果の一覧表示には”Select”が使用されます。既存のデータにリレーション先が存在しない場合は、”Edit”を用いてデータを新規に作成してからリレーションを設定することもできます。またEditRelationshipでは既存のリレーションを解除することもできます。

・Confirm(ConfirmPageInterface)
 処理の実行を確認し、Entityには依存しません。Yes/Noの2択により処理を実際に実行するかキャンセルするかを選択し、データを削除するときの確認に用いられています。

・Error(ErrorPageInterface)
 こちらもEntityには依存せず、エラーメッセージの表示をおこないます。例えばモデル上で設定したDelete Ruleに違反するようなデータの削除操作をおこなったときに用いられます。

 以上があらかじめ定義されているtaskの概要ですが、今回紹介した機能はあくまでも標準の状態での機能です。ルールを記述していくことによって例えばListのページにリレーション先のデータを追加するなど、標準の機能に様々な変更を加えていくことができますし、独自のテンプレートを使用することもできます。

 以上のようなtaskごとにテンプレートが用意されているわけですが、以前紹介したように標準で3種類のLookが用意されています。そのため1つのtaskに対してLookごとに3種類のテンプレートがフレームワーク内に実装されています。例えば”List”の場合は以下の3つのテンプレートが存在します。

BASListPage, WOLListPage, NEUListPage

 これらは異なるコンポーネントとして存在するわけですが、機能的には同一であるため、それぞれ共通のD2WListPage(ListPageInterfaceを実装している)を継承する形で実装がおこなわれています。

 さて、これまでしばらくD2Wの話ばかりしてきましたので、D2Wの解説はひとまず終わりにして、次回は話題を変えてみたいと思います。

ニュース・解説

 今週の解説担当:新居雅行

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┃Java 1.4.2がリリース、日本語の処理に問題含み
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Mac OS XのJavaがVer.1.4.2にアップデートされ、1.4.2_03のリリースが使えるようになった。ソフトウエアアップデート等でアップデートできるが、Ver.1.4.1は削除されてリプレースとなる。アップデート後のシステムは、1.3.1、1.4.2等が利用できる状態にアップデートされる。
1.4.2ではLiveConnectに対応した。LiveConnectは当初はNetscapeで開発された機能で、HTML内に記述するJavaScriptからアプレットがオブジェクトとして作業できたり、逆にアプレット側のJavaプログラムがそれを含むHTMLページ側に記述したJavaScriptの関数などを呼び出すことができる。

さらに、Swingのファイル選択ダイアログボックスであるJFileChooserが改良され、より通常のダイアログボックスに近い形式になった。カラーコレクションについては、1.4.1ではKodakCMMのインプリメンテーションであったが、1.4.2ではシステムプロパティで設定することでColorSyncを利用することができる。AWTの改良、そしてプロキシ設定等も改良されている。

一方、Windows版などでも問題になっていた、JISコード文字列のJava 1.4.2での問題はそのままMac版にも持ち込まれた。ISO-2022-JPのエンコードで余分なエスケープシーケンスがあるものをStringクラスの文字列としてインスタンス化すると、内部で無限ループに陥る。BizTechやまぐまぐといったメールマガジンで実際にそうしたエンコードがなされおり、よく使われているPerlのライブラリ等でそうしたデータ構築をするためと思われるが、不要なエスケープシーケンスが混じったメールは日常的に流通している。なお、この点については、Windows版が登場したときにバグレポートされており、Sun Microsystems側は認知している問題で、この問題が顕在化してすでに半年以上は経過している。次回のリリースで直るものとなっているようで、1.4.2_04ないしは1.5では直るものと認識されているようだ。このバグにより、たとえばJavaMailを使っている場合にある種のメールを受信すると、そこでプロセスの処理が止ってしまい、CPUの利用率が極端に高くなるという状況に陥る。

なお、WebObjects 5.2.2については、Java 1.4.2での動作は十分に検証されていない。基本的にはJava 1.4.1での利用が保証されたバージョンとなっている。明確な問題は発生していないようであるが、WebObjectsの運用等では意識しておく必要はあるかもしれない。

Java 1.4.2 Now Available
http://developer.apple.com/java/index.html

Java 1.4.2 Release Notes
http://developer.apple.com/documentation/ReleaseNotes/Java/Java142RN/index.html

Java 1.4.2 API Reference: Apple Extensions
http://developer.apple.com/documentation/Java/Reference/1.4.2/appledoc/api/index.html

Java 1.4.2 API Reference: J2SE
http://java.sun.com/j2se/1.4.2/docs/api/index.html

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┃Cocoaで利用するXMLパーサクラスについての解説文書
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Mac OS X 10.3以降で利用できるXMLパーサについての解説文書が公開された。イベントドリブン方式のXMLパーサである。XMLをもとに、特定のタグやあるいは文字列を見つけることによってデリゲートで定義されたメソッドを呼び出す方式で、XMLの内容を解析できるようになっている。なお、このクラスはObjective-Cでのみ定義されているが、JavaについてはSAXなどを利用することを想定していると思われる。

Event-Driven XML Parsing
http://developer.apple.com/documentation/Cocoa/Conceptual/XMLParsing/index.html

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┃CocoaのNSViewでの効率的な描画機能についての注意
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Technical Notesに、Mac OS X 10.3からCocoaに搭載された描画高速化機能についての注意点が掲載された。NSViewにgetRectsBeingDrawn:count:とneedsToDrawRect:のメソッドが追加され、再描画が必要な領域なのかを判断できるようになった。しかしながら、文字があるような場合などで正しく判断しないことがあり、その回避方法を解説している。

Working Around Incorrect -needsToDrawRect: Behavior in Custom View Classes
http://developer.apple.com/technotes/tn2002/tn2107.html

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┃サウンドはNSSoundでならす
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Cocoaでサウンドをならすときには、NSMovieよりもNSSoundを使う方がより良い結果を得られることがTechnical Q&Aで紹介されている。NSSoundはCore Audioの機能を使ってさまざまなフォーマットが利用できるようになっており、安定してサウンドの再生ができる。

Use NSSound instead of NSMovie for audio only playback on Mac OS X 10.3 and
greater
http://developer.apple.com/qa/qa2001/qa1335.html

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┃Launch Servicesの解説とリファレンスが公開
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Launch Servicesのドキュメントが公開された。解説文書とリファレンスが公開されている。Mac OS Xで搭載されているLaunch Servicesは初期の頃から存在するが、ドキュメントがないためにヘッダを参照してプログラムをした人も多いだろう。別のアプリケーションを起動したり、文書を開くという仕組みをプログラムするときに必要になる。ほかに、アプリケーションの情報や、文書がどのアプリケーションで起動されるかなどの情報を取得したり、最近使った項目の処理などの機能もある。起動する場合もさまざまなオプションがあり、URLを開く対象に指定することもできる。

Launch Services Concepts and Tasks
http://developer.apple.com/documentation/Carbon/Conceptual/LaunchServicesConcepts/index.html

Launch Services Reference
http://developer.apple.com/documentation/Carbon/Reference/LaunchServicesReference/index.html

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┃JBossが1.0.1にアップデート
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Mac OS X Server 10.3に含まれるアプリケーションサーバのJBossがVer.1.0.1にアップデートしている。JBossそのもののバージョンは3.2.2RC2、Tomcatは4.1.24となっているが、基本的には、Java 1.4.2への対応となっている。なお、Java 1.4.2へアップグレードした後にJBossが起動できない場合の対処も文書が公開されている。

JBoss Update for Mac OS X に関する情報とソフトウェアのダウンロード
http://docs.info.apple.com/jarticle.html?artnum=120310

Java 1.4.2: Java 1.4.2 Update インストール後 JBoss と Tomcat が開始しない
http://docs.info.apple.com/jarticle.html?artnum=107814

MOSAからのお知らせと編集後記は割愛します

MOSA Developer News   略称[MOSADeN=モサ伝]
Apple、Mac OSは米国アップルコンピュータ社の登録商標です。またそのほかの各製品名等はそれぞれ各社の商標ならびに登録商標です。
このメールの再配信、および掲載された記事の無断転載を禁じます。
http://www.mosa.gr.jp/
Copyright (C)2004-2006 MOSA. All rights reserved.