Vale reparar o apoio de nomes fortes da comunidade, como Doug Lea e Joshua Bloch, que inclusive participam do projeto. Um apoio desse traz chances de algumas coleções serem candidatas a entrarem em uma futura versão do Java SE.
Não podemos deixar de falar que muitas das “novas” coleções existentes ali, o Apache Commons Collections (ex Jakarta Commons Collections) possui já a anos: http://commons.apache.org/collections/
A API de Coleções é uma parte fundamental do JavaSE, que todos os desenvolvedores precisam conhecer a fundo e tirar o melhor proveito. Novas coleções são sempre bem vindas!
Saudacoes guri louds, percebi que voce nao curti a api do pessoal jakarta (apache), as colecoes deles acho muito bom, uso muito nos clientes, antes de usar, gastava em torno de 30 minutos para manipular 9.000 objetos, agora caiu para 2 segundos, negocio absurdo… costumo atualizar sempre as apis deles nos projetos.
Ao Luca e sem querem ao Silveira, obrigado pela dica do Collection do Google, vou dar Stop Watch nas duas colections e ver quem ganha.
Saudacoes guri louds, percebi que voce nao curti a api do pessoal jakarta (apache), as colecoes deles acho muito bom, uso muito nos clientes, antes de usar, gastava em torno de 30 minutos para manipular 9.000 objetos, agora caiu para 2 segundos, negocio absurdo… costumo atualizar sempre as apis deles nos projetos.
Ao Luca e sem querem ao Silveira, obrigado pela dica do Collection do Google, vou dar Stop Watch nas duas colections e ver quem ganha.
Haloha,
Leandro Capuano[/quote]
Eu acho elas terriveis, até a versão 2.x tinhamos aquelas tranqueira de FastXXXX que eram anunciadas como sendo thread-safe mas nunca foram. Fora que a maioria das collections alí são mera perfumaria.
E sem contar também que ainda na versão 3.2 não há suporte para Generics.
(Que na verdade foi um dos motivos para o Google criar sua própria extensão de collections ao invés de contribuir com o projeto commons)
Rafael, infelizmente eles nao podem colocar generics, ou entao o jar nao rodaria mais nos projetos antigos que ainda assumem compatibilidade com o jdk 1.2. Claro que eles podiam usar aqueles esqueminhas de gerar o jar para 1.x a partir de fonte 1.5.
[quote=Paulo Silveira]Leandro, que collection por qual collection que voce trocou?
Concordo com o louds que tem muita perfumaria la, sem contar o enorme numero de deprecated na versao 3.x[/quote]
Saudacoes Silveira,
Em primeiro lugar, perdao pela demora. Entao costumo usar muito as interfaces Closure, Transformer e Predicate, quando migro de uma versao antiga para nova, costumo mudar o jar (commons-collections-x.x.jar), re-compilo os codigos, e checo se contem algum erro, caso contenha, abaixo a api e vejo que tem de depreciado e arrumo para o mais recente), caso contrario, there you are!
O guri Rafael Nunes comentou que a versao 3.2 nao contem Generic, isto eh de fato, tive que criar uma classe abstract (public abstract class GenericClosure extends Object implements Closure) para atender a minha necessidade, fiz para todas as interfaces, bem que podia colaborar com o pessoal do Apache, o problema eh que o meu tempo eh curto pra documentar e enviar via CVS os fontes.
[quote=leandrocapuano]¡Por supoesto! Sou eu de novo, esqueci de comentar… nao tive tempo pra colocar o Stop Watch das api do Google e comparar com o Apache ou Jakarta.
Haloha,
Leandro Capuano[/quote]
Leandro: suponho que esteja se referindo à Classe org.apache.commons.lang.time.StopWatch do Commons Lang, certo?
Já uso (e às vezes até abuso) o Commons Collections há muito tempo, principalmente os functors (Closure, Transformer e Predicate) e sempre foram uma mão na roda (certo Leandro?). Quanto a sua adaptação para os Generics, há um fork do projeto no SourceForge. Entretanto, no wiki há uma declaração de que a API será refeita do zero para suportar generics. Portanto, podemos esperar novidades.
Quanto à API do Google dei uma olhada (superficial, admito) e por enquanto não fiquei muito impressionado.
