私の小さなソフトウェアライブラリは他のライブラリの使用を避けるべきですか？

わずかなクラスとメソッドのみを提供する小さなJavaライブラリをリリースしました。Mavenを使用してプロジェクトを構築したので、すぐにいくつかのサードパーティライブラリを使用して、特に次の目標を達成しました。

commons-lang3（いくつかの一般的なJavaのもの用）
slf4j-api（ロギング用）
commons-io（ほんの少しのファイル用-文字通り一度ファイルを読む、と思う）

自分のライブラリが他人の目に肥大化しているように見せたくない。フットプリントを最小限に抑えるために、これらのライブラリへの依存を削除する必要がありますか？将来さらに多くのライブラリを使用することを検討する際に、どのタイプのライブラリを避けるのが最善かについてアドバイスはありますか

java libraries maven

— ダンカン・ジョーンズ
ソース

あなたの質問の具体的な部分は答えられるように見えます：あなたのプロジェクトに加えて具体的なライブラリに加えて、問題ないかどうか。問題は、一般的な部分「should ... small ... avoid」と一緒につづったことです。現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または特定の専門知識によってサポートされると予想されますが、この質問は、議論、議論、投票、または詳細な議論を求める可能性があります。この質問を改善できると思われる場合は、FAQのガイダンスをご覧ください。

— gnat

@gnatおMyび申し上げます。通常のStack Overflowユーザーとして、私はプログラマーには少し主観的な質問が受け入れられると思っていました。そのような問題が問題ないStack Exchangeサイトはありますか？それまでの間、質問から曖昧さを取り除きます。

— ダンカンジョーンズ

@gnatこの質問は、元の形式でも問題ありません。

— トーマスオーエンズ

@ThomasOwensすべての敬意を払って、私はそうは思わない。以下のために元のバージョン歓迎ポーリングゲーム：私はすぐに、反対の勧告に両方の合理的に正当化2つの答えを考え出し

— ブヨ

@gnat 2つだけですか？それはいいです。それらを投稿して投票させてください。正反対の正当化と推論を伴う2つの潜在的に正しい答えは、問題を悪くしません。3または4あるいは5それは、ライブラリ開発者が対処しなければならない問題だ整形質問ませんん、と負担は、その後の回答に置かれるどちらも良い答えも。

— トーマスオーエンズ

回答:

私はあなたの特定の状況を考慮してこれに答えています。これらのライブラリを使用しても問題ないと思います。slf4j-apiで実装が実行されないことを確認してください。つまり、実装の依存関係を「テスト」としてマークするということです。例えば：

<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-log4j12</artifactId>
    <version>1.7.2</version>
    <scope>test</scope>
</dependency>

これについては、SLF4j FAQで詳しく説明されています。

他の2つのIMEについては、常に下位互換性があります。したがって、5年後にライブラリを使用する必要があるが、それらの古いバージョンを使用している場合、依存関係を除外するだけでコードは引き続き機能します。言い換えれば、これらの特定のライブラリを使用することで、他の人にjar-hellを導入することはありません。

ライブラリをMaven経由で使用する場合、ライブラリが肥大化しているかどうかはわかりません。私はあなたに依存してそれを使用します。フットプリントを小さくするよりも、コードが正しく機能することが重要だと思います。バグのあるホイールを再発明するのではなく、commons-ioを使用することをお勧めします。

— ダニエル・カプラン
ソース

回答いただきありがとうございます。私が取るべきアプローチに広く同意していると思います。1ビット修正するだけです-slf4jをライブラリプロジェクトに含める方法はslf4j-api、提供されるかどうかに関係なく、他の関連するアーティファクトを単に含めることです。slf4j.org/manual.html#projectDepを参照してください。

— ダンカンジョーンズ

exclude依存関係にある特定のモジュールがslf4jバージョンで「同意」できなかったときに、脳を傷つけたエクササイズ（数十億のiirc）を思い出しました。あなたの答えから、モジュール設計者がそれをとして公開する場合provided、そのような問題はないでしょうか？

— グナット

@gnat通常は、POMで1つの優先バージョンを宣言することで解決されます（少なくともMavenでは）。Mavenはアーティファクトに定義された「最も近い」バージョンを使用し、即時のPOMは推移的な依存関係を上回ります。おそらく、これはMaven 2.xリリース中の動作の変更でした。

— ダンカンジョーンズ

slf4jを指定するための+1- provided非常に目立たない。

— ゲイリーロウ

@DuncanJonesありがとう、たぶん当時はこれを見逃していた。私のMavenバージョンは2.2または2.3でしたが、どちらを思い出すことはできません（mvn dependency:analyze除外されるまでがらくたバージョンを持っていた方法を覚えていますが）：

— gnat

番号。

「膨張」は神話です。ライブラリ内のコードの量に関係なく、そのコードの一部が使用されない場合、ページングされません。パフォーマンスまたはメモリフットプリントにまったく影響を与えません。

一方、追加の機能が必要な場合は、2つの選択肢があります。それを自分で書いて、他の人が以前に解決した問題を解決するために多くの時間と労力を費やすか、すでに存在する（そしてテスト/デバッグ/などされた）ソリューションを使用することを選択できます。

これにより、ダウンロードサイズとディスク領域のフットプリントが残ります。そして、あなたが愚かな数字を話さない限り、2013年には、心配する必要のあるもののリストの一番下に近い2つの要素になります。

— マキシマスミニマス
ソース