-道具

私はね、道具は結構めんどくさいものでもよくて、使いこなすことでベネフィットが出るなら難しいぐらいでいいと思うのですね。ほら、それがたとえ悪い意味でも差別化というものに近づくじゃないですか。一方で道具として「優しく易しい」のは最高ですよ。たとえちょっとベネフィットが減ったとしても。もちろん、優しく易しいハイリターンツールは究極です。でも、たぶん実現は難しいし、それが出た瞬間からそこがスタートラインになっちゃう。少なくとも同時に両方を達成するんじゃなくて、どちらか片方を先に達成してからもう片方が遅れて進むことになるでしょう。たとえばS2Daoはそのへんどちらも高度に満たしているからすごいよね、と。しかしどちらも高レベルながらどちらかというと易しい寄りでベネフィットにもうちょっと余地があるから、今度はKuinaで行こう、となってるわけです。
最近のJavaでフレームワークを見たり作ったりしている中、最近自分の達成順位で優先設定しているベネフィットがあります。高負荷・高スループットWEB環境の実現です。たまたま、ウチはこれが仕事に求められることが多いんですよ。で、そこに間違いが無いなら、相当優しくなかったり易しくなくてもいいかなと思うのです。ただしウチだけかもしれませんが。暗号化が遅いっていうんでネイティブで作ってJNIで叩くとか、セッションに積むモノを減らすために特別な設計したりとか。結果が予測どおりに必ず出せるとも限らないので、コーディングクラッキ達がいろいろがんばってるわけです。
3年ぐらい先の予測として。。。JavaリフレクションがWEBのパフォーマンス上キツい局面に出会うような気がしています。もちろんリフレクションの手前に、やることはたくさんあります。まずは大きな壁としてガベージコレクションの挙動を意識しながらの地道な施策もあるし、ユーザーインターフェイスの工夫でサーバ負荷をドラスティックに下げられるようなこともあるでしょう。しかしそれもこれもやった後、中間地点ぐらいのところにリフレクションの壁が来ると思います。小さいかもしれないけど、ほかにやることやったら手をつける順番になります。
私と、私の向かいで今何をやってるかというと、MayaaのHAチューンとIkushipeです。Mayaaは徐々に出していくバージョンでは相当パフォーマンス良くなっています（いろいろ要望いただいていますが、機能の充実は今は二の次なんですよ、すいません）。普通サイズのサイトでは問題なくても、デカいサイトでやるには赤く塗らないといけないw。実際、手をいれた後は3倍早くなりました（当社比）。Ikushipeは執拗に実行時のリフレクションがゼロになるようにしています。WEBフレームワークですが直接間接問わずにClass#getMethods()もなければ、Class#getAnnotation()も無いです。それはコンパイルの時にコード生成で仕込むのです。Ikushipeが終わったら、Mayaaのコードジェネレータ化と思ってます。ユーザーのためのコード生成ではなくJavaVMのためのコード生成なため、Churaさんとは同工異曲です。
たぶん今年度はそこらあたりで終わっちゃうでしょう。