SwingWT 0.77 disponible

Una de las discusiones más de moda en la actualidad dentro del mundo Java es sin duda la si se debe utilizar Swing para crear interfaces de usuario o si es mejor utilizar algo como SWT.



SwingWT es un framework que busca hacer sencilla la migración de aplicaciones ya desarrolladas utilizando Swing a SWT. Más concretamente, se trata de un clon de Swing, es decir, de un API exactamente igual, pero que utiliza como base componentes nativos desarrollados en SWT en lugar de utilizar componentes Java.



Como garantía de su funcionamiento, el autor nos cuenta que fue capaz de migrar todos sus proyectos realizados en Swing, a SWT, sin tocar ni una sola línea de código, exceptuando por supuesto las sentencias import para importar las nuevas clases en lugar de las viejas clases de Swing.



Entre las ventajas:



- Menos consumo de memoria

- Interfaz con una mejor respuesta al usuario

- Se mantiene el API de Swing

- Las aplicaciones existentes no necesitan ser reescritas

- Se pueden utilizar los diseñadores gráficos existentes

- Se pueden crear aplicaciones nativas con GCJ

- Se puede acceder directamente a los componentes SWT

- Se pueden crear aplicaciones para dispositivos móviles con Swing

- Nuevos componentes gráficos : pestañas que se cierran, barras de herramientas con soporte de menus, etc. etc.



El soporte de Swing es prácticamente completo, y tan sólo falta por añadir el soporte de impresión y el soporte de drag

Benchmark de Java vs .NET vs Phyton

Este artículo realiza una comparación entre diversos lenguajes de .Net (C#, J#, Visual C++ y Visual Basic), gcc, Python/Psyco, Python y las máquinas virtuales de Sun 1.3.1 y 1.4.2. Este micro-benchmark aborda cálculos con enteros, long, double, operaciones trigonométricas, y de entrada y salida.



En los resultados la máquina virtual 1.4.2, si no tenemos en cuenta las operaciones trigonométricas, donde es francamente pésima, vence a gcc y está a la par de Visual C++, el mejor lenguaje de .NET. En cuanto a Python/Psyco y Pitón, lenguajes totalmente interpretados, son un orden de magnitud más lentos que los lenguajes compilados. El comportamiento de la máquina virtual 1.4.2 en cuanto a las operaciones trigonométricas es francamente patético (unas tres veces más lento que la 1.3.1!!!). Probablemente se deba a un error en la programación de las rutinas trigonométricas en esa MV.



Como todo microbenchmark este debe tomarse con sumo cuidado, y no generalizar los resultados. Las pruebas sólo atañe a métodos estáticos, no hacen un uso intensivo de reserva y liberación dinámica de memoria, el testeo de la entrada y salida es muy básico, no se mide de ningún modo el rendimiento en multihilo



Y adicionalmente Christopher W. Cowell-Shah, autor de los test no, parece ser un experto en Java; no comprende porqué Java, siendo interpretado, vence a gcc, ya que "ejecutar código en una JVM debería introducir algún tipo de penalización en el rendimiento respecto a ejecutar ensamblador". Obviamente esto no tiene porqué ser así desde el momento que se emplea Hot Spot, ya que se emplea información sólo disponible en tiempo de ejecución para realizar optimizaciones adicionales en el código ensamblador generado por la JVM. También dice que JRockit, la máquina virtual de Bea, podría mejorar notablemente los resultados de Sun, cosa cierta, pero que "sólo está disponible para Windows", cuando JRockit está disponible también para Linux de 32 y 64 bits.



Aquí tenéis los códigos fuentes del benchmark. Yo lo he probado, y a modo de test he mirado como correría en JRockit 8.1 el código del becnhmark. JRockit 8.1 es equivalente a la JVM 1.4.1. Estos son los resultados que obtuve:



JDK de Sun int = 21.3, long = 46.6, double = 54.5, trigonometría = 113, I/O = 18.3, total = 258.



JRockit int = 18, long = 22, double = 52, trigonometría = 25.5, I/O = 15.3, total = 133.



Obviamente mis resultados no se pueden comprar con los del artículo; la máquina en la que se ejecutaron es mucho más lenta, sólo se pueden comparar entre si. No es ninguna noticia que el jdk de Sun no es el más eficiente; siempre es el primero en salir (aún no hay un JRockit equivalente a una JVM 1.4.2), pero no el más eficiente.



Observamos como la mejoría es especialmente notable en el cálculo trigonométrico, lo que refuerza la hipótesis de que se produjo un error en la JVM 1.4.2 de SUN al codificar las rutinas trigonométricas . JRockit, excluyendo las rutinas trigonométricas (sino sería el doble de rápido), emplea sólo un 75% del tiempo que necesita la JVM 1.4.1. Extrapolando esto al benchmark podríamos concluir que JRokit es notablemente más rápido que Visual C++.



¿Qué opináis vosotros de este benchmark y de mi humilde contribución?

Críticas a J2ME

John Drewry en este artículo realiza ciertas críticas a J2ME, resaltando los problemas y deficiencias que, según él, han provocado que J2ME hoy en día signifique prácticamente aplicaciones orientadas al ocio. Son muy escasas las aplicaciones de J2ME que van más allá de un juego, un ringtone, o a lo más una calculadora científica o una agenda personal, y según John Drewry esto se debe principalmente a:

• J2ME evoluciona, y ha evolucionado, muy lentamente. Algunos aspectos claves han tardado mucho en ser definidos por el JCP y otros aún se están definiendo.



• Las distintas implementaciones de J2ME a veces incorporan extensiones a la especificaciones que provocan incompatibilidades entre las aplicaciones desarrolladas para ese dispositivos y otros dispositivos J2ME compatibles.



• El sandbox es muy restrictivo y no hay modo de saltárselo. Para evitar que las aplicaciones Java dañen el teléfono móvil, o a su usuario, en algún modo, se ejecutan en un sandbox que limita lo que estas plicaciones pueden hacer. Así por ejemplo las aplicaciones J2ME no pueden efectuar llamadas, avisar al usuario que se está recibiendo una llamada, acceder al listado de las últimas llamadas... funcionalidad existente en otros entonos de desarrollo para móbiles como QUALCOMM o Symbian.

Para solucionar estos problemas el autor pide que se resuelvan las incompatibilidades entre los dispositivos, que se creen unas recomendaciones para el desarrollo de aplicaciones y que se busquen soluciones a las limitaciones del sandbox.

¿Qué opináis vosotros al respecto?

Actualización para SSL en Java

Hola,

En esta noticia de TheServerSide comentan que los certificados de Verisign que venían con el JDK hasta hace poco(versiones anteriores al JDK/JRE 1.4.2_03, 1.4.1_06 y 1.3.1_10) caducaban el 7 de Enero, así que multitud de sitios con SSL basado en Java con JDKs más antiguos se han quedado sin servicio.



Así que si os pasa, ya sabei:, A actualizarse tocan!

GIS en Java: GeoServer 1.1.0 ya disponible

El proyecto GeoServer es una implementacrión totalmente transacional de la especificacrión OpenGIS Consortium's Web Feature Server que documenta como ofrecer informacrión geogrýfica de una manera estándar a travýs de un servidor web.



Se trata de un producto totalmente libre, liberado bajo licencia GPL 2.0. El producto permite consultar y modificar datos geográficos de una manera estándar a travýs de Internet y se presenta como una gran alternativa a este tipo de servidores comerciales.



Para conocer más sobre GeoServer y comprender su importancia lo mejor es echarle un vistazo a su pýgina web donde hay extensa documentacrión y algún que otro FAQ.