何事も使い方次第
これを使うことのメリットってあまりないような気がする。Collection APIを使っているコードって全体の何分の1だろう？システムを稼動しているときに、全体の何分の1実行されるんだろう？しかも、3層なり、4層なりのシステム構成をとるのがほとんどの現在、システム全体としてはこのツールを導入することで、どのくらい速度が向上するのだろう？ だったら、ネットワークなりサーバのCPU・メモリの速度をあげちゃったほうが、てっとり早いと思う。
それはそれで1つの真実だが、世の中の Java を使っている人がみんな Web な人な訳でもないわけで、自分みたいに言語処理やらの研究に Java を使っている人間もいるし、ちょっと前に書いたとおり、言語処理の研究者で直接/間接に trove 使っている人は少なくない。別に言語処理の研究で無くたって Collection の速度が問題になる場面はあるけど。
要するに汎用的なライブラリだからといって何でもかんでも適用するんじゃなく使いどころを見極めれば良いだけの話で、いきなり使えない判定するのはいささか乱暴な話だ。
もう1点。trove はただの高速な Collection Library なだけでなくて、各 primitive type 用の Collection 用意されているのでシステムが J2SE 1.4 以前ならその目的だけに導入するのもありといえばあり。要するに高速な commons primitives として使うと。
また、標準APIがあるのに、このツールを導入することで、システム構成が複雑化してしまう恐れがある。システム構成はシンプルにしないと、保守のコストがかかってしまう。いくらドキュメントが秀逸でも理解に時間がかかってしまうし、シンプルなシステム構成が取れることに勝るものはない。
別にいきなり全部リプレースするか否かって話にしなくても、頻繁に実行されるコンポーネントの実装内部でだけ使うってのもありじゃないかな。闇雲なパフォーマンスチューニングってのは良い結果を出さないし。
