.NET / JavaのMono？ 簡単！

こんにちは。 私のプロジェクト-Javaの.NET / Monoコンパイラーを紹介します。 プロジェクトの目的は、コンパイラ、および記述されたアプリケーションとライブラリをJavaプラットフォームバージョン1.6以降に転送できるようにする一連の標準ライブラリを作成することです。 同様のプロジェクトのうち、私はdot42プロジェクトのみを知っています。 しかし、Androidに収監されており、.NET / Monoと完全に互換性のない独自の標準ライブラリがあります。



これまでのところ、アルファ版のみが存在するため、コンパイラは実際の使用には適していませんが、部分的に動作し、有効なJavaコードを生成し、ECMA-335標準の一部をサポートします。



github.comのソースコード： https : //github.com/zebraxxl/CIL2Java





コンパイラは、パラメータなしで起動するとヘルプを表示するコンソールアプリケーションです。 したがって、問題を使用しても発生しないはずです。



また、作業中、コンパイラは、入力時に送信されたすべてのコードが有効であるという仮定から進むことに注意してください。

サポートされていないもの

すぐに、現時点ではサポートされていないことを明記します。

• アンマネージポインター
• ポインター上の数学（マネージドとアンマネージドの両方）
• P /呼び出す
• 非ベクトル配列（下限が0でない配列）
• long型のswitchステートメント
• オペコードカリ
• 例外フィルター

最後の3つのポイントは、近い将来、残りを犠牲にして実装される予定です。これらは、実装可能な場合は長期計画です。

仕組み

コンパイルは3つの大きな段階に分かれています。 最初のステップで、コンパイラは使用されるすべての型をロードし、内部表現に変換します。 2番目は、3番目の段階の準備です。 3番目の段階では、メタ情報を変換し、コードをコンパイルします。



型の内部表現への変換は、ロード中にその場で行われます。 つまり、型が取得され、内部表現に変換されてから、コンパイルリストに追加されます。 次に、すべてのフィールドとメソッドが元の型から取得され、内部表現に変換されます。 したがって、入力アセンブリとして明示的に指定されたすべての型、それらのフィールド、およびメソッドがコンパイルリストに追加されます。



ただし、型、フィールド、またはメソッド（以降、メンバーと呼びます）の変換時にもロードされ、内部表現に変換され、コンパイルリストに追加されます。元のメンバーが依存するすべてのメンバー。 実際に使用されるメンバーのみが追加されます。 したがって、コンパイルリストの最初の段階の後は、ソースアセンブリにある型だけに加えて、必要な型とそのメンバーが存在します。 これにより、出力ではコンパイル済みのソースアセンブリと残りの必要な部分が取得されます。 たとえば、次のコードを使用します。

using System; namespace TestConsole { public class Program { public static void Main(string[] args) { Console.WriteLine("Hello world"); } //    Java public static void main(string[] args) { Main(args); } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初のステップの後、コンパイルリストは次のようになります。

 0：Foo.Programと入力
    メソッド：
        メイン
        メイン
 1：タイプSystem.Console
    メソッド：
        ライトライン
 2：System.Stringと入力します

また、アセンブリを交換するメカニズムについても注意する必要があります。 外部アセンブリ（入力として指定されていない）にある型への参照が見つかった場合、このアセンブリは自動的に読み込まれます。 ただし、ロードされたアセンブリにJavaと互換性のない実装がある場合はどうなりますか？ たとえば、標準のmscorlib？ このためには、アセンブリを置き換えるメカニズムが必要です。 現時点では、現時点では、mscorlibは、Javaメカニズムを使用して動作する特別な実装に置き換えられています。 また、-rコンパイルキーを使用して、他のアセンブリを指定することもできます。 つまり、Mono.Cecilがアセンブリのダウンロード先を探し始めると、この問題をAssemblyResolverに対処します。AssemblyResolverは、元のアセンブリを読み取るときにパラメータとして渡されました。 コンパイラのAssemblyResolverは、以前にロードされたアセンブリで同じ名前のアセンブリを最初に検索し、見つからない場合はリストで置換を検索します。 存在する場合は、リストに示されているアセンブリをロードしてスプーフィング用に返します。 ただし、置換リストにない場合は、標準的な方法で標準アセンブリがロードされます。



2番目のコンパイル段階の前に、プリコンパイル段階が行われます。この段階では、コンパイラは追加の型処理を実行して、直接コンパイルの準備をします。 たとえば、この段階で、どこでも明示的に呼び出されないメソッドが追加されますが、明示的に使用されるメソッドの仮想メソッドがオーバーロードされます。



そして実際には、第三段階が最も基本的です。 メタ情報の変換は、かなり単純で理解可能なプロセスです。 私が注意したい唯一のことは、JavaとCILの可視性レベルの非互換性のために、すべての型が結果としてパブリックアクセスで宣言されることです。 Javaのグローバルタイプには、パブリックアクセスまたはパッケージ（名前空間）からのみアクセスできます。 また、Javaのネストされた型は、たとえば閉じたレベルの可視性を持ち、それらが宣言されている型の外側ではまったく使用できません。 外部クラスからこのタイプのメンバーをアドレス指定すると、例外がスローされます。 したがって、すべてのタイプが自動的にオープンになります。



ただし、コードのコンパイルはより複雑で時間がかかるプロセスであり、これもいくつかの段階に分割されます。 最初のステップは、コードグラフを作成することです。 これは、ILSpyのICSharpCode.Decompilerライブラリによって行われます。 一般に、グラフはほとんどコンパイルの準備ができていますが、それでもいくつかの追加の変換が実行されます。 たとえば、ICSharpCode.Decompilerによって生成された擬似CompoundAssignment命令は逆変換されます。 さて、その後、Javaバイトコードが実際にコンパイルされます。



これがコンパイラの仕組みです。 次に、作業のいくつかの側面と、特定のサポートを実装する方法について詳しく説明します。

ジェネリック

JVMの観点からは、ジェネリックは存在しません。 Javaのジェネリックは単なるコンパイラ拡張機能であり、JVMの観点からのジェネリックはjava.lang.Objectのような通常のオブジェクトです。 CLIのジェネリックは実行時にコンパイルされます。 これは、コンパイラがジェネリックに遭遇すると、実際の型を代わりに置き換え、実際には、元の型またはメソッドに基づいて新しい型またはメソッドを作成することを意味します。 CIL2Javaは同じ方法で動作し、jerickパラメーターを持つメソッドと型をスキップし、これらのパラメーターを置き換える型を示すリンクが見つかった場合にのみそれらを作成します。

重要なタイプ

これはおそらく、.NET / Monoが紛争においてJavaよりも優れている主な理由の1つです。 はい、Javaはこれらのタイプをサポートしていません。 したがって、すべての重要な型はポインター型としてコンパイルされます。 ただし、重要な型とポインター型の動作の違いによる問題はないため、重要な型の動作はエミュレートされます。 最初に、パラメーターなしのコンストラクターが生成され、3つの内部メソッドが追加されます。

• c2j __ $ __ ZeroFill（）-型の内容をゼロで埋めます
• c2j __ $ __ CopyTo（ValueType）-ソースタイプの内容を指定された場所にコピーします
• c2j __ $ __ GetCopy（）-型の新しいインスタンスを作成し、元のデータをそこにコピーします

これら3つの方法を使用すると、重要なタイプの動作が完全にエミュレートされます。 たとえば、コード「Foo（valType）;」は「Foo（valType.c2j __ $ __ GetCopy（））;」に変換され、valTypeのコピーがFooメソッドに渡されます。



また、正しい操作のために、すべての重要な型は、コンストラクターのデフォルトのコンストラクターおよびメソッドの最初（プロローグ）で自動的に初期化されます。



したがって、これらのタイプの主な利点は、正しく使用するとアプリケーションの速度が向上することです。失われるだけでなく、逆に使用するとアプリケーションの速度が低下します。

乗り換え

.NET / Monoでは、列挙は本質的に意味のある型ですが、追加の制限があります。 メソッドには、「value__」という名前のプリミティブ型（int、shortなど）の1つの非静的フィールドと、列挙自体の型の静的フィールドのみを含めることはできません。



列挙型の代わりに、コンパイル時にその基本型が置換されます。 つまり、コンパイル後のメソッド「void Foo（EnumType val）;」は「void Foo（int val）;」になります。

パッキング

重要なタイプのパッケージ化は、プリミティブタイプのパッケージ化、重要なタイプのパッケージ化、リストのパッケージ化の3つのカテゴリに分類されます。



プリミティブ型のパッケージ化は、CIL型へのパッケージ化またはJava型へのパッケージ化の2つの方法で実装されます。 最初のケースでは、System名前空間のCILの標準タイプ（System.Int32、System.Singleなど）がパッケージ化のタイプとして使用されます。 2番目-Javaの標準タイプ（java.lang.Integer、java.lang.Floatなど）



CIL型にパッケージ化する場合、符号なしの型に関する情報を保存し、「uintType.ToString（）」という形式のコードが正しい結果になります。 ただし、このようなパラメーターをJavaに、パックされたプリミティブ型（java.lang.reflect.Method.invokeなど）を渡すメソッドに渡す場合、コンパイラーは再パッケージ化コードを生成する必要があります（ただし、この関数は現時点ではコンパイラーにありません）パフォーマンスを落とします。



Java型でパッケージ化する場合、逆のことが当てはまります。 uintType値が2 147 483 647を超える場合、コード「uintType.ToString（）」は誤った結果を返しますが、CILからJavaへ、またはその逆への不必要な再パッケージ化はありません。 どの方法を適用するかはあなた次第です。 コンパイルパラメータボックスがこれを担当します。 デフォルトでは、パッケージ化はCILタイプで行われます。



重要なタイプのパッケージ化により、すべてがよりシンプルになります。 型のコピーを取り、そのまま渡します。 実際には、コンパイル後、ポインタ型になります。



しかし、リストは真のタイプでパックされています。 つまり、ベース型intを持つEnumType型の列挙がある場合、上記のように、コンパイル時にEnumTypeの代わりにint型が置換されます。 ただし、パッケージ化の場合は、EnumType型のオブジェクトが作成され、この列挙の値がそのvalue__フィールドに入れられます。 したがって、タイプ情報が保存されます。

ポインタ

既に述べたように、コンパイラは安全でないポインターをサポートしていません。 しかし、リンク転送は非常にうまく機能します。 値が参照によってメソッドに渡される場合、このパラメーターの型はCIL2Java.VES.ByRef [type]型になります。[type]はリンクが作成される型です（可能な値：Byte、Short、Int、Long、Float、Double、 Bool、Char、Ref）。 呼び出しごとにそれらをパック/アンパックしないために、プリミティブ型の個別の型が必要です。 リンクタイプ自体は、参照による値の取得と設定をそれぞれ行うget_Valueとset_Valueの2つの抽象メソッドを持つ抽象クラスです。 これはどのように見えるかです：

 public abstract class ByRef[type] { public abstract [type] get_Value(); public abstract void set_Value([type] newValue); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

値への参照を作成すると、対応する抽象クラスを実装するオブジェクトが作成されます。 そして、リンクの作成先の値が保存されている場所に応じて実装します。



LocalByRef [type]-ローカル変数またはメソッドパラメーターへの参照。 呼び出された場所を出るまで値を保存し、その後変数またはパラメータの値が復元されます。

次のコードを取得します。

 public class Program { public static void Foo(ref int refValue) { refValue = 10; } public static void Main(string[] args) { int localVar = 0; Foo(ref localVar); } //    Java public static void main(string[] args) { Main(args); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コンパイル後、コードは次のようになります。

 public class LocalByRefInt : ByRefInt { private int value; public LocalByRefInt(int initialValue) { value = initialValue; } public override int get_Value() { return value; } public override void set_Value(int newValue) { value = newValue; } } public class Program { public static void Foo(ByRefInt refValue) { refValue.set_Value(10); } public static void Main(string[] args) { int localVar = 0; LocalByRefInt tmpByRef = new LocalByRefInt(localVar); Foo(tmpByRef); localVar = tmpByRef.get_Value(); } //    Java public static void main(string[] args) { Main(args); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

FieldByRef [type]-オブジェクトのフィールドへの参照。 それは反射の力によって実現されます。 コンパイル後、このタイプは次のようになります。

 public class FieldByRef[type] : ByRef[type] { private object target; private java.lang.reflect.Field field; private [type] value; public FieldByRefInt(object target, Field targetField) { this.target = target; this.field = targetField; paramField.setAccessible(true); this.value = targetField.get[type](target); } public [type] get_Value() { return this.value; } public void set_Value([type] newValue) { this.field.set[type](this.target, newValue); this.value = newValue; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ArrayByRef [type]-配列要素への参照。 ここではすべてが簡単です。配列自体（ポインター型）とこの配列のインデックスを保存します。 コンパイル後の外観は次のとおりです。

 public class ArrayByRef[type] : ByRef[type] { private [type][] array; private int index; private int value; public ArrayByRefInt([type][] paramArray, int index) { this.array = paramArray; this.index = index; this.value = paramArray[index]; } public int get_Value() { return this.value; } public void set_Value(int newValue) { this.array[this.index] = newValue; this.value = newValue; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

メソッドとデリゲートへのポインター

これは私がJavaで最も見逃しているものです。 メソッドポインターを実装する1つの方法は、リフレクションです。 ただし、パラメーターをパッケージ化する必要があるため、パフォーマンスが低下するため、このオプションは好きではありませんでした。 したがって、2番目の方法が使用されました。



次の説明では、この例を使用します。

 using System; namespace TestConsole { public delegate void Deleg(int f); public class Program { public void Foo(int f) { Console.WriteLine(f); } public static void Main(string[] args) { Program p = new Program(); Deleg d = new Deleg(p.Foo); d(10); } //    Java public static void main(string[] args) { Main(args); } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

メソッドは、ldftnまたはldvirtftn命令が検出されると、最初にCIL2Java.VES.MethodPointers名前空間に、メソッドシグネチャに依存する名前と、メソッドとほぼ同じシグネチャを持つ単一のinvokeメソッドを使用してインターフェイスが生成されるというものです。最初のパラメーターに、メソッドを呼び出す必要があるオブジェクトへのリンクを追加することにより、ポインターを取得します。 この例では、このようなインターフェイスは次のようになります。

 public interface __void_int { void invoke(object target, int param); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、各ldftnまたはldvirtftn命令は、メソッドポインターインターフェイスを実装するネストされた型を生成します。 invokeメソッドは、単に命令がポインターを受け取るメソッドを呼び出します。 上記の例では、次のようになります。

 public class C2J_anon_0 : __void_int { public void invoke(object target, int paramInt) { ((Program)target).Foo(paramInt); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、すでにデリゲートコンストラクターでは、このクラスのインスタンスがメソッドへのポインターとして渡されます。



コンパイル後、デリゲートは次の形式を取ります。

 public sealed class Deleg : MulticastDelegate { public Deleg(object target, __void_int method_pointer) : super(paramObject, method_pointer) { } public sealed void Invoke(int paramInt) { ((__void_int)this.method).invoke(this.target, paramInt); if (this.next != null) ((Deleg)this.next).Invoke(paramInt); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、コンパイラのデフォルトの動作です。 ご覧のとおり、デリゲートコンストラクターのシグネチャが変更されています。最後のパラメーターは、標準で必要なネイティブintではなく、メソッドポインターのインターフェイスタイプです。 これは最適化のために再度行われます。 ただし、「-method_pointers standart」パラメーターを使用すると、標準に従ってメソッドポインターをコンパイルするようにコンパイラーに指示できます。 この場合、この例のデリゲートの作成は次の形式を取ります。

 Deleg d = new Deleg(p, Global.AddMethodPointer("TestConsole.Program$C2J_anon_0"));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、デリゲート自身は次のようになります。

 public sealed class Deleg : MulticastDelegate { public Deleg(object target, int paramInt) : base(target, Integer.valueOf(paramInt)); { } public sealed void Invoke(int paramInt) { ((__void_int)Global.GetMethodPointer(((Integer)this.method).intValue())).invoke(this.target, paramInt); if (this.next != null) ((Deleg)this.next).Invoke(paramInt); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、この場合、メソッドポインターはint型ですが、実際には、これはメソッドポインターのグローバルリストの単なるインデックスです。 このようにして、標準に準拠しますが、パフォーマンスが低下します。

利回りリターン/ブレーク

正直に言うことはありません。 それだけで動作します。

非同期/待機

特別なこともありません。 async / awaitを使用したコードはコンパイルされますが、機能しません。 操作に必要なタイプ（System.Threading.Tasks.Task、System.Runtime.CompilerServices.AsyncTaskMethodBuilderなど）の実装がないため、機能しません。

符号なしの数字

コンパイラで符号なしの数値をサポートできますが、「-unsigned」パラメーターによって個別に含まれます。 elw00dの原作者に関する記事http://habrahabr.ru/post/225901/は、 実装に本当に役立ちました。 一般に、この記事ではすべてについて説明し、符号なしの数字を使用したすべての操作はこの記事で行われました。

例外

一般に、JavaとCILの例外は非常に似ています。 例外フィルターはサポートされていません（ICSharpCode.Decompilerはそれらをサポートしていません）。



さらに、JavaとCILの例外タイプをリンクするメカニズムが追加されました。 たとえば、CILにはSystem.ArithmeticException例外があります。 Javaには独自のタイプjava.lang.ArithmeticExceptionがあります。 System.ArithmeticExceptionのキャッチがjava.lang.ArithmeticExceptionと同じ方法でキャッチされることを確認する方法は？ これを行うために、Javaで同様の例外をコンパイラーに伝えるJavaExceptionMapAttribute属性が導入されます。 また、コンパイラはSystem.ArithmeticExceptionキャッチを検出すると、同様のJava例外にキャッチを追加します。 追加される唯一の条件は、同じタイプの例外のインスタンスがインターセプターに渡されるように、java.lang.ArithmeticExceptionタイプのパラメーターを1つだけ受け入れるSystem.ArithmeticExceptionに追加のコンストラクターを導入する必要があることです。

デバッグ

コンパイラは、-debugコンパイルキーを指定するときに、デバッグ情報の生成をサポートします（ソースアセンブリにある場合）。 Eclipseでテストアプリケーションをデバッグする方法の例を次に示します。

型置換

このメカニズムは、Javaで同様の型を持つ型をコンパイル中にこれらの同じ類似体に変換できるように作成されました。 このタイプの例はSystem.Stringです。 mscorlib実装では、この型はTypeMapAttribute属性でマークされ、コンパイル時にjava.lang.Stringに変わります。 個々のメソッドの置換も可能です。 これを行うには、MethodMapAttribute属性でマークする必要があります。

おわりに

それだけです。 これはプロジェクトのアルファ版にすぎず、作業の安定性はこれまでのところ不十分です。 したがって、さらなる作業のベクトルは、安定性の向上と標準ライブラリの実装です。 最後まで読んでくれてありがとう。