代替困難 - Kazzz's diary

現状判っている、.NETからJavaへの移植で困難になるだろうと思っているのは以下の2点。

プロセス間通信
クライアントデータ(オブジェクト)の共有

いずれもプロセス間での話なのでJavaの場合はJVM間ということになる。
実装してもいないのに困っているというのも変なのだが、.NETでは上の二つはそれぞれ

WM_COPYDATAによるウインドウ間におけるメッセージの授受とシリアライズ
.NET Remotingによるシステム・シングルトンオブジェクト

いずれもプラットホーム特有の技術で実装しているのであり、Javaで実装するには0からその方式を考え直さなくてはならない。

プロセス間通信

過去に試した方法としては、JNIでプラットホーム上にアロケートされた連続したメモリ領域をByteBufferでマップするというものだったが、今回はクライアントアプリ(JWSで配布することも考慮している)であることを考えるとJNIを使うという時点でNGだ。プラットホーム毎にバイナリを用意しなくてはならないのも嫌だしな。使ったことがある人は判ると思うが、とにかくJNIは面倒なのだ。
比較的楽に実装できるのはソケットだが、セキュリティにうるさい昨今では適当なポート範囲をクライアントアプリケーションに割くことは皆嫌がることだろう。
JavaはいつになったらUNIXの偉大な資産であるIPCの手段(シグナル、パイプ等)が使えるようになるんだろう。

クライアントデータ(オブジェクト)の共有

Javaには元々RMIという立派な仕組みがあるんだが、rmiregistryというリポジトリの常駐が必要なこと、(対して.NET Remotingは特別なインフラやリポジトリは必要とせずに配置されたオブジェクトは生き続けることができる)いちいちrmicによりスタブ・スケルトン(スケルトンは1.2の時点で不要になった)のコンパイルが必要なことは、10年前であれば我慢できたが今となっては使いたくないのが本音だ。※
最新の仕様ということであればjcacheになるのだろうが、クライアントアプリケーションに使うには大げさ過ぎて使う気にならない。
こちらもNIOを使ってファイルをMappedByteBufferでマップする手もあるが、相手がファイルだと読み込みは良いが更新とその通知が面倒だ。

これら二つの機能に関しては、現状これという決定的な方式が見つかっていない状況だ。

追記
※J2SE5以降はスタブの生成も不要になった。JavaTM RMI リリースノート - JavaTM SE Development Kit (JDK) 6 の拡張機能
あとは、rmiregistryも不要になればいいんだけどなぁ。