4

現在のプロジェクトでは、IKVM を使用して、XML のさまざまな側面を処理するいくつかの Java ライブラリをクロスコンパイルしています。これらのライブラリは、いくつかの .NET ライブラリとメインライン コードに統合されます。すべてが正常に機能しますが、特にストリームベースのデータ アクセスの領域で、いくつかの非効率性があると思われます。

Java ライブラリの多くは、ストリーミング SAX クラスや、OutputStream などの他のストリーミング オブジェクトを受け入れることができます。場合によっては、対応する .NET サブクラスで適切な Java クラスをラップして、ギャップを埋め、2 つの言語間のシームレスなストリーミングを提供できます。たとえば、.NET MemoryStream と Java OutputStream の両方から派生するクラスを作成します。ただし、ほとんどの場合、インターフェイスは難しく、.NET 側で利用可能なストリームがあり、Java 側が (異なる) ストリーム クラスを受け入れる (逆の場合もある) にもかかわらず、文字列全体を渡す必要があります。

一般的に私の質問は、ストリームを使用して IKVM でコンパイルされたライブラリとの間でデータをやり取りする際に同様の問題に遭遇した人がいるかどうかと、それらがどのように解決または軽減されたかということです。このギャップを埋めるサードパーティのソリューションはありますか? たとえば、.NET XmlReader や XmlWriter の Java SAX ラッパーを提供するコードは非常に便利です。

4

1 に答える 1

4

私はSaxonでこの種のことのためにいくつかの橋渡しクラスを行いました。オープンソースなので、便利だと思うものは何でも再利用できます。ただし、Saxon の使用方法以外の方法で使用した場合、それらが完全で正しいことを保証するものではありません。

DotNetInputStreamは、.NET ストリームを Java InputStream にマップします。

DotNetOutputStreamは、.NET ストリームを Java OutputStream にマップします。

DotNetReaderは、.NET TextReader を Java Reader にマップします。

DotNetWriterは、.NET TextWriter を Java Writer にマップします。

XML ストリームの場合、Saxon には独自の内部プッシュ/プル インターフェイス (それぞれ Receiver と PullProvider) があり、これらの両方を対応する Java および .NET インターフェイスとの間でマッピングするクラスがあります。

于 2011-07-06T15:12:26.800 に答える