Los puntos de dolor de Java

Cay Horstmann escribe en su blog un comentario sobre lo que llama los puntos de dolor de Java.

Entra en algunas discusiones recientes que ponen a la evolución Java en un camino sin salida, y lo relaciona con la evolución de C++ (igual que hacía Eckel). Horstmann, igual que Eckel, parece abogar por una estabilización del lenguaje, pero se centra más en presentar qué es lo que realmente (en su opinión) necesita mejorarse en Java, qué es lo que le produce más sufrimiento a la hora de desarrollar. En su opinión, las discusiones sobre la necesidad de las closures, u otras similares, desvían la atención de otros problemas más importantes/interesantes.

Para Horstmann la verbosidad del lenguaje, la necesidad de escribir más (y en ocasiones más confuso) es doloroso pero no es el problema principal. Lo que más dolor le causa son por un lado la concurrencia -que empieza a ser más importante últimamente con la disponibilidad general de microprocesadores de varios núcleos- y las aplicaciones web, el esfuerzo que supone la falta de un framework web decente [dice él].

Yo personalmente no he tenido que enfrentarme al tema de la concurrencia últimamente, pero sí coincido en que el desarrollo de aplicaciones web en Java es bastante más doloroso (o al menos cansado) de lo que debería ser. Y también coincido con otra queja que aparece unas cuantas veces en los comentarios: Swing.

¿Y vosotros? ¿Qué es lo que más sufrimiento os causa? ¿Qué véis más necesario mejorar?

¿Están los días de Geronimo contados?

En TheServerSide, se hacen eco de un rumor que viene circulando entre los usuarios de Geronimo: que los días de este servidor JEE están contados. De acuerdo a TSS, el patrocinio de IBM no ha sido el catalizador esperado para que por fin este servidor JEE de Apache despegara.

El problema es que IBM busca sobre todo potenciar su marca WebSphere y aunque le llama a Geronimo "Websphere Community Edition", no le da el apoyo ni la publicidad que a la línea tradicional de sus servidores JEE. Una de las pruebas de esto es que Geronimo pasó el test de certificación JEE 5 desde mayo de 2007 y aunque IBM anunció este hecho, no ha buscado capitalizarlo para no restar potenciales clientes a Websphere (del que por cierto no se tiene idea aún de cuando será JEE 5 certificado).

Desde que IBM tomó las riendas del proyecto, los commiters más activos del mismo son empleados del gigante azul; lo que ha ocasionado que Geronimo se mueva siempre a donde le conviene a la empresa. Por ello, los usuarios y los desarrolladores sienten que se ha detenido la innovación dentro del proyecto y se ha hecho más enfoque en desarrollar  compatibilidades con otros productos de la rama Websphere. De tal suerte que Geronimo está quedando a la zaga de otros servidores java opensource como Glassfish, Jetty y JBoss que continuan buscando la innovación y mejora de su producto.

Mala suerte para Geronimo, un proyecto que estuvo mucho tiempo sin avanzar dentro de las filas de Apache y al que al parecer IBM podría al fin rescatar. Por otro lado, las apuestas de IBM de dar apoyo a proyectos opensource para competir a Sun como Geronimo y Harmony parece que no le han salido bien. Menos mal que al menos Eclipse sigue rodando.

Escalando aplicaciones Comet con Jetty

Greg Wilkins, del Blog Comet Daily, ha publicado un interesante artículo sobre Dojo Cometd y el servidor Jetty. Este framework es una implementación de Comet (también llamado Reverse Ajax) patrocinado por Dojo y que busca, entre otras metas, lograr una implementación de Comet escalable a los requerimientos actuales de las aplicaciones web.

En el artículo enlazado, se anuncia que la versión actual de Cometd ha logrado en benchmarks servir a 20 000 usuarios concurrentes gracias en gran parte a usar el servidor web java Jetty. Para los que no lo conozcan, Jetty 6 ofrece Continuations, un patrón para gestionar las peticiones al servidor que permite suspender un request (liberando el thread que lo atiende) y recuperarlo más tarde; lo que permite atender más peticiones con un menor número de threads en comparación a otros métodos.

Los datos del benchmark puedes descargarlos en el artículo. A mi realmente me sorprendió la escalabilidad lograda, al parecer Jetty 6 se está volviendo una gran opción para escalar aplicaciones Ajax y Comet, no hace mucho poco Zimbra también hizo el cambio por estas razones. ¿Alguno de ustedes usa Jetty?

DJ Project, integración de navegadores web y reproductores flash en aplicaciones Swing

DJ Project es un proyecto libre que proporciona herramientas y librerías para apoyar el desarrollo de aplicaciones de escritorio Java. DJ Project - Native Swing es una parte del anterior proyecto que pretende facilitar la integración de componentes nativos en aplicaciones Swing, especialmente la integración de navegadores web y reproductores de Flash. DJ Project Native Swing trata de proporcionar un API para los componentes nativos similar a las API que suelen proporcionar los componentes Swing y, según los creadores, resuelve de un modo transparente para el programador todos los problemas relacionados con multithreading. Nuevamente según los creadores del proyecto, éste es uno de sus puntos fuertes respecto al componente JDIC Browser de Swing Labs.

Aquí podéis ver unas capturas de pantalla y aquí podéis lanzar una demo (sólo para Windows de 32 bits) del proyecto.

¿Cuántos os habéis visto en la necesidad de integrar un componente nativo en una aplicación de escrtorio? ¿Qué solución usastéis para ello?

actualización 1.4.1 de OpenSwing, framework libre para el desarrollo de aplicaciones Swing

OpenSwing es un framework para el desarrollo de aplicaciones swing, tanto para aquellas que no se comunican con una base de datos como para aquellas aplicaciones de dos o tres capas cuyo front end es una aplicación de escritorio. El framework incluye un conjunto de componentes gráficos implementados en Swing orientados a la visualización de datos entre los cuales hay componentes para mostrar cantidades de dinero, grids, un componente híbrido entre un árbol y un grid, calendarios, diagramas de Gantt y un largo etcétera.

OpenSwing también cuenta con una librería para el desarrollo de la capa de acceso a datos y (para las aplicaciones de tres capas) la lógica de negocio, así como una librería que se encarga de simplificar la comunicación con el servidor. También cuenta con componentes para visualizar documentos PDF y Excel. El framework se distribuye bajo licencia LGPL y cuenta con abundante documentación entre la cual se incluyen varias aplicaciones de demostración.

Algunos acoplamientos:

Home page: http://oswing.sourceforge.net

Demo: http://oswing.sourceforge.net/demo10/demo10.jnlp 

JAllInOne demo: http://www.hostingjava.it/-carniel/jAllInOne.jnlp