電子書籍の厳選無料作品が豊富!

javaからマックOSのAPIを直接制御させるアップル独自拡張仕様のJNIは、
今でも存続していますでしょうか、
それとも廃止されていますでしょうか?
・・・それとも更に高度なアップル独自拡張が進んでいますでしょうか?

A 回答 (3件)

>(つまり、OSX時代になってからのマック用jvmは、まったくSunのJDKをそっくりそのままポーティングして使うことになった。

と事実上考えてよいですね?)

依然としてJVMを作っているのはAppleですが、これはSunとの協力のもとに開発を行っているそうで、ほぼ純正と同じものが移植されていると考えていいようです。Sunのサイトにいっても、Mac OS X用のJDKについては「Appleより配布されてます」という扱いになってますので・・。

>(つまり、一部にこのフレームワークが含まれるjavaアプリを開発したい場合には、該当フレームワークが他OS上jvmでの挙動に影響を与えないような分岐バイパスするルーチンを事前に用意する必要がある、と基本的に考えていてよいですね?)

これは、ちょっと違います。そのような起動OSに応じてCocoaを使うか否かを処理するようなことはしません。なぜなら、CocoaアプリケーションはMac OS X以外では一切動かないからです。(旧Mac OSですら動きません)
 CocoaのアプリケーションとJavaの一般的なアプリケーションでは、プログラムの構造からして根本的に違います。そもそもCocoaアプリケーションを旧MacOSやWindowsにもっていっても、それはただのフォルダとしてしか表示されず、アプリケーションとは認識されません。ですから起動すらできないでしょう。
 ですので、Cocoaを使う場合はMac OS X専用と割り切った作り方になります。

この回答への補足

本当にご親切にありがとうございます!

>ほぼ純正と同じものが移植されていると考えていいようです

なるほど。アップルvmの形式が、java1時代からのMRJ形式でなく、今では完全にJDKになってくれているのですね!

勘違いしていたのがやっと分かってきた気がします。

(MRJ時代に、汎用javaアプリから、特別にマックのシステムを動作させることが可能なJNI拡張というものがありましたが、これはJDKでは「そんなもの知らないよ」という独自拡張でしたのでJNI拡張コードを含むjavaアプリは基本的に互換性が失われる、と解説書に記述されているのを読んで、気になって投稿しました)


現在の「アップル用javaコード」というものは、完全にマック専用Cocoaアプリを作成するか、そうでないか、のオール・オア・ナッシングだということですね!
(両生類的汎用javaアプリからマックOSを直接制御することもできる、という考え方は消滅したわけですよね?)
JAVA本来の原点にアップルが軌道修正してくれた、と考えてよさそうですね?
(単にJAVA使いのプログラマに、簡単にjavaだけでmacアプリが作成できますよ、という便宜を提供する、ということでとどめて、それ以上の拡張で互換性が失われることを避けた、ということになりそうですね?)

まだ勘違いしているようでしたら、どうかまた私を正しくお導きくださいましたら幸いです。

補足日時:2005/07/05 00:22
    • good
    • 0

>Sunの標準仕様のほうからCocoaに合わせているからアップル独自拡張というものが必要なくなった、という考え方でよろしいでしょうか?



いえいえ、そうではありません。つまり、Mac OS XのOSのコアにCocoa APIとJavaの間を結ぶブリッジ機能が組み込まれているのですね。Java内部からCocoaのAPIを利用すると、Java仮想マシンからブリッジを介してOSのCocoaフレームワークを呼び出すような仕組みがOS内に最初から入っている、ということです。
 ですので、改めてJNIがどうとか考えることはなくて、普通のJavaプログラムと全く同じ感覚でappleのCocoaパッケージをimportしてJavaのプログラムを書けば、そのままCocoaアプリケーションができてしまう、という感じです。(ただし、CocoaはコードとGUI関係のデータが分離してますので、実際はそう単純なものではありませんが、イメージとしてそんな感じで動く、ということです)
 あくまで「Mac OS Xの内部の仕組みとして」ということで、Javaの規格そのものがMacのために変更されているとかいうわけではありません。

ですから、こうして作られたプログラムは、Mac OS X以外では動きません(他のOSにはCocoaフレームワークはないので)。
    • good
    • 0
この回答へのお礼

とてもご親切にありがとうございます!
だんだん謎が解けてきた感じです。


>ですので、改めてJNIがどうとか考えることはなくて、

なるほど!
jvmランタイム側ではなく、OS側の機能だからSunの仕様を逸脱したアップルの独自java拡張ではなくなった、
ということになる訳ですね。

(つまり、OSX時代になってからのマック用jvmは、まったくSunのJDKをそっくりそのままポーティングして使うことになった。と事実上考えてよいですね?)

>ですから、こうして作られたプログラムは、Mac OS X以外では動きません

なるほど、勝手な独自拡張ではなくSunの仕様から一歩も外れてはいないけれど、Javaの「ライトワンス・ランエニウェア」の理念は働かないので微妙なところですね。
(つまり、一部にこのフレームワークが含まれるjavaアプリを開発したい場合には、該当フレームワークが他OS上jvmでの挙動に影響を与えないような分岐バイパスするルーチンを事前に用意する必要がある、と基本的に考えていてよいですね?)

お礼日時:2005/07/03 16:54

現在、Macは、Mac OS Xが標準となっています。


 Mac OS Xでは、Cocoaと呼ばれるフレームワークによってアプリケーションが構築されます。このCocoaは、Objective-CとJavaから標準的に利用できるようになっています。
 つまり、現在のMac OS Xでは、APIは最初からJavaで使えるように設計されているわけです。(未対応のものもありますけど)

Mac OS X以前の旧MacOSについてのことをご質問でしたら話は別ですが・・。

この回答への補足

さっそくにどうもありがとうございます。
Sunの標準仕様のほうからCocoaに合わせているからアップル独自拡張というものが必要なくなった、という考え方でよろしいでしょうか?

その場合、Cocoaを操作するコードを含むjavaアプリケーションは、
Mac OS X以外の他のOS上で動作するjvmに対して、互換性がなくなるような心配はしなくて大丈夫な回避策がSunの標準仕様で確保されているでしょうか?
(それともOSを判定するルーチンをプログラマが自前で用意して他OSのjvm上で停止してしまうようなことを防止する必要が生じますでしょうか?)

補足日時:2005/07/02 22:46
    • good
    • 0

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!