18/05/2009
02/06/2009
18/06/2009
Google ha publicado Google Collections una librería con clases para implementar colecciones que no están en j2se,como:
BiMap: Un mapa de valores únicos y de vista inversa
MultiMap: Un Map que permite valores duplicados
Además de tener clases estáticas para Iterar colecciones, comparar elementos, e incluso autoboxing de arrays.
A pesar de estar en alfa, esta librería - de acuerdo al FAQ de la misma- cuenta con el respaldo de ser usada internamente en desarrollos de Google como GMail o Google Reader; por lo que puedes esperar bastante estabilidad de ella.
En está página puedes descargarla.
Etiquetas: j2se, Google, collection
Muy interesante esta línea en la FAQ de Google Collections: "We already use this library extensively in production for services like GMail, Reader, Blogger, Docs & Spreadsheets, AdWords, AdSense and dozens more".
Para mí es una novedad que Google utilice java en todas estas aplicaciones. Me parece un dato muy positivo, que le voy a mostrar a un par de trolls anti-java XD
¿BiMap? ¿MultiMap?
¿alguna ventaja sobre Commons-Collections que hace años que lleva ofreciendo esto de manera estable?
¿alguna ventaja sobre Commons-Collections que hace años que lleva ofreciendo esto de manera estable?
Quizas Google quiere reinventar todo ? Pues, es la verdad porque entiendo, despues hablar con fuentes a Google, que la proxima cosa que va a aparecer es "Google Rueda", que es algo que usamos para transporte, y ponemos 4 para crear "Google Coche".
Seguramente hay otros problemas en el mundo ...
¿Quizá Google ha probado ya Commons-Collection y no cubre sus necesidades? ¿O quizá la implementación no les daba el rendimiento necesario? ¿O quizá alguna razón que no sabemos?
Naaa, es más fácil suponer cualquier cosa y emitir un juicio basado en la ignorancia.
Uy espera, que aun és más fácil: Extraido del Wiki:
Why did Google build all this, when it could have tried to improve the Apache Commons Collections instead?The Apache Commons Collections very clearly did not meet our needs. It does not use generics, which is a problem for us as we hate to get compilation warnings from our code. It has also been in a "holding pattern" for a long time. We could see that it would require a pretty major investment from us to fix it up until we were happy to use it, and in the meantime, our own library was already growing organically.
An important difference between the Apache library and ours is that our collections very faithfully adhere to the contracts specified by the JDK interfaces they implement. If you review the Apache documentation, you'll find countless examples of violations. They deserve credit for pointing these out so clearly, but still, deviating from standard collection behavior is risky! You must be careful what you do with such a collection; bugs are always just waiting to happen.
Our collections are fully generified and never violate their contracts (with isolated exceptions, where JDK implementations have set a strong precedent for acceptable violations). This means you can pass one of our collections to any method that expects a Collection and feel pretty confident that things will work exactly as they should.
¿Van a aplicarse a Apache Commons Collections los genéricos? Lo digo porque personalmente los genéricos me parecen la mejor incorporación de Java 5, te dan seguridad en tiempo de compilación y el no tener que hacer conversiones en tiempo de ejecución. Además si es cierto que el paquete no respeta los contratos del JDK puede haber problemas si declaras una propiedad de un tipo del JDK y lo instancias con una clase de dicho paquete.
Un saludo.
Hola, soy el primer anónimo
> emitir un juicio basado en la ignorancia.
No me he sentido exactamente emitiendo un juicio desde la ignorancia, sino remarcando que existe una librería de Jakarta que tiene esos BiMap (BidiMap) y MultiMap (Bag) y que es estable y se usa en producción desde hace años, en vez de ser una alpha.
Porque en JavaHispano entra mucha gente que puede llevar poco tiempo en Java y puede hacer una mala elección por no sabar que existe commons-collections.
Claro que, puedo estar equivocado, desde la ignorancia no aprecio del todo bien la realidad.
Hola,
No has emitido ningun juicio, asi que obviamente el comentario no iba por ti ;).
En cuanto al por qué, ellos mismos lo explican y aunque no es que esté mal preguntar, siempre es mejor ir a las fuentes a obtener de primera mano las respuestas. La información es como la transmision en algunos medios, cuantos más pasos intermedios, más ruido.
y me imagino entonces, que ahora hay qué utilizar esta librería ... porque ... COMO ES HECHA POR GOOGLE !! ¿QUIÉN NO QUIERE ESTAR DEL LADO DE GOOGLE? Definitivamente somos a veces tan idiotas ... todo nos lo tragamos entero ¿PORQUÉ NO ESFORZARNOS POR PARTIR DE LO BUENO QUE HAY O INCLUSO TRATAR DE MEJORARLO ?
"Lo bueno que hay" podría ser esa librería de google, no?
Muchas veces es mas rentable hacerlo desde nuevo, que intentar destripar chapuzas para intentar mejorarlas o reutilizarlas (no digo que sea el caso). Incluso intentar mejorar una libreria aceptable (bien organizada, etc...), puede ser muy duro y desmoralizador cuando te pegas horas y horas intentando comprenderla para que luego no puedas adaptarla o segregar la utilidad que necesitas en tu libreria/aplicación.
También depende de lo gorda que sea la libreria o lo compleja que sea la funcionalidad implementada, a veces no vale la pena rehacerlo desde 0. En este caso creo que si merece la pena rehacerlo porque no es una implementación compleja.
Un saludo.
Definitivamente somos a veces tan idiotas ...
Totalmente de acuerdo, aplicate el cuento. Tranquilo que otros no escogemos librerías por razones como esas. A mi si es Google como si es Apache, las miro, las evaluo y si no me sirven pues a otra cosa.
Simplemente la han hecho por lo que habia no les ha servido y la ponen por si les sirve a otro, si eso te causa un trauma deberías tomartelo conmás calma, hombre :).
Hay que tener cuidado con librerias de terceros......el día que dejen de mantenerlas o actualizarlas (caso de apache con su commons-collections) nuestros aplicativos serán esclavos de librería out-of-time.....
Yo por eso apuesto por seguir los estandares de SUN y desarrolar mis propias librerias....que las actualizaré cuando deba y el dia que deje de mantenerlas, es que ya no estaré en este mundo....
Hay que tener cuidado con librerias de terceros......el día que dejen de mantenerlas o actualizarlas (caso de apache con su commons-collections) nuestros aplicativos serán esclavos de librería out-of-time.....
Yo por eso apuesto por seguir los estandares de SUN y desarrolar mis propias librerias....que las actualizaré cuando deba y el dia que deje de mantenerlas, es que ya no estaré en este mundo....
A estas alturas decir que las librerias OpenSource van a dejar de mantenerse es lo mismo que decir que "me gusta crearme mis propios drivers de conexion a base de datos, por si un dia dejan de mantenerlos"
Intento siempre utilizar SUN ysino Apache o cualquier otra libreria pero con fuentes, por si hay que mantenerlos.
Que pasa con todo el codigo desarrollado utilizando librerias de Weblogic, Ibm o Oracle ... y si dejan de mantenerlos como en su dia hizo Microsoft con su maquina virtual y sus "apaños" para ActiveX.
http://www.volny.cz/celebrities/map.html naked celebrities photo http://www.volny.cz/celebrities/
Escribe tu comentario