我的小型软件库应该避免使用其他库吗？

我刚刚发布了一个小的Java库，其中仅提供了几个类和方法。自从我使用Maven构建项目以来，我立即使用了几个第三方库来实现我的目标，特别是：

commons-lang3（用于一些通用的Java东西）
slf4j-api（用于记录）
commons-io（用于一小部分文件，我认为一次读取一个文件）

我不希望我的图书馆在别人眼中显得appear肿。我是否应该尝试摆脱对这些库的依赖以最大程度地减少占用空间？在将来考虑使用更多类型的库时，最好避免使用哪种类型的库？

java libraries maven

— 邓肯·琼斯
source

问题的具体部分看起来很容易回答：您的项目加上具体的库以及是否还可以。问题是，您将其拼写为“应该……很小……避免”。按照目前的情况，这个问题并不适合我们的问答形式。我们希望答案得到事实，参考或特定专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决，请参阅FAQ中的指导。

— 蚊蚋

@gnat我很抱歉。作为常规的Stack Overflow用户，我倾向于假定程序员可以接受一些稍微主观的问题。是否有Stack Exchange网站可以解决此类问题？同时，我将消除问题中的任何含糊之处。

— 邓肯·琼斯

@gnat这个问题即使是原始形式也可以。

— Thomas Owens

@ThomasOwens，我谨此表示敬意。对于原始版本，我很快想出了两个带有相反建议的答案，并且都给出了合理的理由：欢迎民意测验

— 2013年

@gnat只有两个？没关系。让他们发布并投票。具有正当性和推理的两个可能正确的答案相反，这并不会使问题变得糟糕。3或4甚至5都不是。这是一个格式正确的问题，开发人员必须解决这个问题，然后将负担加在答案上就成为了好的答案。

— Thomas Owens

Answers:

考虑到您的具体情况，我正在回答这个问题。我会说使用这些库很好。只要确保您的slf4j-api不带实现即可。这样，我的意思是将实现依赖项标记为“测试”。例如：

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

这在SLF4j FAQ中有详细描述。

至于其他两个，IME，它们总是向后兼容。因此，如果从现在起5年后，我需要使用您的库，但是您使用的是旧版本的库，那么我可以排除您的依赖项，并且我们的代码仍然可以使用。换句话说，通过使用这些特定的库，您不会为其他人引入jar-hell。

如果我通过Maven使用您的图书馆，我不会注意到您的图书馆是否肿。我会依靠你的并且使用它。我认为，让您的代码正确运行比占用更小的代码更为重要。我更喜欢您使用commons-io，而不是使用其中的bug重新发明轮子。

— 丹尼尔·卡普兰
source

感谢您的答复，我想我们在我应该采取的方法上大体上达成了一致。只是要纠正一位-在库项目中应该包含slf4j的方式是仅包含slf4j-api而不提供其他相关工件（无论是否提供）。参见slf4j.org/manual.html#projectDep。

— 邓肯·琼斯

我记得exclude当我的依赖项中的特定模块无法在slf4j版本上“达成协议”时，我必须进行一些破坏大脑的练习（成千上万的iirc）。从您的答案看来，如果模块设计人员将其公开为provided，就不会出现这样的问题，对吗？

— 蚊蚋

@gnat通常，可以通过在POM中声明一个首选版本来解决（至少在Maven中）。Maven采用为工件定义的“最近”版本，并且即时POM超过了传递依赖项。可能这是Maven 2.x发行期间的行为更改。

— Duncan Jones

+1，用于将slf4j指定为provided-非常引人注目。

— 加里·罗

@DuncanJones谢谢，那时候我可能错过了。我的Maven版本是2.2或2.3，记不清mvn dependency:analyze是哪个版本（尽管我确定还记得如何带出废话，直到被排除在外：）

— 2013年

没有。

“膨胀”是一个神话。无论您的库中有多少代码，如果其中一些代码从未使用过，则不会被分页-它将对性能或内存占用量没有任何影响。

另一方面，如果您需要额外的功能，则有两种选择。您可以自己编写它，并花费大量时间和精力来解决其他人以前已经解决过的问题，或者您可以选择使用已经存在的解决方案（已经过测试/调试/等）。

这给我们留下了下载大小和磁盘空间占用空间，除非您说的是愚蠢的数字，否则在2013年，这两个因素应该接近您需要担心的事情清单的底部。

— 马克西姆斯·迷你姆斯
source