JSR-277かね？
OSGiとか、何か色々とッ散らかってる感すらあるなぁ…
機能としては、大体この３つが要るヨネ？とか。
・Package
・AccessControl
・Interfaces
まぁ、そうね。OSGiも大体そんなもんだ。
またキーワード増やすのかよ…
package の前にmoduleて…、アフォか！！！！
アノテーション位にしとけよ…
module-info.javaとかｗｗｗｗｗ
もうダメだｗｗｗｗｗｗｗ
VMレベルでmoduleサポートするのか。
つまり、VMが理解するメタモデルの量が増える訳だな。
まぁ、しかし、今の今までmoduleシステムが、真っ当に動いてなかったのには、
それなりに理由があると思うんだがなぁ…
Jar Hellってば最悪だよね、みたいなのは、DLL Hellの頃と変わってないじゃんよう。
でも、それはそれで、テキトーに動くんであって、COMや.NETの様な解決策が、
必ずしも正解じゃないと考えている人達はいる訳だよね…
The JAM Module System
JavaSE7に入ってくるのん？これは、OSGi実装の足回り足りえるのん？んぐー
JAMのmetadataは、がりがりとアノテーションを書く。これは、良筋。
でも、俺としては、META-INF/MANIFEST.MFに書いて欲しいんだけどなぁ…
ソースコードじゃなくてさ。っつうか、modulurityとコードって、
ほんとは、全然関係なくネ？とかさ。
正直、スコープのモデルと全然違うコンテキストを用意するんなら、それこそ、
メタモデルをソースコード上に書きたく無い…
既存のスコープモデルの上に、moduleが追加されるんなら、
つまりは、スコープの数と種類が2倍になる訳だよね…、
まぁ、何かさ頑張らなくてもいいんじゃないかな…
JVM上で動作する言語ではそれぞれ、moduleを意識したスコープモデルを実装してさ、
本家のJavaでは、既存のままでもいいんじゃないかなぁ。
つまりは、Cでasm{}みたいにさ、もう、最終的には何でも出来る領域って残しておいて欲しいんだよネェ…
スコープまわりの情報を絞る為の設計ってさ、つまりは、
再利用可能性を定義する事なんだけど、それって、妥当な設計するのがスゲェ難しくて、
結局の所、卑近な表現をすると、スコープを絞った中に、Hackしたい対象はある訳だよ。
クリーンに設計されたinterfaceはそれはそれで必要なのだけど、
そんなに上手く可視性を設計出来ると思うのは、何か、ねじが飛んでるんじゃねぇの？みたいなー。
複雑な可視性構造を出来る様にしたトコロで、地獄の種類が変わるだけだと思うナリ。
A framework for the module System
moduleのリポジトリモデルねぇ…単なるツリー構造じゃん…
まぁ、何か、他に構造があるのかといわれれば、ねぇけども。
おおう、複数のRepositoryが、1つのJVMのなかで、ゴタゴタと通信するモデルについて説明している。
うん。やっぱり、結局ツリー構造を作らざるを得ないのだね。
後は、このツリーが、シンボリックリンク的な事がサックリと無駄なく、
効率的に出来るかどうかが、問題になるかな。
OSGi in the java Module System
結局、現状キチンと実装されていて、
実績のあるJavaのModuleシステムって、OSGiしかないんじゃね？
あー、そんな事も無いか。EJBコンテナとか、DIコンテナもある種のmoduleシステムだな。
でも、スコープを再定義する様なmoduleシステムで、稼動実績がキチンとあるのは、OSGiだけなのかな…
