46

JVM で C# コードを実行したい

私の会社には大規模な C# コード ベースがあります。このコードの半分以上は、Excel ワークブックの作成、読み取り、変更、計算、および書き込みを行うコア エンジンです。お客様や潜在的なお客様から、エンジンの Java バージョンを構築する予定があるかどうかという質問が頻繁に寄せられますが、その多くは UI にまったく関心がありません。Java アプリケーションから私たちの .NET ライブラリを使用するのに苦労した顧客もいます。

そのため、理想的には別個の Java ソース コード ベースを維持せずに、コア エンジンの Java バージョンを構築したいと考えています。

Eric Sinkは、この問題を非常によく説明しています。私も同様の立場ですが、私たちのソフトウェア ライセンスにはロイヤリティ フリーの展開が含まれており、Eric が Mainsoft を選択することは私たちにとって非初心者でした。

私は、「c# to jvm」のようなものを数か月ごとに数年間グーグルで検索してきましたが、喜びはありませんでした。Java 用の同様のソフトウェアの開発に 7 年ほど費やしてきた経験から、コア エンジンで使用する .NET API は簡単にカプセル化でき、Java ライブラリを使用して必要なすべてを達成できると確信しています。したがって、C# -> JVM コンパイラさえあれば、Java 用のコア エンジンを構築でき、それを使用したい Java 開発者を断る必要がなくなります。

Sun が C# コンパイラを提供しない技術的な理由を尋ねているわけではありません。Java にはプロパティがない、または符号なしの 64 ビット長などがあることを認識しています...議論のために、これらの技術的な問題はすべて、JVM および/またはその他の手段を拡張することで対処できると仮定してください。

そして、ある言語/スタックが他の言語よりも優れている理由について、さらに別の議論を求めているわけではありません。私たちのビジネスの現実は、それぞれを使用している潜在的な顧客がたくさんいるということです.

Sun が C# コンパイラを使用する理由 （もちろんIMO）

Java プラットフォームでの C# コードの実行が容易になるということは、プラットフォームの開発者とソフトウェアが増えることを意味します。プラットフォームの成功にとって、これ以上に重要なことはありますか? Jonathan Schwartzはソフトウェアの専門家です。彼が Sun の社長兼 CEO として不可能な仕事を引き受けたかどうかの判断は、私より賢明な他の人に任せますが、Jonathan が Sun に入社してすぐに会ったときの私の印象は、彼はソフトウェアと大規模なソフトウェアの必要性を理解しているということです。開発者のベース。

では、なぜ Sun は C# コンパイラを開発しないのでしょうか?

  1. NIH症候群？
  2. スコット・マクニーリーの幽霊？
  3. あまりにも多くの Java 開発者が Microsoft に関連するものを嫌い、または信用していませんか?
  4. 彼らは、大金を手にすることの一部ではないことに同意しましたか？
  5. ???

正当な理由があるはずです。私はそれが何であるかを一生理解することはできません...

4

18 に答える 18

10

http://jsc.sourceforge.net/は、(特に) .NET コードを Java に変換できる ac# クロス コンパイラです。

于 2009-06-17T10:28:34.393 に答える
3

正当な理由があるはずです。私はそれが何であるかを一生理解することはできません...

企業は、あなたの利益を心から考えている非営利団体であると信じがちです。上場企業の唯一の目的は、株主のためにお金を稼ぐことであることを忘れがちです。これは法的義務であり、株主がこれを怠ったと信じていない場合、取締役/幹部は解雇/訴えられています.

Sun が Java を無料にしたのは、Java から収益を上げているハードウェアの販売を支援するためです。IBM が Java を無料にしたのは、コンサルティングでより多くのお金を稼ぐのに役立つからです。

Sun が C# コンバーターにお金を使うとしたら、どのようにしてそのお金を回収し、利益を上げることができるでしょうか。Sun の株主を説得しなければならないと想像してみてください。可能であれば、Sun は C# コンバーターを作成します。

于 2009-03-29T10:35:35.617 に答える
3

Mono プロジェクトは、独自の仮想マシンをゼロから開発して維持するのではなく、JVM をターゲットにすることで、自分自身の作業を減らすことができたのではないかと思います。開発作業は、C# クロス コンパイラと、.NET ライブラリのクリーンルーム実装の JVM への移植に集中できたはずです。Mainsoft が行ったことのオープンソース バージョンのようなものです。次に、同じ JVM 内の Java と C# コード間の言語間呼び出しを有効にし、C# で記述されたアプレットと Java Web Start アプリケーションを展開できます。

于 2010-02-01T19:19:15.547 に答える
2

これがあなたが探しているものではないかもしれないことはわかっていますが、(あなたにとってそうでない場合) 他の人にとって役立つ可能性のある代替案をいくつか紹介します.

  1. C: 可能な限り C に移植できます。C# と Java (および C と通信できるその他の言語) でラッパーを作成して、プログラミング中にそれらの言語にネイティブに感じられるようにすることができます。ここでの問題は、あなた (またはライセンスによっては彼ら) が各プラットフォームの C 部分をビルドしなければならないことです。

  2. Fantom* : ホームページによると、次のようなプログラミング言語です。

    • 移植可能: Java VM、.NET CLR、および JavaScript に移植可能なコードをブラウザーで記述します。
    • 親しみやすい: 構文 Java および C# プログラマーは、Fantom の進化した構文に慣れ親しんでいます。
    • オブジェクト指向: すべてが Obj のサブクラスです。パフォーマンスが必要な場合の値型。
    • 機能的: 関数とクロージャが組み込まれています。
    • 静的型付けと動的型付け: 極端なことは好きではありません - 道の真ん中を選んでください。

  3. Haxe *: (hex と発音) は、他の言語にコンパイルできるクロスプラットフォーム言語です。まもなく C# と Java がサポートされる予定です。現在、以下をサポートしています。

    • Javascript: Haxe プログラムを単一の .js ファイルにコンパイルできます。型指定されたブラウザー DOM API にオートコンプリートをサポートしてアクセスでき、すべての依存関係はコンパイル時に解決されます。

    • Flash: Haxe プログラムを .swf ファイルにコンパイルできます。Haxe は、「古い」Flash 8 API または最新の AS3/Flash9+ API を使用する Flash Player 6 から 10 と互換性があります。Haxe は、Flash コンテンツを開発するための非常に優れたパフォーマンスと言語機能を提供します。

    • NekoVM: Haxe プログラムを NekoVM バイトコードにコンパイルできます。NekoVM は他の DLL で埋め込んだり拡張したりできるため、動的 Web ページ (Apache の mod_neko を使用) などのサーバー側プログラミングや、コマンドラインまたはデスクトップ アプリケーションにも使用できます。

    • PHP: Haxe プログラムを .php ファイルにコンパイルできます。これにより、既存のサーバー プラットフォームやライブラリとの完全な互換性を維持しながら、haXe などの高レベルの厳密に型指定された言語を使用できるようになります。

    • C++:必要な Makefile を使用して、Haxe ソース コードから C++ コードを生成できるようになりました。これは、iPhone 開発などのネイティブ アプリケーションの作成に非常に役立ちます。

    ハクセ コミュニティ。(2011 年 3 月 11 日)。ハクセの紹介。2011 年 1 月 29 日、http://old.haxe.org/doc/introから取得

    Haxe が役立つ理由については、こちらを参照してください。

*私はこの言語を使ったことがないので、これがどれほどうまく機能するかわかりません。

于 2012-01-30T03:15:23.960 に答える
1

私は本当に答えであるべきだったコメントをしました：

現時点では、JVM に C# 仕様を実装することは技術的に不可能です。C# は、ポインター、符号なし型、ユーザー定義の値型、真のジェネリック、参照渡し、およびその他の読み込みをサポートしています。非常に C# に似た JVM 言語については、Stabを確認してください。

メインソフトはそれを偽造します。彼らの多大な努力が必要だと確信しています。

于 2011-04-16T04:00:21.210 に答える
0

より良い質問は、C# から Java へのバイト コード コンパイラを作成しないのはなぜでしょうか(必要な場合)。大企業が何かをするのを待つのは悪い考えです。

このような実装を作成するための提案: Mono または .GNU の C# フロント エンドを使用します。わざわざ自分で書く必要はありません。

于 2009-06-23T02:20:14.507 に答える
0

クロスプラットフォームのクロス言語サポートのようなことをしている場合、言語は構文が似ているため、翻訳者を十分に簡単にすることができるため、「共通の API」を作成します。次に、Java または .net api をコアから直接呼び出す代わりに、必要な Java および .net api を再実装する「共通 api」を呼び出します。このようにして、必要に応じてクロスランゲージ サンドボックスを作成できます。Java と C# の主な違いはオブジェクト定義であるため、C# dll を反映してそれらを取得し、構成を再構築すると、インタープリターを実行して関数本体を実装し、プロパティをゲッター セッターに変換するのが簡単になります。ファイルの構造をすでに知っている。これはもちろん .net 2.0 を前提としており、3.0 および 3.5 の機能の一部は非常に難しくなります

それは複雑ですが、Java でコアを手作業で再構築し、2 つのチームが別々に作業する必要があるほど複雑ではありません。このアイデアが何らかのインスピレーションを引き起こしたら、私はそれを作成するかもしれません. Mac 用のよりシンプルで安定したモノラル インストールを実際に見てみたいと思います。

基本的に、共通の API クラスのセットに基づくコード レベルのインタープリターは、チームで 1 週間か 2 週間で作成できる可能性が非常に高いと思います。

于 2009-03-29T02:46:53.060 に答える
0

単純。Sun はむしろ Microsoft に訴えられたくないからです。私たちプログラマーは訴訟を起こす正当な理由を見つけられないかもしれませんが、Microsoft は Sun よりもかなり大きな会社であり、彼らを支配する力を持っていることを心に留めておいてください。

ただし、幸いなことに、Sun は Microsoft よりもかなりオープンな立場にあります。そのような需要があれば、オープン ソースまたはサード パーティがこのコンパイラを Java 用に作成でき、Sun は熱狂する必要はありません。

于 2009-03-29T11:38:36.417 に答える
0

JACILは、IKVM の逆を行おうとする明らかに死んでいるプロジェクトです。おそらく、やる気のある一部の人々は、実行可能な.NetからJVMへのコンパイラの出発点としてそれを使用できます.

于 2009-06-16T17:33:56.427 に答える