viernes, junio 26, 2009 at 9:37AM Desde el pasado día 24, está disponible Galileo, la versión 3.5 de Eclipse con importantes novedades.
jueves, junio 25, 2009 at 9:53AM aTunes es un clon de iTunes implementado en Java y distribuido bajo licencia GPL. Soporta los formatos mp3, ogg, wma, wav, flac, mp4, m4a, ra, rm y cue, además de radios de Internet. Tiene soporte para las etiquetas de dichos formatos, tanto para leerlas como para modificarlas.
Cuenta con soporte para podcasts, tiene múltiples opciones para crear listas de reproducción y para navegar por las colecciones de audio y, obviamente, soporta sincronización con múltiples reproductores de MP3.
Francamente me ha sorprendido el ver una aplicación Java de escritorio tan orientada al mundo multimedia y con un acabado tan pulido. ¿Por casualidad alguien por aquí ha usado aTunes?
jueves, junio 25, 2009 at 9:50AM Simon es una API para monitorizar partes de una aplicación; esto es, para tomar medidas de interés sobre partes de la aplicación. Los "monitores" de Simon deben ser insertados en el propio código, y puede decidirse si se desean activar o no en cada ejecución.
Sus autores no la describen como una herramienta de profiling, ya que el propósito de estas herramientas es mejorar el rendimiento de la aplicación. Simon tiene un propósito más genérico: simplemente monitorizar; tú decides qué es lo que quieres monitorizar.
Simon se distribuyen bajo licencia LGPL y acaba de liberar su versión 2.0.
miércoles, junio 24, 2009 at 10:54AM OSGi (inicialmente las siglas de Open Services Gateway Initiative, aunque ahora ya sólo son "OSGI") es un grupo de estándares que han definido un modelo de componentes modulares que definen el ciclo de vida de los componentes, proporciona un registro para ellos y proporciona un entorno de ejecución. Se trata de una tecnología muy madura y probada en la cual se basa, entre otros muchos, Eclipse.
El JSR 294 tiene como propósito mejorar el soporte para modularidad dentro de la plataforma Java. Su propósito es que sea posible distribuir tanto la máquina virtual, como las librerías estándar, como tu propia aplicación en módulos que puedan descargarse bajo demanda y que se integren adecuadamente con los mecanismos de gestión de aplicaciones nativas. Una de sus ventajas, al modularizar la máquina virtual y las librerías estándar, será una mayor velocidad de arranque de la máquina virtual al tener un control más fino sobre qué es necesario cargar y qué no. Ahora mismo, Sun considera esto como crítico para su negocio, para conseguir que JavaFX sea realmente competitivo con otras alternativas como Flash, que en la actualidad resultan mucho más "ligeras".
Jigsaw podría considerarse como la implementación del JSR 294 que Sun está creando para su JDK 7.
Terminadas las presentaciones, pasemos al motivo de la polémica. Desde el campo de OSGI se ve con buenos ojos al JSR 294, pero se critica que su implementación (Jigsaw) no se base en OSGI. Esto ha dado lugar a una "guerra" entre los defensores de OSGI y Sun; los primeros acusan a Sun de querer reinventar la rueda y de no basarse en una tecnología ya probada.
Este ya viejo debate se ha reavivado recientemente por las (bastante poco acertadas) palabras de Gosling donde afirma que el problema con OSGI es que es demasiado pesado, y que Jigsaw hará lo mismo que OSGI, pero será más ligero. Esto no es correcto del todo.
Recientemente Javaposse ha entrevistado a Mark Reinhold, Chief Engineer de Java 2 SE, sobre este tema. De todo lo que he leído sobre la polémica entre OSGi y Jigsaw, esta entrevista es de lo mejor. En ella se explica claramente que OSGI y jigsaw se solapan, pero no completamente. El primero hace muchas cosas que Jigsaw no necesita. Y el segundo necesita varias cosas que no están contempladas en OSGI.
Dos ejemplos concretos son la necesidad de cargar en un mismo cargador de clases dos clases que pertenezcan a módulos diferentes pero estén dentro de un mismo paquete Java (necesario para modularizar las librerías estándar). Otro problema de OSGI es que no se integra bien con los sistemas de gestión de paquetes de los sistemas operativos (necesario para mejorar la integración de las aplicaciones Java con los sistemas operativos). Por otro lado, hay cosas que aunque con OSGI son factibles, pero muy complicadas, como por ejemplo que el compilador explote la información relativa a los módulos en tiempo de compilación.
En la entrevista Mark Reinhold afirma que el único motivo por el cual están construyendo Jigsaw es porque no les queda más remedio, y que si OSGI les sirviese por supuesto que lo habrían utilizado, del mismo modo que los desarrolladores de Glasfish decidieron que OSGI era precisamente lo que necesitaban para el servidor de aplicaciones.
Definitivamente recomiendo el podcast a todos los interesados en este tema. Y, desde mi punto de vista, esta entrevista zanja definitivamente la polémica OSGi vs Jigsaw.
martes, junio 23, 2009 at 10:00PM Saludos. Como lo prometido es deuda, para la gente que acudió al taller y para la que no, he colgado el material del taller que impartí en el pasado evento de Sun.
Lo podeis encontrar aquí: información del taller, de donde os podeis descargar tanto la presentación que usé como guión como las aplicaciones de ejemplo. No olvideis seguir las instrucciones de instalación antes de juguetear con ellas :).
En fin, espero que le sirvan a alguien.
Y ya puestos, ¿Algún comentario de los asistentes al taller?
Por mi parte disculparme por los problemas que hubo al traspasar los ficheros por un USB que corrompió algunos XML y he de decir que para la próxima vez quizá distribuya el material pero las prácticas han de ser mucho más simples o necesito muucho más tiempo, ya que practicar y escuchar una presentación al mismo tiempo es demasiado pedir para los asistentes. Al final fue casi todo escuchar para vosotros, pero espero que al menos os diera algunas ideas y que con el material que publico ahora os sirva para probarlo si conseguir que os picara el gusanillo ;).
Por último agradecer la oportunidad tanto a JavaHispano, en especial a Abraham, y a Sun. Espero haber estado a la altura.
S!