Garbage collectors

Como parte de un trabajo para una asignatura del doctorado que estoy realizando actualmente he tenido que mirarme con detalle el funcionamiento del GC en plataformas de alto rendimiento.

La información encontrada me ha sorprendido, ya que incluso a partir de un par de procesadores el funcionamiento "por defecto" de la VM puede no ser óptimo en absoluto. Una máquina biprocesador o tetraprocesador puede parecer no muy habitual ahora, pero con los nuevos procesadores multinúcleo estó será cada vez más frecuente.

Os dejo parte de esta información.

java.nio

La nueva libreria de entrada/salida introducida con la versión 1.4 de Java es una de esas novedades que ha pasado un poco desapercibida.

La principal razón es que su utilidad se encuentra realmente en un segmento bastante específico de aplicaciones. En realidad, cualquier aplicación podria beneficiarse de un aumento de velocidad usando NIO, pero como las librerias clásicas de entrada/salida ya utilizan parte de las novedades internamente, la ventaja se nota con el simple uso de la version 1.4


Se pueden resumir las ventajas de java.nio en dos principalmente:

• E/S multiplexada, no bloqueante
• Acceso a buffers directos (zero copy)

Básicamente las aplicaciones que comento que pueden beneficiarse son principalmente aquellas con gran E/S y muchas conexiones simultaneas (java.nio rompe el 1:1 entre hilos y conexiones entrantes).

JavaOne 2003 Technical Session (Benchmark)

• Apache 2.0.42 for small file (1 KB)
• thttpd 2.20c for large file (1 MB throttled to 56kb/sec)
• Java 1.4.2 amb java.nio i java.io
• Multi-Threaded Pool (java.io)
• 2+2 Threads java.nio (2 acceptors + 2 dispatchers)

La versión clásica con java.io obtenia un rendimiento equiparable a los otros dos productos, sin embargo su consumo de memoria crecia linealmente con el número de conexiones hasta llegar a los 600MB cuando el thttpd consumia sólo 8.

La versión java.nio con selector no bloqueante ofrece un rendimiento a la par con las otras soluciones y un uso de memoria fijo que no aumenta con el número de conexiones.

• http://www.theserverside.com/articles/article.tss?l=JavaOneDayTwo_03
• http://gee.cs.oswego.edu/dl/cpjslides/nio.pdf

Instalación de Tomcat 5 bajo Debian

A raiz de un mensaje en la lista de correo de usuario de Debian en catalán he publicado un nuevo artículo que tenía por aquí hecho sobre la instalación de Tomcat 5 en un Debian. Sencillito, pero contiene más o menos lo necesario.

Espero que os sea de utilidad. Los comentarios y sugerencias, donde siempre.

Reserva de objetos en Java

Otro interesante artículo de Brian Goetz de IBM que destruye otra de las leyendas urbanas relativas al rendimiento de la plataforma Java: la gestión de memoria. Habitualmente se ha comentado que la construcción de objectos y, sobre todo, el trabajo del garbage collector implicaban un deterioro importante en el rendimiento.

Tal como el autor especifica en el artículo, no solo esto es falso, sino que es más conveniente crear y destruir objetos con frecuencia que mantener un pool de los mismos.

Sorprendente...

Java vs C (rendimiento)

Realmente nada nuevo bajo el cielo como comentan en este artículo sobre el rendimiento de Java vs C publicado en javaHispano.

Están prácticamente igualados, apenas C rebasada Java en algunos campos, y en otros Java rebasa a C. Desde luego el rendimiento hace tiempo que no es un factor para la elección del lenguaje de programación (rendimiento de ejecución se entiende).

JSP 2.1 y JSTL 1.2

Siguiendo con las novedades en las especificaciones J2EE Web Tier, las especificaciones de JSP y JSTL no presentan prácticamente ninguna novedad salvo adecuarse al nuevo documento de especificación del lenguaje EL.

En esta parte es donde si han habido cambios, ya que se han incorporado al EL cambios que ya había adoptado JSF.

Para empezar, ahora las expresiones no son sólo ${} sino también #{} aunque en la especificación se indica que ambas son equivalentes y que la diferencia depende del entorno en el que se utilicen (por ejemplo Faces utiliza #{} para expresiones con evaluación diferida).

Se ha ampliado bastante la sintaxis básica. Anteriormente (con JSP 2.0) el EL sólo permitia producir rvalues. O sea, expresiones que devuelven un valor. Ahora es posible indicar también rvalues y métodos. Un ejemplo tomado de la propia especificación (ejemplo de JSF):

<h:form>
<h:inputtext
id="email"
value="#{checkOutFormBean.email}"
size="25" maxlength="125"
validator="#{checkOutFormBean.validateEmail}"/>
</h:form>

En este ejemplo #{checkOutFormBean.email} es un rvalue ya que no representa un valor sino una propiedad del bean a la que ha de darse valor según el campo de formulario. En el caso de #{checkOutFormBean.validateEmail} hace referencia a un método que se invocará para validar ese campo.

Realmente un cambio centrado en el EL que lo va a convertir en una herramienta aún más util.

Nuevas especificaciones J2EE

Siguiendo los Java Community Process se han publicado versiones casi definitivas de las principales especificaciones relacionadas con las aplicaciones web J2EE: JSP 2.1, Servlet 2.5 y JSTL 1.2 (también Java Server Faces pero no la comentaré en esta ocasión).

Comenzando con los JSP 2.1 lo primero que llama la atención es que el Expression Language pasa a un plano mucho más activo, disponiendo de una especificación separada de la de JSP. El nuevo EL (versión 2.1) se produce con la unión de los esfuerzos de los grupos de desarrollo de la especificación de JSP y JSF.

Revisando la especificación se ve el único cambio de importancia es el nuevo EL (ahora lo revisaremos). Sin embargo me llama la atención una nueva directiva para páginas JSP que permite eliminar las lineas que sólo contengan espacios en blanco. Me parece una buena adición, porque realmente al utilizar muchos tags y estructuras de control de JSTL se acaban generando muchas lineas en blanco que lo único que hacen es aumentar el peso de la página que se ha de servir.

Otra pequeña sopresa oculta: JSP 2.1 requerirá JSE 5 (o J2SE 5.0 si queréis), así que entre otras cosas en la especificación se hace alguna referencia los genéricos y su uso en el EL.

Más tarde recojo las impresiones del resto de especificaciones (son documentos largos!).

AjaxTags 1.0

Esta mañana he leido en Ajaxian Blog la release estable de esta libreria de tags para JSP con componentes Ajax.

Son las 18:44 y ya lo he integrado en un par de páginas de la aplicación web que estoy desarrollando. Excelente!

Via:

• Versión Cero
• Ajaxian Blog
  

Ruby on Rails vs J2EE

Yo acostumbro a desarrollar aplicaciones web bajo J2EE (Java). Pero siempre es bueno tener un ojo puesto en todas las tecnologias alternativas, aunque sea para descartarlas (o tener argumentos en una discusión!)

Una tecnologia que lleva un tiempo atrayendo mi atención es Ruby on Rails (RoR). Es un framework completamente nuevo específico para desarrollo de aplicaciones web. Además, es uno de los primeros que más uso de AJAX está efectuando.

Finalmente alguien se ha decidido a hacer una buena comparativa. Si alguien está interesado, aquí está Ruby on Rails vs J2EE.

Tomcat Deployer

Cuando necesito simplemente un servidor para aplicaciones web (un contenedor de servlets J2EE) suelo utilizar el Apache Tomcat, actualmente la versión 5.0 (aún no he pasado a la 5.5 porque está diseñado para J2SE5 y no veo que aún sea momento de pasar a esa versión de Java).

Pues bien, para mis clases muchas veces me es necesario entregar una "solución" en forma de aplicación web pero sin entregar nada de código. Tal como se hacen los deployments habitualmente de las aplicaciones web es fácil pasar sólo el código de servlets y otras clases (bajo /WEB-INF/classes) pero no es fácil para JSPs... hasta ahora.

Si os fijáis en las descargas del Tomcat (la última estable de la versión 5.0 es la 5.0.28) además del servidor en sí hay tambien una descarga que reza algo así como deployer. Descargando y descomprimiendo ese fichero disponemos del Tomcat Client Deployer que entre otras cosas es capaz de validar y compilar una aplicación web. Si no queréis ni cambiar la configuración, es tan sencillo como crear un directorio ./myapp y ejecutar 'ant' en el directorio (para el target por defecto del build.xml).

El resultado será un directorio ./build/webapp con la aplicación compilada y desplegada (y también en un .war). Aunque aún veamos los JSP, se pueden borrar puesto que ahora estan compilados y además se ha modificado el web.xml para que apunte a los servlets generados.

JavaServer Faces

Uno de mis principales trabajos consiste en implementar aplicaciones web. Para ello, utilizo JSP + Servlets + JSTL utilizando un modelo MVC "a mi estilo". Muchas veces añado otras librerias de tags de la Taglibs de Jakarta.

Andaba buscando una libreria de tags para publicar rápida y fácilmente tablas, cuando he topado con un tag de JavaServer Faces. Esta tecnología nunca había atraído mi atención, porque pensaba que sustituía a los JSP y a mi ya me va muy bien el planteamiento que utilizo para las aplicaciones web. Sin embargo, he echado un breve vistazo a sus características y me ha atraido la idea.

Cuando tenga un rato tengo que echarle un vistazo a fondo y probarlo.