昔、jarファイルでアプリケーションデプロイをしなきゃいけないことに対して効率が悪い！と疑問を呈したら、Javaに詳しい人が、「なんとかlet」（コードの集まり）で、デプロイ管理が確実になるからこれで良いんだって言ってた。

確かにjarファイルでまとまった形でデプロイすることは、バージョン管理の面からは信頼性が高くなる。しかし、WEBというのは更新してナンボなので、一々、jar単位で更新してたら面倒で仕方ない。やはり一度、コードがfixしたら、次回の受注まで更新は滅多にやらない「Webアプリケーション」のためのJ2EEなのだなぁと強く思ったものだ。（それならそうと教えてくれればWebサイトになんか使わなかったのにさ。）

HOT deploy完成
HOT deployとは何か。アプリケーションサーバを稼動させたまま､クラスを追加､変更しても､アプリケーションのリロードは不要で､その変更が即座に認識される技術です。

ひがやすおさんが作られた、ダイナミックにクラスを入れかえるための技術だそうで、素晴らしいです。

しかし、これは確かに、すごく素晴らしいと思うんですが・・・こういうのを付け足していくこと自体が、すでにシステムが複雑化していくことを表してるんじゃないかと。DIにせよ、良いとはわかっていても腰が重くて、いろいろ大変だったりして。（で、PHPとかの方に来ちゃったんですけど）

最初、J2EEが好きだったのは、Tomcatから、Servletクラスまで全部Java文法で記述されているってことだったんですが、そうこう言ってる間にStrutsが出てきて、変なXMLファイルが出てきて、DIコンテナが出てきて、またXMLファイルが出てきて、あぁうまくいかないもんだなぁって。フレームワークというアプリケーションの設定ファイルがXML形式なだけだけど、開発作業の中に複数の言語（メタファというべきか）が入ってくるって結構頭の切り替えが大変。効率的なのか非効率なのか、個人的には疑問だった。

・・・そんなことを嘆くより、時代は変わるから、変えて行けば良い。そして実際に変えられるJavaは素晴らしいと思う。ひとえにPure Javaという思想の成果のように思える。

しかし同時にJ2EEは官僚主義的開発思想で作ってしまった失敗策だったのではないかとも思う。

今まで世界中でJavaのコードを書く手間や、Tomcatの再起動、アプリケーションデプロイのために費やしていた工数の合計による損失はどれぐらいあったのだろうか・・・・とか、結構、むなしくなってしまった。そして、その無駄は今後、取り返せるのだろうか。だったら、シンプルなPerlやPHPで作った方が早くて、よっぽど仕事が速くて、管理しやすいのではないだろうか。（極論ですが、転職してPHPいじって、ＣＳＶファイルを読み込むとか、そういう小さな事だけど数倍以上のスピードで実現できた時に、ふと思ったものです。）

極論だがソースコードもCVSやSubversionが使えなくても、Diffのアプリケーションで見渡せる範囲に押さえることはできないのだろうか。それでエンタープライズアプリが作れるかいっ！という反論は承知の、あくまで問題提起として。でも、そういう設計ってできないのかなぁ。潔癖性的にライブラリが分業をしなくても、もっとシンプルにまとめられるパターンはないのか？とか。少々ベタなコードでも構わないんじゃない？頭良い人多いんだから、大丈夫じゃないの？とか。

そういえば、J2EEでEclipseを初めて触ったときに思ったことがあって、Eclipseが最高だと思ったのは、Javaでオブジェクト指向プログラミングをしてると、クラスが階層化してしまうが故にソースコードを追うのがすごく大変だったからなんですよね。ロジッククラスで使うライブラリの奥底のクラスに画面に文字を出力する機能なんて持ってなくて、Eclipseがなかったら何が起きてるのかちっともわからねー、なんてね。

それまでがASPのお気楽プログラミングだったので余計に思ったのですが、Eclipseが出てくるまで、無料のIDEなしでServletでMVCやってた人って、なんて高コストで非効率な人たちなんだろうとかまで思ってました。後から考えると、そういう直感は正しかったのかなぁって。そんなことを思っても、当時はASPじゃダメだ、Javaこそがこの世界の主役なのだ！と信じてやってきたわけですが。

そんな思いこみというかJavaへの信仰があったからこそ、昨今のJavaのライトウェイト化の流れは結構、気持ち悪い。要はJ2EEの設計に対して人々が我慢できなくなってるということなのかなぁとか。