JVM用のC＃の実装

91

JVMにC＃を実装しようとしている人はいますか？Java開発者として、私はC＃を羨望の念を抱いて見つめてきましたが、JVMの移植性と成熟度を放棄するつもりはありません。JVMのためのさまざまなツールは言うまでもありません。

JVMとCLRの間にいくつかの重要な違いがあることは知っていますが、ショートッパーであるものはありますか？

c#  java  clr  jvm 
— ロブ
ソース
3
また、Javaで完全にマルチプラットフォームのアプリケーションを多数作成しました。これは、私と私のチームにとって日常的なことです。私たちは通常、正式に「認定」された各プラットフォームでテスト計画を実行しますが、テストのバグがプラットフォームの違いに起因するようになってから数年が経過したと思います。
— Jared、
1
当社の主力製品は、Windows、OS X、およびLinuxでそのまま実行されます。それは本当に難しいことではありません。
— するThorbjörnRavnアンデルセン
1
私はWindowsでJavaを実行します。男がOSXで彼の役割を果たしている場合、CIはLinuxですべてのテストを実行し、ソフトウェアをWindowsとLinuxの両方のサーバー、さらにはSolarisにも展開しました。だから私は、しばらくの間、本当に完全にマルチプラットフォームのJavaプログラムを書いてきたと言えるでしょう。
— Esko、
1
.NETで実装されたJavaVM。Java LIBSの.NET実装。両方の世界の相互運用性-> IKVM.NET（ikvm.net）
— gsscoder
1
...あなたは（JSILは、例えばこれを行います）JavaScriptに.NETに変換することができれば、あなたは、Javaに変換することができるはずと私には思える
— BrainSlugs83

回答:

93

CLRとJVMの間には非常に大きな違いがあります。

いくつかの例：

  • Javaにはユーザー定義の値タイプがありません
  • Javaジェネリックは.NETジェネリックとは完全に異なります
  • C＃の多くの側面は、フレームワークの要素（デリゲートなど）に依存しています。言語の側面であっても、ライブラリも移植する必要があります。
  • Javaは、JVMレベルのプロパティやイベントなどをサポートしていません。これの一部を偽造することもできますが、同じではありません。
  • JVMレベルであっても、Javaに参照渡しパラメーターに相当するものがあるとは思わない
  • C＃仕様にどれだけあるかはわかりませんが、さまざまなメモリモデルを処理するための微妙な問題が発生する可能性があります。
  • 安全でないコードは、おそらくJavaではおそらく不可能です
  • ネイティブコードとの相互運用性は、JNIとP / Invokeで大きく異なります。これはおそらくあなたにとってそれほど問題ではありません。
  • 偽の演算子のオーバーロードとユーザー定義の変換が必要になる

おそらく多くのC＃を移植できますが、IMOはかなり満足のいくエクスペリエンスが得られません。

逆に、あなたはIKVMを知っていますか？.NETでJavaコードを実行できます。

— ジョン・スキート
ソース
7
Javaにはファイナライザがあり、.NETファイナライズも確定的ではありません。2つの間に若干の微妙な違いがあるかもしれませんが、私はどんな手放しも考えられません。Javaの到達可能性テストは.NETよりも強力だと思います。別のスレッドがインスタンスメソッドを実行している間はファイナライズされません
— Jon Skeet
3
値型を参照型にマッピングできると思います。すべての割り当てに浅いクローンを作成させるだけです！
— Daniel Earwicker 2009年
3
@Earwicker：...配列の割り当てを変更し、セマンティクスが違いを生むさまざまな場所を変更しますか？私は疑われるだろう非常に、仕事にそれを得るのは難しい場合はそれが可能だ、との結果は、あなたが使用したいと思い何かではないでしょう。
— Jon Skeet、
4
ジェネリックも解決できると思います。型パラメーターのClassオブジェクトを保持するために追加のフィールドを含むJavaクラスを生成する必要があるため、オーバーヘッドが多少追加されますが、新しいT（）およびtypeof（T）を使用できます。
— Daniel Earwicker 2009年
30
@Jon Skeet：それはあなたに両方の世界の最悪を与えます：Microsoftの専有プラットフォーム上のJavaの幾分時代遅れの言語。
— Bart van Heukelom、2010
43

http://code.google.com/p/stab-languageにアクセスします

JVMのスタブ言語コードの場合、以下のコード

using java.lang;
using stab.query;
public class Test {
   public static void main(String[] args) {
   // Sorts the arguments starting with "-" by length and then using the default   
        // string comparison
        var query = from s in Query.asIterable(args)
                    where s.startsWith("-")
                    orderby s.length(), s
                    select s;
        foreach (var s in query) {
            System.out.println(s);
        }
    }
}
— Vns
ソース
7
stabは、JVMでC＃言語の主要部分の多くを提供しますが、Javaと非常に相互運用可能な方法で提供します。そのため、.NET CLR用に作成されたC＃コードと完全に互換性のあるソースコードではありませんが、Javaプログラマーは、非常にC＃に似た言語を享受しながら、同じ品質のバイトコードを生成し、Javaライブラリーおよびフレームワークとの非インピーダンス相互運用性を実現できます。これは、JVMでC＃を取得するための適切なアプローチです。
— RogerV 2010
良い言語、良いプラットフォームで...私がこの数年前に遭遇したいのですが。
— Jefferey Cave 2014
14

バイトコードトランスパイラー

GrasshopperはCLRバイトコードを取得して、JVM用にトランスパイルできます。主にWebアプリを対象としており、WindowsフォームクラスのJVM実装などは提供していません。ただし、多少日付が古いようです。WebはASP.NET 2.0、Visual Studio 2008などについて話します。@alexによって最初に言及されました

XMLVMは、CLRまたはJVMバイトコードを入力として受け取り、出力として生成できます。さらに、JavascriptまたはObjective-Cを出力できます。まだリリースはなく、Subversionのみです。「実稼働環境では使用されない実験的開発バージョン。」

IKVMはOPが望む方向とは逆の方向に進みます。これは、CLRで実行されるJVM実装、JVMからCLRへのバイトコードトランスパイラー、およびJava用のCLRライブラリメソッドスタブジェネレーターを提供します。http://www.ikvm.net/uses.html @Jon Skeetによる言及

RPC

CLRとJVMを一緒に実行して、通信を可能な限りスムーズにしないのはなぜですか？これはOPが望んでいることではありませんが、他のいくつかの回答はさまざまな方法ですでにかなり話題から外れているので、それをカバーしましょう。

RabbitMQには無料のオプションがあり、C＃、JavaなどのAPIライブラリを備えたErlangで記述されたRPCサーバーです。

jnBridgeは、一部の見込みユーザーにとってライセンスが高すぎる可能性があります。

gRPCおよび同様の最新のRPCライブラリは、幅広い言語サポート、これらの言語でのクライアントライブラリのコード生成、データ用の言語非依存のワイヤ形式、カスケードコールキャンセルなどの高度な機能を提供します。

プログラミング言語

一度書いて、どこでも実行;）

Haxe、C＃/ CLR、Java / JVM、Javascript、Flash、Pythonなどにコンパイルして、各ターゲット言語の相互運用メカニズムを提供します。ある程度ActionScript3の後継と考えることができます。少なくとも1つの会社が実際にそれに依存している、かなり堅実なもののようです。次に説明するStabよりもはるかに信頼できる。

StabはいくつかのC＃機能とJavaの相互運用性をもたらします。あまり役に立ちませんが、いくつかのC＃機能を利用できますが、やり取りするのはそれらを使用しないJavaコードです。https://softwareengineering.stackexchange.com/a/132080/45826言語は比較的あいまいで、おそらく見捨てられ、改善される見込みはほとんどありません。ここで最初に@Vnsによって言及されました。

JVMプラットフォームの新鮮な空気の突風;）

Scala、Kotlin、その他は、JVM上で実行されるかなり良い言語であり、C＃プログラマーがJavaで見逃す可能性のある機能をもたらします。特にKotlinは、JVMの世界ではC＃の合理的な代替手段のように感じられます。Scalaは、プログラマーが短時間で慣れるには少し大きすぎる言語かもしれません。

単核症

それも確かにオプションです。Monoがそのまま実行できるのに、なぜJVMにトランスパイルするのか。@ferhrosaが最初に言及

ニューヨーク— 2014年11月12日 —水曜日、Microsoft Corp.は、サーバーサイドの.NETスタック全体をオープンソース化し、.NETを拡張してLinuxおよびMac OSプラットフォームで実行できるようにすることで、クロスプラットフォームの開発者エクスペリエンスへの取り組みを強化しました。

引用元となったこのプレスリリースによると、Visual Studio 2015はサポートされているプラ​​ットフォームとしてLinux / Monoを追加します。

これは、Monoプロジェクトの人々が反対側から書いたブログです。.NETソースコードの統合（2014年11月）。

.NET Core

Microsoftが管理する.Net（の一部）のWindows / Linuxマルチプラットフォームバージョン。'nuffはhttps://github.com/dotnet/coreと述べました。

結論

これらのツール/フレームワークを試して、どの程度の摩擦があるかを確認する必要があります。OPは、実際にはGrasshopperを使用すると非常にうまく機能するJVM用のC＃で記述したいと考えています。

C＃とJavaのワールドライブラリを単一のコードベースに混在させることを目的としてこれを行うと、うまく機能しない場合があります。

出典

http://blog.pluralsight.com/new-course-making-java-and-c-work-together-jvm-and-net-clr-interop

— user7610
ソース
正解です。Javaへの移行の必要性に不満があり（プロパティなしでどのように生活できるか？！）、Scalaに疑問があるC＃開発者として、これは本当にオプションをうまくレイアウトします。
— Gilthans、2015年
9

ILからバイトコードへのコンバーターを書く方が簡単かもしれません。そうすれば、JVM上の.NET言語のサポートが自動的に得られます。

ただし、これは非常に明白なアイデアであり、これがまだ行われていない場合は、おそらく非常に困難であるか、十分に/効果的に行うことが困難です。

— ダニエル・アーウィッカー
ソース
6
あなたは私がリストした問題のほとんどに出くわすでしょう-異なるジェネリックなど
— Jon Skeet
8
これはまさにGrasshopperが行うこと（上記の@alexの回答を参照）であり、実際にうまく実行することは非常に困難です（以前はGrasshopperで作業していました）。
— Motti
7

Grasshopperを見てください。これはVisual StudioベースのSDKであり、Linux®およびその他のJava対応プラットフォームで.NET Webおよびサーバーアプリケーションを実行できるようにする特許取得済みの.NETからJavaへのコンバーターです。

— アレックス
ソース
2
実践的な経験はありますか？また、ライセンスは無料版のdraconicであることに注意してください。
— するThorbjörnRavnアンデルセン
13
「特許取得済み」という言葉を言った瞬間、あなたは私の興味を失いました。はぁ。
— スティーブンC
2
ほんの一部のニュース：Grasshopperは無料で、ほとんどのオープンソース製品と同様に、サポートと保証はありません。
— fernacolo
1
Mainsoftは完全に停止しているようで、Grasshopperリンクは機能しなくなります。
— デビッド・ギヴン
1
その時は明らかです。現在、両方のリンクが機能しています。残念ながら、なぜ私はそれが欲しかったのか思い出せません...
— デビッド・ギヴン
0

この答えは遅いかもしれませんが、これは新しいものです。Kotlinプログラミング言語をチェックアウトすることもできます。Java以外のJVM言語を除いて、C＃が持つ構文糖と、C＃構文に最も近い糖を提供します。そのJetBrainsから。

— LEMUEL ADANE
ソース
0

これがあまり熱狂的でない理由は2つあります。

言語の実際の機能に関して言えば、C＃とJavaは非常に近いということを最初に理解する必要があります。C＃とJavaは近いだけでなく、同様の方向に向かっています。JVMがそのままではサポートしていない機能がいくつかありますが、それは本当の問題ではありません。不足しているものはいつでも偽造できます。Almost-Javaをゼロから作成するよりも、Javaが砂糖を手に入れるのを待つ方が好きだと思います。移植の準備ができるまでに、Javaは追いつくことに決めているかもしれません。

第2に、開発者がC＃を好む理由は、言語そのものではなく、その周辺のツール、C＃との双方向の関係、およびMicrosoftがすべてをサポートする方法にあります。たとえば、C＃とXAMLは互いにハッキングされているため（たとえば、C＃の部分クラス、XAMLのバインディングなど）、C＃-XAMLコンボはJavaFXよりも使いやすいです。JavaFXでC＃を使用しても、それほど改善されません。JVMでC＃エクスペリエンスを得るには、ツールも移植する必要がありますが、これははるかに大きなプロジェクトです。モノでもない気になり。

だから、慣れ親しんだツールの上でより洗練された言語を使用したいJava開発者への私のアドバイスは、既存のJVM言語をチェックすることです。

Monoもオプションですが、私は常にそれについて懐疑的でした。C＃-。NETであり、クロスプラットフォームですが、Microsoftのツールで構築されたものは、通常Monoでは機能しません。それは本質的に独自のものです。マイクロソフトが協力すると発表したことで、今何が起こるかがわかります。

— クリス
ソース
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.