【Java】Apache Jakarta Commons
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
NGNGApache Jakarta Commons について語るスレッド
Apache Jakarta Commons
http://jakarta.apache.org/commons/
中でも便利なものが
Commons Lang
http://jakarta.apache.org/commons/lang/
Commons Collections
http://jakarta.apache.org/commons/collections/
Commons FileUpload
http://jakarta.apache.org/commons/fileupload/
とくにLangには equals(), hashcode(), compareTo(), toString()
メソッドを簡単にオーバライドできるメソッドが用意されており重宝する。
そのほか、NestableExceptionはC#のような言語に頼らなくても
投げられ続けた例外を上書きせずに保持する事ができるので便利。
Collectionsは java.utilのコレクションクラスに不満を持つ者にとっては
朗報だ。ListとHashを兼ねた便利なクラスも用意されており、その数は豊富である。
0153デフォルトの名無しさん
2005/03/31(木) 23:31:410154デフォルトの名無しさん
2005/03/31(木) 23:32:030155デフォルトの名無しさん
2005/03/31(木) 23:32:240156デフォルトの名無しさん
2005/03/31(木) 23:33:14叔母です。
0157デフォルトの名無しさん
皇紀2665/04/01(金) 11:43:270158デフォルトの名無しさん
NGNG0159デフォルトの名無しさん
2005/04/20(水) 16:28:13Jakarta Commonｓ Daemon
http://jakarta.apache.org/commons/daemon/
を使ってる人いますか？使い勝手とか感想が聞きたいんですけど・・・
0160デフォルトの名無しさん
2005/04/20(水) 22:22:41仕方がないとはいえ、Cで作ったライブラリを一部使うので、jarがあればどこでも使えるというわけには
いかない。狙い所はいいのに、なんとかならんものか。
0161デフォルトの名無しさん
2005/04/20(水) 22:54:570162デフォルトの名無しさん
2005/04/21(木) 05:56:02OSに深くかかわる部分だしある程度は仕方ないね
0163デフォルトの名無しさん
2005/04/21(木) 22:01:27JavaService の方が使い勝手は良さそう。
0164デフォルトの名無しさん
2005/05/18(水) 20:54:390165デフォルトの名無しさん
2005/05/19(木) 07:27:22http://incubator.apache.org/projects/ftpserver/
誰かつかったことある人います？
使用感とか教えていただけると助かります。
0166デフォルトの名無しさん
2005/05/24(火) 10:43:27ほかのフレームワークとかもだけどDBを完全に正規化しておくとかVIEWを作ってあげないとだめぽなのかなぁ
0167デフォルトの名無しさん
2005/05/24(火) 10:55:12そんなもまいにこのｽﾚを。
Java⇔RDBのMapping-Frameworkを語るThre Vol.3
ttp://pc8.2ch.net/test/read.cgi/tech/1090653286/
0168デフォルトの名無しさん
2005/05/24(火) 11:01:27㌧です。
早速のぞいてみます。
0169デフォルトの名無しさん
2005/05/24(火) 12:22:40HibernateかS2DaoかEJB3待ちか、最近の選択肢は３つ。
0170デフォルトの名無しさん
2005/05/24(火) 12:33:03手軽にSQL-Mappingということなら、iBATISも選択肢に入ると思われ。
0171デフォルトの名無しさん
2005/05/28(土) 15:46:48Commons NetのSMTPClientでsendMessageData()メソッドを使ってメッセージ送信する際、
文字エンコーディングを指定するにはどうすればいいですか？？
何か参考になるサイトでもいいのでどなたかよろしくお願いします m(__)m
0172デフォルトの名無しさん
2005/05/28(土) 22:51:050173デフォルトの名無しさん
2005/05/29(日) 09:06:17俺はJavaMailの方でやっているけど、いずれこっちに変えようかと思っていたので調べてみた。
Commons NetのSMTPは、シンプルにSMTPというプロトコルを実装しているだけなので、MIMEは全然ノータッチみたい。
エンコーディングを自分でした後、それをsendMessageData()するという感じだと思う。
メール送信するだけならCommons EMailというのがあるけど、今のところCVSからしか落とせないみたい。
JavaDoc見る限り EMail.setCharset()というのがある。EMailクラスを継承したMultiPartEmailクラスがあるからこれを使うみたいだけど、
試してないからホントにちゃんと使えるのかどうかは知らない。
Commons EMailがCommons Netを使っているのかどうかも不明。
もし試してみるなら、結果を報告してくれたらうれしい。
0174デフォルトの名無しさん
2005/05/29(日) 16:29:360175デフォルトの名無しさん
2005/05/29(日) 16:35:590176デフォルトの名無しさん
2005/05/30(月) 02:00:15# いま、Jakartaにつながらない。
半年前使ったときには、SMTP はJavaMail を使ってました。
MultiPartには対応していていました。
そのときは、charsetがまともに指定できてなかったと思います。
0177JavaMailプロ
2005/05/30(月) 05:07:22(1) javax.mail.MimePart#setText(String text, String charset)を使えば、
"text/plain"限定で文字セット指定ができる。
(2) javax.mail.Part#setContent(Object body, String mimeType)を使えば、
任意のMIMEタイプ/文字セット指定ができる。
エンコーディング指定には javax.mail.Part#setHeader("Content-Transfer-Type", "BASE64")等を指定。
ただし、(2)では実際のエンコーディング処理は内部的に
JAF(Java Activation Framework)のDataHandlerクラス (javax.activation.*)が呼び出している。
もし、デフォルトでインストールされているDataHandlerが、期待するエンコーディングをしない場合は、
新しいエンコーディング用にDataHandlerとDataSourceのサブクラスを作成して、
JAFのプロパティ・ファイルに登録してやる必要がある。
・・・JavaMailは、「Javaのメール・クライアントを作ってPCデスクトップを攻略」するためのAPIだったんで、
メール・クライアント以降の新しいニーズ(例えばSOAPやMQ)では使いにくいかもしれない。
以降、JavaMailプロの独り言
・・・その昔、JavaMailがまだβ版だった当時、
日本語メール慣習への適合度や、バグ含有度を調べる余裕がなくて、
JavaMail APIをフルスクラッチで書いて、
その上にメール・クライアントを構築した事を思い出した。
(本当はメッセージ・キューやらワークフロー・エンジンも作るって言われたから
基礎からカッチリ作ったんだけど・・・未実現。
つか、そのうちJMSやらSOAPが出てきた。俺の仕事ってつくづくProgress Software近辺と被ってるのな)
0178デフォルトの名無しさん
2005/05/30(月) 06:31:080179デフォルトの名無しさん
2005/05/30(月) 08:28:360180177訂正
2005/05/30(月) 08:57:05○ ただし、(1)(2)の実際のエンコーディング処理は、MIMEタイプに応じてJAF APIのDataHandlerが処理してる
0181デフォルトの名無しさん
2005/06/03(金) 02:08:39そうです
0182デフォルトの名無しさん
2005/06/03(金) 02:15:180183デフォルトの名無しさん
2005/06/03(金) 02:54:43とりあえずスレ違いにはならないとおもわれる範囲で
質問・同意を得る形式でレスをすること。
答えがどうあろうとレス稼ぎが問題なので単発で終わることが多い。
0184デフォルトの名無しさん
2005/06/04(土) 11:59:280185デフォルトの名無しさん
2005/06/04(土) 12:18:02レス稼ぎと荒らしの関連性が分からん。
0186デフォルトの名無しさん
2005/06/05(日) 11:37:07無視しろ。183はコピペ荒らしだ。
0187デフォルトの名無しさん
2005/06/11(土) 13:14:35すっげー気になったもんで。
0188デフォルトの名無しさん
2005/06/11(土) 13:19:18>>187 ル・シ～ン！！！ (銭型警部の声で
0189デフォルトの名無しさん
2005/06/11(土) 14:15:250190デフォルトの名無しさん
2005/06/11(土) 14:39:450191デフォルトの名無しさん
2005/06/11(土) 21:41:210192デフォルトの名無しさん
2005/06/12(日) 00:33:15それは「アルセーヌ・ルパンIII世」
0193デフォルトの名無しさん
2005/06/12(日) 00:35:230194デフォルトの名無しさん
2005/06/12(日) 01:12:29「ばかもーん、そいつがルパンだ、追え～」
0195デフォルトの名無しさん
2005/06/12(日) 02:36:06ルパンごっこ？
0196デフォルトの名無しさん
2005/06/12(日) 10:51:31「インターポールの銭形です。 ルパンを追っているので見かけたら連絡をお願いします。」
と言って立ち去る。
２．すぐにドタバタ戻ってきて店員に、
「今わしを見かけなかったか？」
と怒鳴りつける。
３．「今あなたアンパン買って・・・」
「ばかもーん！そいつがルパンだー！！」
と言って、またドタバタと出て行く。
0197デフォルトの名無しさん
2005/06/12(日) 15:17:380198デフォルトの名無しさん
2005/06/12(日) 15:35:31「ばかもーん、そいつがアンパンマンだ、追え～」
0199デフォルトの名無しさん
2005/06/16(木) 01:30:59tools.view.servlet.error.template( = Error.vm)
tools.view.servlet.layout.directory( = layout/)
tools.view.servlet.layout.default.template( = Default.vm)
この設定を全て無効化することはできないのか？
test.html?layout=./
このレイアウトのパラメータも無効化したい。
0200デフォルトの名無しさん
2005/07/26(火) 11:35:150201デフォルトの名無しさん
2005/07/26(火) 11:38:340202200
2005/07/26(火) 12:34:010203171
2005/08/02(火) 01:02:12大分遅くなりましたが丁寧な解答ありがとうございます。
Commons EMailはまだ試していないのですが、SMTPClientで日本語を送信できるようになりました。
String encodedSubject = new String(Base64.encodeBase64(subject.getBytes("Shift_JIS")));
Writer writer = smtp.sendMessageData();
if (writer != null) {
writer.write("Subject:=?iso-2022-jp?B?" + encodedSubject + "=?=\n");
writer.write("From: " + from + "\n");
writer.write("To: " + to + "\n");
writer.write("MIME-Version: 1.0\n");
writer.write("Content-Type: Text/Plain; charset=\"iso-2022-jp\"\n");
writer.write("Content-Transfer-Encoding: base64\n");
writer.write(new String(Base64.encodeBase64(message.getBytes("Shift_JIS"))) + "\n");
writer.close();
smtp.completePendingCommand();
}
Base64のエンコーディングにはCommons Codecを使いました。
これで一応日本語が化けずに送れてます。
もっともE-Mailや文字コード周りの知識があまりないので、作法的にはあやしいかも知れませんが・・・^^;
0204デフォルトの名無しさん
2005/08/07(日) 00:45:500205デフォルトの名無しさん
2005/08/09(火) 20:32:26現場で使ってる奴がほとんどいないけど・・・
0206デフォルトの名無しさん
2005/08/09(火) 22:58:23BeanUtilsは型やプロパティ名が実行時解決なので、
コンパイル時にチェックできないバグが増えるから気をつけてね。
0207デフォルトの名無しさん
2005/08/10(水) 12:08:050208デフォルトの名無しさん
2005/08/10(水) 13:10:11何するライブラリなのか分かってないけど
リフレクションでウハウハするための何か？
0209デフォルトの名無しさん
2005/08/10(水) 20:01:42ソースは見てないけど、xmlから読み込むなら
やっぱりリフレクトでウハウハかなとは思う
0210デフォルトの名無しさん
2005/08/10(水) 22:17:10確かにウハウハだが、なんでもかんでもMapに詰め込んでってのは
エレガントではないな。 まあただの宗教論争だが。
0211デフォルトの名無しさん
2005/08/10(水) 22:17:25一応テスト・デバッグ済みってことになってるし。
リフレクションは重いけどね・・・
Hibernateはリフレクション使ってないよ。使ってたらもっと重いフレームワークになる。
Strutsはバリバリ。カスタムタグとか、リクエストパラメータをActionFormにセットするところとか、
DynaActionFormとか。BeanUtilsはもともとStrutsの一部だったモノだしね。
0212デフォルトの名無しさん
2005/08/10(水) 23:03:40ところでhibernateってなんて読むの？
未だに分からない
0213デフォルトの名無しさん
2005/08/10(水) 23:37:380214デフォルトの名無しさん
2005/08/11(木) 00:36:120215デフォルトの名無しさん
2005/08/11(木) 00:38:08リフレクション使ってないけど、バイトコード操作なんていうコンパイル時にチェックできないバグがもっと増える仕組み使ってるがね。
0216デフォルトの名無しさん
2005/08/11(木) 01:10:58いいんじゃない？テスト・デバッグはHibernate開発者の責任だし。
自分でそういう仕組みを使うときは気をつけてね、ってことで。
0217デフォルトの名無しさん
2005/08/11(木) 01:13:28フレームワークとか作るんじゃなくて普通の業務ロジックのためにバイトコード操作してたらブッコロスね。
0218デフォルトの名無しさん
2005/08/11(木) 22:21:47|;:;:;:;:;:;:;:!'" ヽ;:;:;:;ヽ
|;:;:;:;i''" i!;:;:;:;|
|;:;:;:;| ヾ;:;:;:|
|;:;:;:;| ,,,;;:iii;;;;; ,.-＝＝--､. `!;:;|ヽ
〉;:;:| ,.-''"￣￣￣`ヽ⌒| --｡､-､ ヽ-`' | 綺麗な顔してるだろ
i `u i -‐'"ヾ'" :: ::! : | ノ 落選するんだぜ、これ。
i | ノ ヾ､＿＿＿ノ ::|
| | ヽ､＿＿,.-i i ､ : :|
| | : : '" `～ー～'" ヽ : : ::|
`i ヾ ' ＿＿＿＿ ;: ;: :|
＼ -‐'''"~￣￣￣￣ ; ;: :/-
ヾ: : . ` " " " ,.／
0219デフォルトの名無しさん
2005/08/11(木) 22:23:53ソースは見てないけど、xmlから読み込むなら
やっぱりリフレクトでウハウハかなとは思う
0220デフォルトの名無しさん
2005/08/11(木) 23:04:530221デフォルトの名無しさん
2005/08/12(金) 00:06:12まあ原理的には重そうなんだけど開発環境じゃそんな体感できないし。
どういう状況までなら使えるのか線引きが出来ない。
で、結局デバック用のBeanのフィールドのログはきぐらいにしか使ったことない。
0222デフォルトの名無しさん
2005/08/12(金) 00:12:03テーブル5つ程度の簡単なアプリをローカルのPCで動かすだけで
体感できるほど重くなるよ。
Beanのsetter/getterを呼ぶ箇所を全部BeanUtilsを使うように書き換えてみるとわかる。
書き換えるクラス数も10数個程度。
リフレクションは、重いという弊害の他に、ダウンキャストの危険性も多い。
Mapオブジェクトと同じように、せっかくJava言語に用意されている
「型安全性」を無視してしまうから個人的に好みではない。
0223222
2005/08/12(金) 00:12:51BeanUtilsは、に訂正してくれ。
0224デフォルトの名無しさん
2005/08/12(金) 03:07:36Lang,Collections,IOは常用
Codec,HttpClientはたまに
0225デフォルトの名無しさん
2005/08/16(火) 12:27:46普通にハイバネートで良いかと。一般動詞っすよ。
>リフレクトってどんぐらい重くなるんだ？
使い方次第としか。
何かのラッパークラスのソース自動生成とか、
コストのかかる処理(接続とかインスタンス生成とか)の一部で使う分には
全く問題にならんレベルだと思うし。
>224
io, logging は常用
dbcp,pool,collection,beanutilsは常用ライブラリ(Springとか)が間接的に使用
digester,betwixtは以前常用してたけどxmlbeansに移行してしまった今日この頃。
commons じゃない jakarta スレってないんでしょうか。
velocity くらいしか使ってないけど。。
0226デフォルトの名無しさん
2005/08/17(水) 00:00:00このスレはとっとと終わらして、Jakarta スレたててくれ。
1年弱で 200 ちょっとしか消費してないから、使い切るのは
4年後か。
0227デフォルトの名無しさん
2005/08/17(水) 23:45:07IOって便利なの？
あおってるわけじゃなくて普通に知りたい。
オススメ機能教えてよ。
そんな常用するほど使えそうなの見つからない。
まあ名前で使えそうなのさっと探しただけだけど。
closeQuietlyとかソースみたら何じゃそりゃって感じだし。
0228デフォルトの名無しさん
2005/08/18(木) 09:37:08あれ使わないとなると
・毎回try-catchのネストを記述する。
・自作ライブラリに closeQuietely 相当のものを用意してそれを呼び出す。
のいずれかですよね。
前者は保守性・視認性・手間の全ての面からして
個人的にはありえないと思ってます。
後者は他人がコード読んだ時を想像するに、
俺様関数にぶち当たって関数のコード読む手間と
読み終わってから「結局commons-ioのアレじゃねえか。」
と溜息つかせる事を考えれば、あんま嬉しくない気がします。
0229デフォルトの名無しさん
2005/08/18(木) 23:36:28インポートしてってよりは自分とこの共通クラスにコード書くね。
だって誰が書いたってああなるでしょ。
実際ほとんど同じのcommons自体知る前に書いてたし。
結局commons-ioかよとか思わないと思うけどね。
別にたいした手間じゃないんだけどクラスパスが無駄に多いのは好きじゃない。
まあ好みの問題だと思うけど。
0230デフォルトの名無しさん
2005/08/19(金) 00:08:16だるいコードを書かなくてすむ。
IOUtils.toString(InputStream)
CopyUtils.copy(InputStream, OutputStream)
FileUtils.copyFile(File, File)
Ant が中で使ってるクラスも組み合わせるとかなり楽。
org.apache.tools.ant.taskdef の Copy クラスとか Property クラスとか。
タスク名がクラス名になってて、excute メソッド呼ぶだけ。
0231デフォルトの名無しさん
2005/08/19(金) 02:48:30環境構築のたびにクラスパスったって、今日ビ、IDEでプロジェクト作成したときに登録するだけだろ。
importなんか勝手に書いてくれるし。
0232デフォルトの名無しさん
2005/08/19(金) 09:51:56こういう勘違い発言をする奴がいまだにいるのか。
フレームワーク・ライブラリ・デザインパターンがなぜ存在するのかを考えろよ
0233デフォルトの名無しさん
2005/08/19(金) 11:55:20>229
プロジェクト作るたびにそのプロジェクトの Utility クラスに
closeQuietely 相当のコードを記述するんですか？
毎回同じ事を書くのに？
俺様.jar にまとめてしまった方が100倍マシだと思いますけど。
とても好みの問題だとは思えないです。
毎回同じクローズ処理
↓
うぜえから関数化(今このあたり)
↓
毎回同じ関数書いてるから俺様.jar作成
↓
気がつけば当たり前のようにみんな同じことやってる
↓
車輪の再発明は時間の無駄だから commons-io にしてしもうぜ
0234デフォルトの名無しさん
2005/08/19(金) 12:04:27closeQuietelyしか使わない前提で話を進めているようだから、
メソッド一つのために外から拾ってきたライブラリを入れのか普通？
jarがいくつになれば気が済むんだと問いたい問い詰めたい。
0235デフォルトの名無しさん
2005/08/19(金) 12:26:30毎回他人の俺様コードを見るより「いつものライブラリ」を使う方が数百倍まし。
0236デフォルトの名無しさん
2005/08/19(金) 12:36:07目当てのメソッド以外のクラスやメソッドが使われた時のテストや管理のリスクは無視か。
趣味で触ってるやつならともかく、人のコード見ないで出来る仕事ってそうはないと思うがな。
>jarがいくつになれば気が済むんだと問いたい問い詰めたい。
これについでの回答は？
おめぇの趣味で一々jar入れてたら100や200個になりかねないから、
採用に当たってのポリシーが必要なわけだが、
お前が使いたいメソッドが１個あるから入れろってか？
俺がリーダーなら帰れって言うな。
0237デフォルトの名無しさん
2005/08/19(金) 12:59:23>>236 のような視点では結論は出ないよ。（意見を否定しているわけではない。念のため。）
ただ、俺様.jarはいただけない。その点は >>235 に同意。
ひどいPGだと、よそで使ったコードをそのまま持ち込もうとしたりとか。
そういう意味でもやばい。
> jarがいくつになれば気が済むんだと問いたい問い詰めたい。
必要とあらば仕方ないんじゃね？ IDE使えば無問題だし。
0238デフォルトの名無しさん
2005/08/19(金) 13:02:27ってのは採用に値しないのか？
これはもう釣りかも分からんね。
0239デフォルトの名無しさん
2005/08/19(金) 13:09:13バカか？テスト・デバッグはライブラリベンダの役割だ。
それとも、おまえのところは初めて使う製品はすべて自社でテストし直すのか？
＞人のコード見ないで出来る仕事ってそうはないと思うがな。
それは当たり前だが、少なければ少ないほどいいのがわからないのか？
毎回同じコードを書き直すほうがいいのか？
＞ >jarがいくつになれば気が済むんだと問いたい問い詰めたい。
いくつになっても結構。
なぜ増えると困るのかね？もしかして全部手作業でデプロイしてるとか？ｗ
0241デフォルトの名無しさん
2005/08/19(金) 14:03:08自社で使ってるライブラリ（そっちの言う俺様jar）とかならテスト済みだから、
毎回テストが必要って言うお前の主張がおかしいって話だ。
>いくつになっても結構。
ど素人ってのがよく分かったから、今度人のプロジェクトに参加する時に
「このメソッドが使いたいから、このほげほげjarをプロジェクトに入れてね」と頼んで見な。
お前が入れるのは別に反対はしないが、
そうしなければならないというお前の主張が常識と思うならそりゃ大間違いだな。
>たとえ一つでも誰もが使うメソッドがある(ry
ないな。外部ライブラリーの使用のリスクについてまったく無知でなければそんなことはしない。
jarが本当に100個になっても、そのバグ情報やバージョン、ドキュメントなどを管理できる
スーパープロジェクトリーダーならともかくな。
0242デフォルトの名無しさん
2005/08/19(金) 14:22:38はぁ？
↓Jarを入れないって話じゃなかったのか？
＞ jarがいくつになれば気が済むんだと問いたい問い詰めたい。
0243デフォルトの名無しさん
2005/08/19(金) 14:24:32で、おまいはApacheのプロダクトを使うときは毎回自社ですべてのコードをテストし直すのか？
0244デフォルトの名無しさん
2005/08/19(金) 14:28:50俺はどっちかというとアーキテクトの立場だから
「このライブラリを使いましょう」という俺の意見はほぼ通ってるよ。
0245デフォルトの名無しさん
2005/08/19(金) 14:32:43>>227=>>229=>>234=>>236=>>241はひとつのメソッドが使いたいだけなのに、
その他のメソッドがついてくる（はずせない）のは問題ないのかと言ってるのね。
他の香具師らが言ってるメリットと比べてこっちの問題のが大きいだろと。
その問題ってのが当たり前だの常識だのって言葉でくくられてるからかみ合わないわけね。
実際にリスク見積もって判断しろよって>>227（略）は言いたいんだよな？
それならわかるわ。
不謹慎だが、宮城の地震で屋根が落ちたプールの話と同じ構造だな。
業者に丸投げ（他所のライブラリをチェックせず使う）すると安く出来上がるが、
安全であるかどうかの確認がしにくくなる。
>>239のいうライブラリのテストデバッグは～ってのはまさにこの構図。
最終的な客に対する責任は利用するコードを書いた側に出てくるんだぜ？
断じて、ライブラリを提供した側ではない。
通常は、ライブラリを売ってるところが提供した範囲での責任を取ってくれる
（ライブラリ利用側が客に取る責任よりは小さいわな）、オープンソースだと誰が責任をとる？
もしかしたら、ライブラリのバグのせいで、もまいのシステムが人を殺すかもしれないよ？
0246デフォルトの名無しさん
2005/08/19(金) 14:35:07ライブラリ必要なら入れましょう。
その方が楽なの当たり前。
ただたった一個のメソッドのために入れるのは賛否別れる。
個人的には開発の規模にも因るけどたぶん入れない。
しかもcloseQuetlyじゃね。
結論は程度の問題でしょ。
0247デフォルトの名無しさん
2005/08/19(金) 14:46:48きれいにまとめてくれてありがとう。
>244
jarを入れるのには>245のほかにドキュメントの提供・バージョン・他のライブラリとの相性があるから、
同じアーキテクトの立場ではあるが、リスクを考えるとやはり慎重になるな。
0248デフォルトの名無しさん
2005/08/19(金) 18:31:40少なくとも定番化してるものに関しては拾ってきたとかいうレベルの信頼
性ではないと思う。
もしCommonsを信頼できないとするなら、俺は同僚が書いたコードの方
が遥かに信頼できないよ？ｗ
そして、同僚は俺の書いたコードを信頼できないと思うだろうorz
バグがないとは言わないし、テストに漏れがないとも言わないが、それは
結局誰が書いても同じ事だし？
それなら、より多くの人に触れられ検証される事になるCommonsの方が
信頼できる。
0249デフォルトの名無しさん
2005/08/19(金) 21:07:59いいと思うけど・・・
オープンソースにとやかく文句いっても仕方ないでしょ
いっても使ってるのは、loggingとBeanUtilsだけなんだけど
ioも使えるのか・・・ちょっとやってみよう
ところでDbUtilsとCollectionってどうなの？
0250デフォルトの名無しさん
2005/08/19(金) 21:53:15いつの間にかcommonsのバグの話になってるし。
一個でも使えそうなメソッドがあれば
オープンソースを使わなければならない。
そうしないやつはオープンソースをわかってないし
作ってるシステムもぐちゃぐちゃって感じだね。
commonsかなり気に入って使ってるけど
さすがに一個のメソッドで入れたりしない。
なんかオープンソース好きっていうか宗教っぽいな。
0251デフォルトの名無しさん
2005/08/19(金) 23:13:11commons-langとかでも普通にありえないバグあるから。
バグじゃなくてもパッケージごと移動とかもあるし。
バージョン上がると非推奨になってるやつもいっぱいある。
例えばだがjspでimportしてる古臭い大規模システムだったらimport直して
動作確認するだけでちょっとした人件費に飛ぶな。大人数で開発してる環境ならなおさら。
でそういう時はライブラリを問題あるとわかっててもバージョンアップしないほうが良いのかね？
commonsもオープンソースも否定しないが
当たり前に使うときは動作確認もソースのチェックもするさ。
オープンソース信者の皆さんが言う俺様コードを経由してcommons呼び出したりもする。
なんか不具合あってもそこだけ変えればすむようにな。
まあcommonsマンセーの人たちはどういうシステム作ってきたんだか。
0252デフォルトの名無しさん
2005/08/19(金) 23:33:40その「信頼」の根拠をどこにおくのかわかってるかいって話だよ。
同僚が書いたコードでも、必要なテストをパスしてるんなら今の状態でもOKなわけだし。
>>250の言うように宗教めいてるところはあるね、確かに。
■ このスレッドは過去ログ倉庫に格納されています