日々の破片

_ Javaの好きになれない点

Javaという言語とかの話ではなく、Java界隈という言い方が正確かな。

どうにも前から気に入らないところがあって、そしてどうもそこに良くない点が集約されてるような気がしてならなかったのだが、keisukenさんのところを読んでいて、なんとなくわかったような気になった。

つまりJakartaの存在ということだ（※）。

次のやりかたが単に古いだけということはありえるかも知れないが。

新しい技術を利用してシステムを開発するにあたって、とりあえずは数名で先行して動くわけで、その過程で、練習をかねたりして細かなツールやらユーティリティやらを作っていき、それがチームの道具箱に入っていく。それがあらゆる意味でのベースのインフラとなる。サンプルソースにもなり、拡張の練習、更新方法の練習、変更した場合の影響の実験（というか死にそうになったり）、バグパターンの発見もあったりするわけで。新人には、使い込むうちに錆が浮いてきたやつのメンテか、そのへんを参照してよりベターなデザインのユーティリティを作らせてみたり。かくして、この道具箱の中のソース群は生きたコーディング規約であり、チームの文化の根源となる。

そういう順番でやってきているので、そういうものだと思っているし、それは良いプラクティスだと考えているのだが、どうもJava界隈ではそう考えられていないのではないだろうか、ってことだ。

新しい技術を利用してシステムを開発するにあたって、とりあえずは数名で先行して動くわけで、その過程で、どっかのレポジトリを検索してユーティリティを取ってくるのか？

もちろん欠けているものや、そこまで手が回らないもの、あるいは時間が不足しているという理由から、借りてくることはある。具体例だと、特殊なクラスローダはStrutsから抜き出したし、javacの呼び出しはJasperから抜き出した。プールは最初はcommonsを使っていたようだが、途中から、独自のものに切り替えたみたいだ（ここは担当してなかったので良くわからないが）。

道具箱の中が、他人の作ったものばかりで、仕事ができるんだろうか？

Javaの開発はユーティリティクラス作成からはじまる

いや、メインフレームの時も、SYSVのときも（sh、C、いろいろ）、Windows 3.0（C++だな）の時も、COM（C++とVB）、ASP、CE、Java、Ruby（Cライブラリとの互換スクリプトがたくさん）、ASP.NET、常にユーティリティクラスの作成から始めているが、それは特殊なのだろうか？

#なんか特殊な気がしてきたから、どうでもいいや。

※もちろん、Jakartaプロジェクトが、commonsを持っていることは当たり前のことだし、それを公開していることも良いことだ。そうではなく、たかがcommons程度のものをブラックボックスとして当然のように借りてくるところ（いや、解剖学的にソースをすべて確認して、その解析結果をチーム内で共有してとかやってるところもあるだろうから、それなら結果は同じだとは思うが、そんなことするより作ったほうが良いとは思うが）。なんか、練習もなしにいきなりでっかなシステムを組み始めてひいひい言っているんじゃないか、と思えてしまうところだな。もちろん、それ以外に道具箱の中に山ほど作らなければならないものがあって、それで満載されていて、脇のポケットにcommonsも入っているということもあるだろうから、それはそれで良いのだが、でも粒度的にも、必要度からも、処理の難易度からも、ちょうど自分達の練習で作るべきものをcommonsで代替させているんじゃないかなぁ、と感じるところがあるのであった。はいはい、車輪の再発明ね。

追記：多分、誤解はされてないようだけどkeisukenさんがうんぬんってことではないです。ネガティブな意味での「ユーティリティクラス作成からはじまる」というのとcommonsの合体技が、漠然と感じていたcommonsマンセーなJava界隈に対する不快感をうまく表してるな、ってことで。JavaのAPIについては、1.4からの参入だったことと、stdioやlibcとの比較になりやすかったという点から、ほとんど天国でしたね。Rubyとかは別問題だと思っているし（あの面倒くささも固さのうちというか）。