トップ «前の日記(2007-09-02) 最新 次の日記(2007-09-04)» 編集

日々の破片

著作一覧

2007-09-03

_ 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とかは別問題だと思っているし(あの面倒くささも固さのうちというか)。

本日のツッコミ(全8件) [ツッコミを入れる]
_ がお (2007-09-03 16:57)

既にあるものを自分で作っていることを公言した人が<br>「車輪の再発明」とつっつかれているのは<br>よくある光景ですね。

_ arton (2007-09-03 21:10)

そうですね。まあ細かいことを言い出すと、DRYにしたがっているか/いないか(僕は従うべきと考えてますが)、政治的な意味、コストとかいろいろあるんですが、車輪がどうしたとか言い出している例で、その車輪が車体にフィットしているのを見た覚えは見識が狭いからだとは思いますが、残念ながらないんですよ。

_ Saisse (2007-09-04 00:31)

Javaはソースコードを書かない/書かせないという方向に突き進んでいて、それがいいのかどうかって事なんだと思います。当然アクティブにコードを書く人はそんな世界に安住することはなくて、コードが書ける世界(つまりRuby)への移動が始まったというのが今の現状なのではないかなーと思います。

_ arton (2007-09-04 01:20)

ちょっとそれはあまりに極端流なコメントだと思いますよ(と、感じたけど、本気で言われているのであれば、Saisseさんの立ち位置から、僕にはすさまじく興味深いですけど)。<br>ただ、そこにJRubyが出てくるのは唐突に感じます。むしろ、JVM上のJRubyの使いどころはXMLの代替としてのDSL用ではないでしょうか? (むしろコードを書かせないの側)

_ Saisse (2007-09-05 01:12)

あんまり冗談で書いてるつもりはないのですが(汗 Java->という流れが実際にはあってその原因の底辺に近い一部にはなっているんじゃないかなーと思います。<br>何故にRubyなのかというと十年前のJavaの状況に似ていると思うんです。そのころはWebアプリをCGIでしか作るかしかなくて不満がたまっていた所にServlet+JDBCがポンッとでてきた感じが、RoRが出てきた状況に当てはまるかなーと。

_ arton (2007-09-05 03:05)

ああ、なるほど。JRubyというよりRailsが前提なんですね。<br>ちょっと興味があるのですが、もし、Jakarta Rails(のような、Javaで、CoC+DRY+自動ORマッパ付きのMVCフレームワーク)が出たら、そっちに向かいますか?

_ Saisse (2007-09-07 20:59)

うーん、難しいですね。Railsのバランスは全体的に動的な言語に依存しているので、JavaでWebアプリケーションを最適化していくと自動生成が中心に来るんじゃないかなーと思ってます。

_ arton (2007-09-07 23:18)

確かに、そういう印象も受けますね>自動生成<br>動的言語だと、自己書き換えができるので、ソースを生成する必要も、生成したソースを保持しておく必要もないかも知れませんね。


2003|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|02|03|04|05|06|07|08|09|10|11|12|
2024|01|02|03|

ジェズイットを見習え