web-dev-qa-db-ja.com

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

小さなJavaライブラリをいくつかのクラスとメソッドしか提供しないライブラリをリリースしました。Mavenでプロジェクトをビルドしたので、すぐにいくつかのサードパーティライブラリを使用して目標を達成しました。具体的には次のとおりです。

  • commons-lang（いくつかの一般的なJavaについて）
  • slf4j-api（ロギング用）
  • commons-io（ほんの少しのファイルの場合-文字通りファイルを1回読み取ると思います）

私のライブラリが他の人の目には膨らんで見えるようにしたくありません。フットプリントを最小限に抑えるために、これらのライブラリへの依存を取り除こうとしていますか？将来、より多くのライブラリを使用することを検討する場合、どのタイプのライブラリを避けるのが最善かについてアドバイスはありますか？

javalibrariesmaven
13
Duncan Jones

私はあなたの特定の状況を考慮してこれに答えています。これらのライブラリを使用しても問題ないと思います。 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を使用することをお勧めします。

8
Daniel Kaplan

番号。

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

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

これにより、ダウンロードサイズとディスク容量のフットプリントが残ります。馬鹿げた数を話さない限り、2013年には、心配する必要のあるもののリストの最後に近い2つの要素があります。

1
Maximus Minimus