Noticias javaHispano.org

String vs. StringBuffer vs. StringBuilder

ldeseta — Wed, 03 Dec 2008 17:41:00 GMT

La concatenación de cadena de caracteres es una tarea muy habitual en prácticamente cualquier programa. En Java hay varias formas de concatenar los String, y su rendimiento difiere muchísimo. En String vs. StringBuffer vs. StringBuilder les dejo una breve explicación de estas tres formas de concatenar caracteres, y una breve prueba de rendimiento donde demostramos porqué StringBuilder es, en general, la mejor forma para realizar concatenaciones (incluso mejor que el conocido StringBuffer).

Noticia publicada en www.javahispano.org. Accede a la página web y participa

Conozcamos LIQUidFORM

Marioko — Wed, 03 Dec 2008 16:19:13 GMT

LIQUidFORM siginifica Language Integrated QUeries For Object Relational Mapping, es una libreria java que simplifica mucho la realizacion de consultas JPA sin necesidad de usar tanto Strings. Esta libreria es un DSL inspirado en LINQ que evita problemas comunes al escribir consultas.

¿Alguna vez haz hecho una consulta JPA y luego te ha tocado cambiar el nombre de una clase o metodo? ¿te ha tocado ir y buscar cada una de las consultas (pura Strings) y reemplazar uno a uno los cambios que hicistes?. Obviamente las cadenas no pueden ser refactorizadas por ningun IDE.

Para entenderlo mejor miremos el siguiente ejemplo:

Tenemos una consulta JPA comun y corriente:

String myQuery = "select p from Persona where p.nombre like 'mario%' ";

con LIQuidFORM seria de la siguiente manera:

Persona p = LiquidForm.use(Persona.class,"p");

String myQuery = select(p).from(Persona.class).where(like(p.getNombre(),"mario%").toString();

Al final solo seria cuestion de:

List< Persona > personas = entityMgr.createQuery(myQuery).getResultList();

Notan las ventajas? Tenemos una consulta full refactorizable, type-safe y que sigue siendo igual de compacta que la consulta original. Esta es la mejor forma que he visto para hacer consultas JPA, mucho mejor que la API de criteria actual de hibernate y muchisimo mejor que la api de criteria que traera JPA 2.0 que no se entiende nada y es super compleja.

Este proyecto tiene una licencia Apache 2 y pueden encontrar mas ejemplo y descargarlo desde:

http://code.google.com/p/liquidform/

Comentarios: 3 Fecha último comentario: 03/12/2008 18:14

Noticia publicada en www.javahispano.org. Accede a la página web y participa

Artículo sobre la especificación de Servlets 3.0

janatic — Wed, 03 Dec 2008 11:52:33 GMT

Parece que la nueva especificación de servlets está a punto de salir.

En Theserverside han publicado un artículo sobre algunos de estos nuevos cambios, y realiza una crítica de algunos de ellos. Parece que uno de los cambios mas grandes es que se pueden usar anotaciones para gran parte de los puntos específicos de los servlets.

La crítica alude precisamente a esto. Por ejemplo, en vez de declarar un servlet simplemente extendiendo HttpServlet, es posible hacer una clase normal y anotarlo como servlet. En realidad no es una clase normal, ya que tienes que crear el equivalente al método doPost o doGet recibiendo los parámetros de siempre.

Dejo el enlace para que echeis un vistazo.

http://www.theserverside.com/tt/articles/article.tss?l=PonderingAboutJSR135

Noticia publicada en www.javahispano.org. Accede a la página web y participa

Publicado el seminario sobre Glassfish v3 en español

abraham — Wed, 03 Dec 2008 11:03:38 GMT

Jorge Sánchez en El Acuario (el weblog sobre Glassfish en español) ha publicado enlaces a la presentación y a la grabación de video de ustream del seminariosobre Glassfish v3 que Eduardo Pelegri impartió a mediados del mes pasado en español. Así que, a los que os lo perdisteis, ahora tenéis la ocasión de acceder a este material.

Noticia publicada en www.javahispano.org. Accede a la página web y participa

Novedades de Spring 3.0 en el SpringOne Americas 08

ecamacho — Tue, 02 Dec 2008 18:31:39 GMT

Solomon Duskis escribe en su blog sobre la charla de Juergen Höller "What's new in Spring Framework 3.0". Lo que llama la atención es el roadmap de esta nueva versión de Spring:

3.0 Milestone 1: Esta misma semana
3.0 RC1: Marzo 2009
3.0 Final: Abril 2009.

Así que para aquellos aventureros que no temen usar Milestones, esta misma semana podrán probar las nuevas características de Spring 3.0. Entre estas características, la principal es que será la primera versión de Spring en no soportar el JDK 1.4, sino que ya es necesario contar con el 5. De esta forma, el equipo de SpringSource está trabajando para aprovechar las bondades de este JDK: StringBuilders vs StringBuffers, java.util.concurrent, etc.

Por otro lado, se anunció el uso de Unified-EL para todo Spring Framework, antes solo se soportaba en capa web mediante Spring Webflow. De esta forma y usando este lenguaje, será posible referenciar y hacer uso de SpringBeans, por ejemplo, en anotaciones: @Value("#{systemProperties.databaseName}") o dentro del applicationContext.

Otras novedades:

Soporte para Portlets 2.0
Spring MVC REST. Siguiendo la línea trazada en la versión 2.5, se seguirá trabajando mediante anotaciones para exponer servicios REST de forma simple. Por lo que veo, soportarán las especificación JAX-RS pero irán más lejos y añadirán sus propias anotaciones.
Validaciones: Soporte para Hibernate Validations y el JSR 303 (cuando salga) :-).
Soporte preliminar para JEE 6. Ya que esta especificación todavía no está terminada, irán soportando paulatinamente las diferentes APIs que la conforman. Entre estas destaca el soporte para Servlets 3.0, webbeans, JSF 2.0 y JPA 2.0.
Nuevo sistema de building basado en Ivy. La verdad cuando crearon su repositorio de bundles OSGi (en escencia es un repositorio Maven) pensé que migrarían a maven. Pero veo que optaron una solución intermedia y seguirán usando Ant con el plugin de Ivy que les permita usar su repositorio. Además se dice adios al monolítico spring.jar ya que todos los módulos de Spring vendrán en su propio jar con el fin de ser más amigables a OSGi.

Además de estas y otras características (revisen el blog de Solomon), destaca que se eliminarán muchas dependencias que ya no tienen demasiado sentido. Por ejemplo commons-attributes, TopLink, Struts 1.0, etc. y que se deprecará Spring MVC tradicional (sin uso de anotaciones y basado en extender clases) y el soporte a JUnit 3.8.

Como ven, los de Spring siguen a todo vapor mejorando su framework y para el primer trimestre del año que viene ya tendremos la versión 3.0 disponible y estable. Veo que cambiarán muchas cosas y ello aunado a que funcione solo con JDK 5 harán que las migraciones a esta nueva versión sean un poco más lentas de lo habitual.

Comentarios: 4 Fecha último comentario: 02/12/2008 23:07

Noticia publicada en www.javahispano.org. Accede a la página web y participa

Vroom Request Dispatcher 1.0

abraham — Tue, 02 Dec 2008 09:39:29 GMT

Vroom Request Dispatcher es una solución que permite mapear URLs a métodos de clases Java, independientemente de si estos métodos son estáticos o dinámicos. Empleando esta solución, no es necesario escribir un Servlet para asociar una determinada funcionalidad escrita en código Java a una URL.

Además, Vroom Request Dispatcher puede ligar las URLs con funcionalidad escrita en Groovy, JRuby, JavaScript y JPython. Este proyecto acaba de anunciar su versión 1.0 y se distribuye bajo la licencia GPL v3.
Comentarios: 1 Fecha último comentario: 02/12/2008 11:52

Noticia publicada en www.javahispano.org. Accede a la página web y participa

JBrownie, un compilador que detecta automáticamente cambios y los compila

abraham — Tue, 02 Dec 2008 08:52:16 GMT

JBrowniees un wrapper en torno al Javac que se emplee por defecto en el sistema y que tiene la capacidad de detectar cambios en un repositorio de código fuente, y cuando identifica un cambio automáticamente compila los archivos que han cambiado. Una potencial aplicación de esta herramienta es permitir a gente que emplee editores de texto en vez de IDEs tener una funcionalidad similar a la de "compile on save" que tiene Eclipse desde hace bastante tiempo, y que Netbeans ha incorporado en su versión 6.5.

JBrownie está desarrollado por la empresa Onyxbits y se distribuye bajo licencia Apache 2.0
Comentarios: 3 Fecha último comentario: 03/12/2008 15:41

Noticia publicada en www.javahispano.org. Accede a la página web y participa

Características JSF 2.0 (opinión publicada en Solo Programadores)

abraham — Mon, 01 Dec 2008 16:15:58 GMT

Características JSF 2.0 (opinión publicada en Solo Programadores)

Leonardo Vargas Sandoval, desarrollador de sistemas en Evertect Latinoamérica.

JSF 2.0 presentará novedades en cuatro áreas principales: facilidad de desarrollo, desempeño, adopción y nuevas características. Seguidamente un resumen de éstas.

Facilidad de desarrollo: esta área permitirá la creación de componentes por medio de agregación, reducirá la configuración por medio de descriptores, remplazándola por un uso extensivo de anotaciones las cuales se usarán al desarrollar componentes, navigation rules etc. Por último se eliminará el desarrollo de Tag Handlers gracias a la integración con facelets.

Nuevas características: entre las nuevas características se puede ver una expansión del ciclo de vida del request para brindar soporte a peticiones Ajax, además se ofrecerá soporte de primera clase para el manejo de los recursos utilizados por los componentes JSF.

Desempeño: se propone renderizar deltas de los componentes JSF según se necesite en lugar de un renderizado completo de los componentes, se mejorará el manejo de eventos mediante PhaseListener y los componentes serán sin estado por defecto.

Adopción: para tener una mejor adopción JSF pretende mejorar la interoperabilidad entre librerías de diferentes vendedores, se agregará soporte para JSR 311, Skinning o Themeing entre otros.

Finalmente surgen las preguntas: ¿JSF facilitará el desarrollo como lo hacen Wicket, GWT o Tapestry?, ¿Logrará una integración entre librerías?, ¿Será aceptado? Lo anterior depende del rumbo que tome la especificación y de la ayuda que brinde la comunidad desarrolladora.

Comentarios: 12 Fecha último comentario: 02/12/2008 22:46

Noticia publicada en www.javahispano.org. Accede a la página web y participa

Más motivos para no usar Flex (esta vez más serios)

abraham — Sun, 30 Nov 2008 18:24:50 GMT

De un modo similar a otra entrada en un weblog que criticaba Flex, Bozhidar Bozhanov ha decidido escribir su propia opinión sobre el framework RIA de Adobe después de haberlo usado en un proyecto de envergadura pequeña-mediana. En esta ocasión, las críticas que se realizan en contra de Flex me parecen más serias y bien fundadas.

Entre estas críticas, se encuentran lo primitivo del mecanismo de gestión de excepciones que básicamente se basa en códigos de error, la carencia de soporte para multithreading (para el programador, porque internamente Flex sí usa varios thread), fallos en el carácter dinámico de ActionScript que, en ciertas ocasiones, le llevan a no determinar de modo adecuado el tipo de los objetos, varias deficiencias en el modelo de gestión de eventos, etc.

Como resultado de su experiencia, el autor concluye que Flex y ActionScript están todavía poco maduros y que en el próximo proyecto tipo RIA que tenga que abordar empleará GWT.

Comentarios: 6 Fecha último comentario: 03/12/2008 09:33

Noticia publicada en www.javahispano.org. Accede a la página web y participa

JavaHispano Podcast - 025 - Noticias Diciembre 2008 (a)

JorgeRubira — Sun, 30 Nov 2008 14:44:01 GMT

En el siguiente número hablaremos de las últimas noticias correspondientes al portal. Presentado por Abraham Otero y Jorge Rubira. Las noticias que comentaremos son:

Comentarios: 20 Fecha último comentario: 03/12/2008 13:49

Noticia publicada en www.javahispano.org. Accede a la página web y participa