Google Guava vs. Apache Commons [fechado]

212

Eu estava procurando por uma implementação de mapa bidirecional em Java e me deparei com essas duas bibliotecas:

Ambos são gratuitos, têm a implementação de mapa bidirecional que eu estava procurando (BidiMap no Apache, BiMap no Google), são surpreendentemente quase do mesmo tamanho (Apache 493 kB, Google 499 kB) [ed .: não é mais verdade!] E parecem de todas as formas, bem parecido comigo.

Qual devo escolher e por quê? Existem outras alternativas equivalentes (devem ser gratuitas e ter pelo menos o mapa bidirecional)? Estou trabalhando com o Java SE mais recente, portanto, não há necessidade de limitar artificialmente o Java 5 ou algo assim.

java collections apache-commons guava Joonas Pulakka
fonte
5
Certamente você deve nos fornecer os critérios para escolher a biblioteca? Licença, desempenho, dependências adicionais, genéricos de apoio, ...
steved
1
Google Collections é acessível em repo1.maven.org: repo1.maven.org/maven2/com/google/collections/...
Joachim Sauer
Eu estou corrigido - Eu estava olhando em com / GoogleCode
kdgregory

Respostas:

185

Na minha opinião, a melhor opção é o Goiaba (anteriormente conhecido como coleções do Google):

  • é mais moderno (tem genéricos)
  • segue absolutamente os requisitos da API de coleções
  • é mantido ativamente
  • CacheBuildere seu antecessor MapMakeré simplesmente incrível

O Apache Commons Collections também é uma boa biblioteca, mas há muito tempo falha em fornecer uma versão habilitada para genéricos (que é uma grande desvantagem para uma API de coleções na minha opinião) e geralmente parece estar em manutenção / não fazer modo -muito-trabalho-sobre-o O Recent Commons Collections recuperou um pouco de força novamente, mas ainda tem muito o que fazer. .

Se o tamanho do download / tamanho da memória / tamanho do código for um problema, o Apache Commons Collections poderá ser um candidato melhor, pois é uma dependência comum de outras bibliotecas. Portanto, usá-lo em seu próprio código também pode ser feito potencialmente sem adicionar dependências adicionais. Edit: Esta "vantagem" específica foi parcialmente subvertida até agora, uma vez que muitas novas bibliotecas realmente dependem do Guava e não do Apache Commons Collections.

Joachim Sauer
fonte
3
O que realmente me pergunto: por que não há outras opiniões? Eu deveria estar bancando o advogado do diabo? Afinal, o Apache Commons Collections não é uma biblioteca ruim.
Joachim Sauer
10
Como o Apache não possui genéricos, acho óbvio qual desses dois é o futuro. Google é o próximo passo lógico adiante. É uma sensação estranha, porém, que ela tenha sido construída pela The Giant ... mas, desde que esteja sob uma licença gratuita, não deve importar, mesmo que tenha sido criada pela Microsoft. Eu acho.
Joonas Pulakka
12
Os leitores devem estar cientes de que esta é uma resposta muito antiga e muita coisa mudou
Roy Truelove
1
@RoyTruelove Não me surpreende que muita coisa tenha mudado e eu adoraria ouvir seus pensamentos atuais sobre o assunto, ou talvez um link para uma revisão / comparação mais recente. Gosto da filosofia "imutável por padrão / mutável apenas se necessário" e da inclusão de genéricos na goiaba, mas os materiais que tenho lido podem ter sido datados, como você diz que esse segmento se tornou.
joeA
2
@ testerjoe2 - Desculpe, eu escrevi esse comentário há muito tempo e, francamente, não me lembro o motivo. Em retrospectiva, foi um pouco inútil! Eu não sabia que as bibliotecas não mudaram desde 2010, mas sei que elas continuam sendo muito usadas e, portanto, eu diria que deveriam ser seguras. Se eu estivesse iniciando um novo projeto hoje, provavelmente daria uma olhada na coleção lib do Goldman Sach: github.com/goldmansachs/gs-collections . Quando você é uma das empresas mais más do mundo, realmente deve se certificar de ter uma biblioteca de coleções java de kickass.
Roy Truelove
72

Do FAQ: Perguntas frequentes sobre coleções do Google

Por que o Google construiu tudo isso, quando poderia tentar melhorar as coleções do Apache Commons?

As coleções Apache Commons claramente não atendiam às nossas necessidades. Ele não usa genéricos, o que é um problema para nós, pois odiamos receber avisos de compilação de nosso código. Ele também está em um "padrão de retenção" há muito tempo. Vimos que seria necessário um grande investimento da nossa parte para consertá-lo até que ficássemos felizes em usá-lo e, enquanto isso, nossa própria biblioteca já estava crescendo organicamente.

Uma diferença importante entre a biblioteca Apache e a nossa é que nossas coleções aderem fielmente aos contratos especificados pelas interfaces JDK implementadas. Se você revisar a documentação do Apache, encontrará inúmeros exemplos de violações. Eles merecem crédito por apontá-los tão claramente, mas ainda assim, desviar-se do comportamento padrão da coleção é arriscado! Você deve ter cuidado com o que faz com essa coleção; os bugs estão sempre esperando para acontecer.

Nossas coleções são totalmente geradas e nunca violam seus contratos (com exceções isoladas, onde as implementações do JDK criaram um forte precedente para violações aceitáveis). Isso significa que você pode passar uma de nossas coleções para qualquer método que espere uma coleção e sinta-se bastante confiante de que as coisas funcionarão exatamente como deveriam.

Davide Consonni
fonte
71

As coisas mais importantes que descobri que fazem do Google Collections o lugar para começar:

  • Genéricos (coleções sem genéricos - FTL)
  • Consistência com a estrutura de coleções (Josh Bloch foi um ator importante nessa estrutura)
  • Correção. Esses caras estão desesperadamente ligados a resolver esse problema; eles têm algo como testes de unidade de 25 mil e estão vinculados a obter a API corretamente.

Aqui está um ótimo vídeo no Youtube de uma palestra proferida pelo autor principal e ele faz um bom trabalho discutindo o que vale a pena conhecer sobre esta biblioteca.

joeslice
fonte
7
+1 para o link do vídeo
Jesper
1
Ótimas leituras adicionais sobre o Google Collections: javalobby.org/articles/google-collections (uma entrevista com seus principais criadores). Procure a pergunta "O que há de único em sua abordagem? Como ela difere, por exemplo, da Apache Commons Collection?"
Jonik
4
O Apache Commons Collections Versão 4 usa genéricos. commons.apache.org/proper/commons-collections/release_4_0.html
Abdull
-7

Duas outras coisas (espero não estar errado)

  • A licença do Guava (novo nome para coleções do Google) é a Licença Apache 2.0, que significa: a mesma do projeto Apache Commons
  • Não consigo encontrar o código fonte do Guava em um arquivo para baixar (parece que apenas um acesso ao git é possível)
Olivier Faucheux
fonte
19
Fontes? Você quer dizer jar que pode ser anexado no Eclipse? Está aqui . BTW: O que há de errado com git clone https://code.google.com/p/guava-libraries/e git checkout v11.0.2?
Xaerxess
-7

Uma coisa desagradável no Guava é que o Multimap não estende o java.util.Map. Se você tiver seus próprios métodos que funcionam no Maps, eles não funcionarão no Guava Multimaps (a interface do Apache MultiMap estende o java.util.Map). Tenho certeza de que há uma boa razão para ser desse jeito, mas também é inconveniente.

mate
fonte
16
Se você quiser usar Multimapcomo Map, sempre há asMap()vista.
Xaerxess 03/09/12
22
Como você espera que um Multimap implemente java.util.Map? Um multi-mapa é fundamentalmente diferente de um mapa.
Sleske #
1
O Multimap <K, V> estende o Mapa <K, Coleção <V>> .. Suspeito que G tenha um bom motivo para não usar o Mapa como superinterface.
Matt
10
@lucek: Se você procurar no Javadoc Map, com o entendimento de que toda referência a Vrealmente será uma Collection<V>, acho que verá rapidamente porque essa não é uma boa superinterface Multimap<K, V>.
Ruakh