Liberado FireFox 2.0

Cuando escribo estas líneas la página oficial todavía no ha sido actualizada, pero podéis descargar FireFox 2.0 desde este enlace. Parece que los chicos de Mozilla no se han querido quedar atrás después de que Microsoft liberase hace unos días Internet Explorer 7 .



Haciendo de abogado del diablo, ¿cuántas aplicaciones Ajax dejarán de funcionar correctamente al instalar estos navegadores?.

Groovy mató al fichero de configuración XML

El título de la noticia surge de parafrasear una entrada antigua de un weblog, quien a su vez se inspira en el título de la canción "Video killed the radio star". En la entrada del weblog el autor presentaba un proyecto, que no ha continuado manteniendo, que permitía "programar" los ficheros de configuración XML de una aplicación de Spring 1.0 en Groovy. También discute las ventajas de Groovy frente a XML para este tipo de aplicaciones. Probablemente este weblog es el primero en recoger esta idea.


Otro ejemplo de sistema que emplea en Groovy para describir su configuración es el proyecto Computecycles , proyecto que pretende permitir la construcción de Grids de bajo coste en los que cada servidor "busca" tareas para ejecutar cuando "no tiene nada que hacer" empleando la tecnología Jini para ello.


El proyecto Ant Scripting emplea la integración de Groovy con los lenguajes de marcado (GroovyMarkup) para permitir lanzar tareas Ant desde Groovy. Probablemente sea el esfuerzo más general la línea de convertir a Groovy en un lenguaje de configuraciones. Un proyecto similar, pero que ha escogido a Java como lenguaje de configuración, es Gosling; en este caso tengo dudas de si ese es el camino adecuado. Que el lenguaje de programación de configuraciones tenga un tipado fuerte puede convertirse en un lastre para la programación de los "script" de configuración.


La posible utilidad de este lenguaje de programación como sustituto para la "meta programación en XML" que se emplea en Ant, BEPEL ficheros de configuración de las páginas JSF... y otros muchos también ha sido ampliamente discutida en Artima, Theserverside y este mismo portal.



¿Creéis que de aquí a unos años Groovy habrá sustituido a XML como lenguaje preferido para describir configuraciones dentro de la plataforma Java? ¿Alguna vez habéis echado de menos la potencia expresiva de un lenguaje más procedural al describir configuraciones en XML?

Barbecue 1.5: Códigos de Barra en Java

Barbecue es un desarrollo de código libre para generar códigos de barra. El proyecto viene con una serie de formatos de este tipo de códigos listos para usar y permite incluir nuevos tipos gracias a un API extensible.



Barbecue puede generar los códigos de barra en formato de gráfico (JPG, PNG o GIF), como un componente Swing o SVG.

Quinto aniversario de Eclipse

Han pasado ya cinco años desde que IBM donó el código de Visual Age (en realidad fue de Visual Age Micro Edition) y formó el consorcio Eclipse en conjunto con otras compañías con el fin de continuar el desarrollo de esta herramienta para crear desarrollos en Java.



El consorcio se volvió una organización no lucrativa en 2004 y cambió su nombre a fundación Eclipse. Es a partir de este momento que Eclipse se vuelve más independiente de IBM y lanza su versión 3.0 que gozó de inmediato de gran popularidad entre los desarrolladores.



Sin duda, el gran acierto de Eclipse fue ser una plataforma open source que permitía su extensión fácil a través de plug-ins, lo que provocó que rápidamente se crearan plugins para todas las etapas del desarrollo en java e incluso para otros lenguajes como C/C++ y Ruby.



Por cierto, el nombre se eligió por que el objetivo era crear un IDE "capaz de Eclipsar a Visual Studio" de Microsoft.



Cinco años después, este IDE puede presumir de haber sido todo un éxito y ser precursor de la estrategia open-source que las grandes compañías usan hoy. Para celebrarlo, se organizarán fiestas alrededor del mundo, la lista de las cuales puede verse en el enlace que acompaña esta noticia. Ninguna fiesta será en la región de Hispanoamérica, ya ven, eso se ganan por preferir NetBeans.

Tirón de orejas a la JSR277 por parte de la OSGI

Peter Kriens, de la OSGI, ha evaluado el borrador de la JSR 277 (la que propone cómo será el nuevo sistema de módulos de Java), y su crítica es bastante dura. En el resumen que aparece en java.net, se dice:



"The ambition level of JSR 277 is significantly lower than where the OSGi specifications are today, even way lower than we set out in 1998. In a way, for me the JSR 277 proposal feels rather toyish. The Expert Group took a simplistic module loading model and ignored many of the lessons that we learned over the past 8 years."



En mi opinión, la apropiada resolución de este problema es uno de los aspectos que más influirá en el futuro de Java y que deberá además disminuir las reticencias a la hora de adoptar Java.

Por lo tanto, creo que debe hacerse con sumo cuidado: nos jugamos mucho...



¿Qué opináis vosotros? ¿No se anima nadie a echarles una mano a estos muchachos y mejorar la especificación? (todo el muno está invitado).



Saludos.