소규모 소프트웨어 라이브러리가 다른 라이브러리를 사용하지 않아야합니까? 제공하는 작은 Java 라이브러리를 출시했습니다. Maven으로

방금 소수의 클래스와 메소드를 제공하는 작은 Java 라이브러리를 출시했습니다. Maven으로 프로젝트를 구축 한 후 즉시 여러 타사 라이브러리를 사용하여 목표를 달성했습니다.

  • commons-lang3 (일부 일반적인 Java 기능)
  • slf4j-api (로깅 용)
  • commons-io (작은 파일 내용-문자 그대로 파일을 한 번 읽습니다.)

내 도서관이 다른 사람들의 눈에 부풀어 오르는 것을 원하지 않습니다. 발자국을 최소화하기 위해 이러한 라이브러리에 대한 의존도를 제거해야합니까? 앞으로 더 많은 라이브러리를 사용할 때 피해야 할 라이브러리 유형에 대한 조언이 있습니까?

답변

귀하의 특정 상황을 고려하여 이에 답변하고 있습니다. 해당 라이브러리를 사용하는 것이 좋습니다. slf4j-api가 구현을 수행하지 않도록하십시오. 즉, 구현 종속성을 “test”로 표시합니다. EG :

<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를 사용하는 것이 좋습니다.

답변

아니.

“혈액”은 신화입니다. 라이브러리에있는 코드의 양에 관계없이 해당 코드 중 일부가 사용되지 않으면 페이지에 포함되지 않으며 성능이나 메모리 공간에 영향을 미치지 않습니다 .

반면에 추가 기능이 필요한 경우 두 가지 중에서 선택할 수 있습니다. 직접 작성하여 다른 사람들이 이미 해결 한 문제를 해결하는 데 많은 시간과 노력을들이거나 이미 존재하는 솔루션 (테스트 / 디버깅 등)을 사용하도록 선택할 수 있습니다.

이로 인해 다운로드 크기와 디스크 공간이 부족해졌으며 어리석은 숫자를 이야기하지 않는 한 2013 년에는 걱정해야 할 사항의 맨 아래에 가까운 두 가지 요소가 있습니다.

답변