電子政府が使えない理由、縦割りの弊害？JREの弊害？
JREがバージョンごとに少なからず振る舞いが異なっていて、アップデートにちゃんと対応するのが大変だね、という話。って書くとあんまし面白みが無いので、もう少し。
本件の場合
XML Signature実装って、この電子政府ソリューションが始まった頃はまだまだフロンティアで、とてもバージョン間互換性が期待できたものではなかったように思う。
JREの問題と言える部分があるとしたら、それはsecurity fixを別途リリースするという形にしていないという一点だけであろう（これとは関連するようで関連しない「脆弱なバージョンが残る」問題もあるけど）。そして、それは.NETも（もちろんMonoも）同じである。versioning hellが起こるのはJREだけではない。以前書いた通り、.NET も、期間内件数としてTigerと同程度の変更を加えているのだから、どちらかと言えばSunの方が真摯にアップデートを提供することによって、問題が「隠されていない」のである。
MS.NETのversioning hell
.NET 2.0では1.1でクロスバージョンなアセンブリ生成が出来ないし、1.0でビルドしたアプリケーションの多くが1.xで動作せず、さらにはSecurity Fixと同程度の内容であるべきService Packの適用状態によって動作が変わる*1。protectedがpublicになっただけで動かなくなる。*2 *3
おそらくその原因は、信頼してはいけないSystem.Runtime.Serialization依存（回避可能）とか、member signaturesの変更（回避不可）とかだろう。これは開発者の問題にすることはできないし、フレームワーク実装者の問題でもない。
side by sideはcoolな提案だったし、僕は嫌いではないが、異なるバージョン間でのdispatchの設計には（少なくとも.NET 2.0までの時点では）失敗した。同一のバージョンを前提としたランタイムの自動選択機能が残った。それはほとんど並列にインストールされたJVMと実質的にあまり違いが無い。exeを直接実行するか、batなりshなり何なりを叩くかの違いだ。
.NETがせめてJava程度にインターフェース指向のフレームワークであったなら、これらの問題の多くが回避できたかもしれないが、interfaceでない型を使わないことは不可能なので、結局はJavaで起こっていることと同レベルの問題は起きていたことだろう。Javaではなく.NETで同じような開発が行われていたら、問題はさらに悲惨なものだったであろう。
Monoの場合
Monoの問題はもっと悲惨である。僕らはAPIの誤差を随時修正してMSに合わせている。可能な場合はMSとのserialization compatibilityを実現する。つまり、シリアライズされたメンバーを見て、同じ構成になるようにフィールド名を書き換える*4。これによって、むしろそれ以前のMonoとの間で、互換性が失われる*5。
serialization compatibilityは機械的な作業ではないので、僕はもう諦めた方が良いと思っている。一方でMonoコミュニティにはMS互換原理主義者が少なからずいて、（特に他人の）時間を無駄にするな・させるなという立ち位置の僕とはしばし衝突する。最近はそうでもないか。*6 *7
結論
…というわけで、strongly-strongly-typedな言語を使うのも良いが、素直にstatic linkedなC(++)を使ったり、インタープリタ言語でコーディングしてしまった方が良い側面も多いだろう。この手のソフトのうち、パフォーマンスが大きな問題になるプログラムがどれほどあるか、という話もある。
別にJavaや.NETのソリューションを否定しているわけではない。GroovyやBooを使えば良い。
何か同じ話を何度も書いているような気がしてきたのでこの辺でsage
*1:我々はcorcompareでMS.NETアセンブリとMonoアセンブリのmember signaturesの違いをチェックしているので、MSがSPを出すたびにpublicメンバーが変更されていることを知っている
*2:.NETみたいに厳密にメンバー定義の同一性を要求するdynamic linkingに依存する言語には、同じような問題をかかえたものがあるかもしれない。
*3:もしかしたら、まだその辺が未完成だった頃のmonoが、いちばん使い易かったのかもしれない。monoランタイムが厳密になればなるほど、SIGSEGVが多く見られるようになっている。
*4:名前が同じであるということは、セマンティクスが合致しているということを意味しないのだから、これは本当に見かけ倒しのやっつけでしかない
*5:その意味では、Mono 1.0リリース直前にやっていた、API互換性を優先してcorcompareでチェックして先にスタブを作っておく、という作業は合理的だ
*6:もちろん、自分で直すだけで、他人に言ってくることがなければ、こういう臭い物には単純に蓋をしておくのだけど。
