|
.NET Tools 注目のJava→C#コンバータを試用する |
 |
以上のような問題に遭遇しながら、変換結果のソースを書き換えた。期間としては、ほかの仕事も行いながら1週間ほどを要した。相当な大仕事であったことは間違いない。とはいえ、VS .NETの統合環境に含まれるプロジェクト中の全ファイルを対象とした文字列置換機能のおかげで、機械的に一気に置き換えられたものも多い。そのため、1週間という期間の中で最も時間を食ったのは、実は書き換えそのものではなく、同等機能がないクラスやメソッドに遭遇したときに、どうやって書き換えるべきか悩むことであった。
それはさておき、Windowsサービスとして稼働させるために必要な最低限のコード（サービスの開始や停止のハンドラなど）はまったく新規に書き起こしてソースに追加した。つまり、（インストーラやドキュメントを除き）Java版のりすと亭とほぼ等価の使い勝手にまで到達している。実際に稼働している証拠画面写真は以下のとおりだ。
 |
| C#版「りすと亭」の稼働画面 |
このサイトは当分の間稼働させる予定なので、直接http://erika.piedey.co.jp:8088/index.htmlを訪問していただいても構わない。ただし、テスト・サイトなので、24時間常時稼働することは保証できない。実際に使って確かめたい人は、このサイトにあるtestml4メーリング・リストにメンバー登録して、メッセージを送信していただいて構わない。JLCAの結果を体験するというだけでなく、.NET Frameworkの実用度を確かめるという意味でも、しばらく継続的に運用してみたいと考えている。
結論・どういう場合に使っていくべきか
同じソースをJ#とJLCAで扱ってみた感想は、J#の方が圧倒的に手間が少ないということだ。製品版になれば、J#はほとんど手間をかけないで、JDK1.1.4レベルのJavaソースを扱えるようになるだろう。それに対して、JLCAは製品版になっても、手動書き換えなしで実行できるソースを生成できる見込みは薄い。そのため、手間をかけないでJava資産を.NET Framework上に持っていきたいなら、J#の利用を検討する方がよいと考えられる。またJ#があれば、C#で開発しているソフトからJavaのクラスを利用できるので、今後C#で開発を行いたいと考えている場合でも、J#で十分といえる。決して、すべてのソースをC#に変換する必要はない。
しかしJLCAに存在価値がないわけではない。J#はどこまで行ってもJavaの文法から離れられない。J#だけで開発しているならよいが、新規開発部分はC#で、ということになると、1プロジェクトに2つの似て非なるプログラム言語のソースが混在することになり、生身の人間のうっかりミスを誘発する危険がある。また、C#しか知らないプログラマー、J#しか知らないプログラマがチームを組むとお互いに理解できない領域ができてしまう危険もある。そういう場合には、全部C#にソースを統一してから作業を始めた方がよい場合もあるだろう。その場合には、手動書き換えに多少の手間が掛かるとしても、全体の効率から考えれば、十分にお釣りがくるというケースも多いに違いない。そのようなケースを想定した場合、すべて手動でソースを書き換えるのに比べれば、まだ問題が多かったJLCAベータ1をもってしても、けた違いに素早い作業であったといえる。実際に、りすと亭のソース・コードを手作業でC#に書き換えようと試みたことがあったが、細かい文法上の相違が多く、すぐに挫折した経験がある。それに比べれば、JLCAはまるで天国である。
もう1つ、クラス・ライブラリのオーバーヘッドの問題がある。J#を使うと、JDK1.1.4互換のクラス・ライブラリを追加的に使用することになる。その結果、実行に必要なライブラリが増加する、機能の呼び出しに余計なオーバーヘッドが生じる、覚える必要のあるクラスの数が増える、といった問題が生じる可能性がある。効率重視の場合は、JLCAで変換してから実行した方がコンパクトで速くなる、ということは十分考えられる。
筆者のごく個人的な感想としていえば、かつてBASIC、C、C++、Javaを取っ換え引っ換え使っているうちに、構文の書き間違いが増えた体験から、できるだけ扱うプログラム言語の種類は減らしたいと考えている。そのため、少し手間が増えても、すべてC#に統一して扱うのは歓迎である。そのため、どちらかといえば、J#よりもJLCAの方に好感持ったというのが個人的な結論である。
さて、J#とJLCAの比較という視点を離れれば、もっと別の大きな問題がある。それは、J#、JLCAがどちらもJDK1.1.4ベースであるということだ。これまでVisual J++で開発してきたプログラマーはそれで問題ないだろうが、それ以外の開発ツール（JDK2ベース）でやってきたプログラマーには、いまさらJDK1.1.4ベースというのはつらい話だろう。筆者の持つJavaソースはすべてJDK1.1.4ベースで対応可能なので、個人的なJava資産の活用という点では、すでに結論が出てしまったような感があるのだが、そうではない方々にとっては、これからの重大な課題となるだろう。なお、JLCAの開発元であるArtinSoft社は、J2EE完全対応のコンバータを有償販売する予定があるとのことなので、JLCAよりもこのサードパーティー製品を待つ方が得策かもしれない（ArtinSoft社の当該製品に関する情報ページ）。これ以外にも、Java世界と.NET世界の間に橋を架ける製品は、Microsoft以外からもさまざまな製品が登場する気配を見せている。J#やJLCA以外のこれらの製品にも目を向ける価値がありそうだ。
| 関連リンク | |
| りすと亭のスタートページ | |
| testml4メーリング・リストのページ | |
ArtinSoft社の当該製品に関する情報ページ |
|
 |
 |
| INDEX | ||
| ［.NET Tools］ | ||
| 注目のJava→C#コンバータを試用する | ||
| 1．インストールと実行 | ||
| 2．変換の内容と品質 | ||
| 3．りすと亭の変換で遭遇した問題点 | ||
 |
4．稼働したソースと結論 | |
| コラム：JLCAベータ1で発生した問題点（バグ編） | ||
 |
||
 |
「.NET Tools」 |
- 第2回 簡潔なコーディングのために （2017/7/26）
ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている - 第1回 Visual Studio Codeデバッグの基礎知識 （2017/7/21）
Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう - 第1回 明瞭なコーディングのために （2017/7/19）
C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える - Presentation Translator （2017/7/18）
Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
 |
|
|
|
|
