特集　J#の真実 Part 2 ４．Javaと他言語のインターフェイス 株式会社ピーデー 川俣 晶 2001/11/16

---

Javaと他言語のインターフェイス

　他言語で書かれたモジュールを呼び出す場合でも、特別な配慮はいらない。Javaのパッケージ名と他言語の名前空間は同じものと扱われるので、java.util.Vectorクラスを使うのと同じように、System.Collections.ArrayListクラスを使うことができる。

　基本的に、.NET Framework上では共通のデータ型を共有するので、異なる言語で書かれたモジュールに値を渡すのに特別な処理はいらない。しかし、J#利用時にはこの原則は適用されない。これは.NET Frameworkの文字列クラスと、Javaの文字列クラスがイコールでないことに起因する。どちらも異なるメソッドを持つものなので、Javaの文字列クラスを捨てて、.NET Frameworkの文字列クラスに統一しては、互換性が損なわれる。かといって、このままではJavaの文字列をC#などで書かれたモジュールとやり取りできない。

　J#では、この問題に対して、以下の2つの機能を持って対処している。

• Javaのstringから.NET FrameworkのSystem.Stringへの自動変換
• .NET FrameworkのSystem.StringからJavaのstringへ変換するjava.lang.string.fromStringメソッド（staticメソッド）の提供

　つまり、Javaから他言語に渡す場合は何も悩む必要はない。しかし、他言語から戻ってきた文字列は、自動的には変換できず、fromStringメソッドで明示的に変換してやらねばならない。このメソッドの使用例は、上記コードのDotNetStringクラス中のtoStringメソッドにある。

20:   public String toString() 21:   { 22:     return String.fromString(s); 23:   }

　このメソッドは、.NET Frameworkの文字列をJavaの文字列に直して返している。

ここまで動いた

　いろいろな問題が起き、予定の何倍もの時間を食ったが、最低限稼働させるところまではたどり着いた。その結果が以下のとおりだ。まず、簡易httpd機能が稼働していることを示しているのが以下の画面写真である。

J#により作成した「りすと亭」の簡易httpd機能が稼働している画面

いろいろな問題が起き、予定の何倍もの時間を食ったが、最低限稼働させるところまではたどり着いた。

　そして、メールの配送が行われていることを示すのが以下の画面写真である。

「リスト亭」によりメールの配送が行われていることを示す画面

J#コンパイラは比較的完成度が高いが、ライブラリの方はまだまだこれからという印象を受けた。ただし.NET Frameworkを直接呼べば、たいがいの問題は回避可能だ。

　以上、2枚の画面から分かるとおり、結果的には「割とちゃんと動く」というところまでたどり着くことができた。機能面で見ると、コンパイラは比較的完成度が高く、ライブラリの方はまだまだこれからという印象を受けた。ただ、ライブラリは相当品を自分で書いたり、.NET Frameworkを直接呼べば回避可能なので、どうしてもJ#を使いたい場合は致命的な障害にはならないかもしれない。とはいえ、あまり手動書き換えが多いとJ#のありがたみがないので、実用ツールとしてはもうちょっと待つべきだろう。

　ここまではベータ1についての感想だが、場合によっては、J#が製品版になった段階でも、プログラムの移植は楽ではないかもしれない。コンパイラもライブラリも新規書き下ろしなので、細かい部分の挙動の違いは、ポツポツと発生するだろう。しかし、何もかもJavaからC#に書き換える場合と比較すれば、驚くほどわずかな時間で実行できる、というのも事実だろう。Java資産を.NET Framework上でも活用したいと思う人なら、J#に期待するのも悪くない選択だろう。

INDEX
	［特集］J#の真実
	Part 2 JavaからJ#へ：プログラム移植の実際
	1．Visual J++ 6.0からの移行とコンパイラの互換性
	2．ライブラリの互換性（1）
	3．ライブラリの互換性（2）
	4．Javaと他言語のインターフェイス

　

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）