Minha pequena biblioteca de software deve evitar o uso de outras bibliotecas?

Acabei de lançar uma pequena biblioteca Java que oferece apenas algumas classes e métodos. Desde que construí o projeto com o Maven, imediatamente usei várias bibliotecas de terceiros para atingir meus objetivos, especificamente:

commons-lang3 (para algumas coisas gerais sobre Java)
slf4j-api (para registro)
commons-io (para um pouquinho de material de arquivo - literalmente lendo um arquivo uma vez, eu acho)

Não quero que minha biblioteca pareça inchada aos olhos dos outros. Devo tentar remover minha dependência dessas bibliotecas para minimizar minha pegada? Algum conselho sobre quais tipos de bibliotecas seria melhor evitar ao considerar o uso de mais no futuro?

java libraries maven

— Duncan Jones
fonte

parte concreta da sua pergunta parece respondida: seu projeto mais bibliotecas concretas mais se está tudo bem. O problema é que você o escreveu junto com a parte geral "deve ... pequeno ... evitar". Atualmente, essa questão não se encaixa no nosso formato de perguntas e respostas. Esperamos que as respostas sejam apoiadas por fatos, referências ou conhecimentos específicos, mas essa pergunta provavelmente solicitará debates, argumentos, pesquisas ou discussões prolongadas. Se você acha que essa pergunta pode ser melhorada, consulte as Perguntas frequentes para obter orientações.

— gnat 31/01

@gnat Minhas desculpas. Como usuário regular do Stack Overflow, eu tendia a supor que questões ligeiramente subjetivas eram aceitáveis para os programadores. Existe um site do Stack Exchange em que esses problemas sejam aceitáveis? Enquanto isso, removerei qualquer imprecisão da minha pergunta.

— Duncan Jones

@gnat Esta pergunta é boa, mesmo em sua forma original.

— Thomas Owens

@ThomasOwens com todo o respeito, acho que não; para versão original eu rapidamente percebi duas respostas com recomendações opostas, ambos razoavelmente justificada: jogo de votação bem-vindo

— mosquito

@gnat Apenas dois? Isso é bom. Deixe-os serem publicados e votados. Duas respostas potencialmente corretas com justificativa e raciocínio opostos não tornam a pergunta ruim. Nem 3, 4 ou até 5. É uma pergunta bem formada, com a qual os desenvolvedores de bibliotecas de problemas devem lidar, e o ônus é colocado nas respostas para serem boas .

— Thomas Owens

Respostas:

Estou respondendo a essa questão, considerando sua situação específica. Eu diria que é bom usar essas bibliotecas. Apenas certifique-se de que o seu slf4j-api não traga a implementação com ele. Com isso, quero dizer marcar a dependência de implementação como "teste". POR EXEMPLO:

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

Isso é descrito em detalhes nas perguntas frequentes do SLF4j.

Quanto aos outros dois, IME, eles são sempre compatíveis com versões anteriores. Portanto, se daqui a cinco anos precisar usar sua biblioteca, mas você estiver usando uma versão antiga, posso excluir suas dependências e nosso código ainda funcionará. Em outras palavras, usando essas bibliotecas específicas, você não apresentará jar-hell para outras pessoas.

Se eu usar sua biblioteca via maven, não notarei se sua biblioteca está inchada ou não. Vou depender do seu e usá-lo. Eu acho que é mais importante que seu código funcione corretamente do que tem uma área menor. Prefiro que você use o commons-io em vez de reinventar a roda com um bug.

— Daniel Kaplan
fonte

Obrigado pela resposta, acho que concordamos amplamente com a abordagem que devo adotar. Apenas para corrigir um bit - a maneira como se deve incluir slf4j em um projeto de biblioteca é simplesmente incluir slf4j-apie nenhum outro artefato relacionado, fornecido ou não. Veja slf4j.org/manual.html#projectDep .

— Duncan Jones

Lembro-me de alguns exercícios que prejudicam o cérebro (zilhões de excludesegundos) que eu tive que fazer quando determinados módulos em minhas dependências não "concordavam" com uma versão do slf4j. Na sua resposta, parece que se os projetistas de módulos o expusessem provided, não haveria problemas assim, correto?

— gnat 31/01

@gnat Normalmente, isso seria resolvido (pelo menos no Maven), declarando uma versão preferida no seu POM. O Maven utiliza a versão "mais próxima" definida para um artefato e o POM imediato supera as dependências transitivas. Possivelmente, essa foi uma mudança de comportamento durante o lançamento do Maven 2.x.

— Duncan Jones

+1 para especificar slf4j como provided- muito discreto.

— Gary Rowe

@ DuncanJones obrigado, eu provavelmente perdi isso naquela época. Minha versão do maven era 2.2 ou 2.3, não consigo lembrar qual (embora eu me lembre como mvn dependency:analyzeestava trazendo versões ruins até excluídas) #

— 306

Não.

"Inchaço" é um mito. Independentemente da quantidade de código existente na sua biblioteca, se algum código nunca for usado, ele não será paginado - ele não terá nenhum impacto no desempenho ou na pegada de memória.

Por outro lado, se você precisar dessa parte extra de funcionalidade, terá duas opções. Você pode escrevê-lo e gastar muito tempo e esforço resolvendo problemas que outras pessoas já resolveram antes ou pode optar por usar a solução que já existe (e foi testada / depurada / etc).

Isso nos deixa com tamanho de download e espaço em disco, e, a menos que você esteja falando de números tolos, em 2013 eles são dois fatores que devem estar próximos ao final da lista de itens com os quais você precisa se preocupar.

— Maximus Minimus
fonte