Java 6 podría requerir una actualización del SO en Mac

Empieza a haber rumores en Internet de que Apple podría no portar Java 6 para versiones anteriores a Leopard de su sistema operativo. Leopard será la siguiente versión de Mac OS y todavía no sea liberado. Esto forzaría a los usuarios de Mac que quieran emplear Java 6 a pagar por la actualización del sistema operativo.



Esto ya ocurrió con Java 5 y la versión actual de Mac OS. En la que justificación oficial es que el portar Java 5 a versiones anteriores llevaría una gran cantidad de trabajo debido a la gran cantidad de cambios que había en Java 5. Sin embargo, en esta ocasión los cambios no son tan radicales. Básicamente, son más librerías (que no tendrán que portar) y mejoras de rendimiento la máquina virtual.

Poseidón 5.0

Gentleware ha anunciado la versión 5.0 de su herramienta para modelado UML Poseidón. La herramienta está programada en Java y probablemente sea una de las herramientas de modelado UML más empleadas dentro de la comunidad Java. Además de varias mejoras en la interfaz gráfica (sobre todo en lo relativo a la navegación entre diagramas) la característica estrella de la nueva versión es el soporte de UML 2.0.



Lo que echo de menos en la nueva versión es soporte completo para Java 5.0. La última vez que probé la herramienta no tenía soporte para tipos genéricos, y con esto no quiero decir que no los pintase en los diagramas de clases sino que si tu código emplea genéricos no vas a poder trabajar con esta herramienta sobre él.



Después de ya dos años el soporte de las herramientas de modelado UML para los tipos genéricos de Java 5 deja bastante que desear (al menos según mi experiencia). Las herramientas que proporciona Netbeans son las únicas libres o gratuitas que yo conozco que permiten trabajar con los genéricos. En el pasado he tenido que recurrir a herramientas propietarias como la de Altova o a de Visualuml para estas tareas.



¿cuál es nuestra experiencia al respecto?.

Más sobre Java Media: VLC Java Bindings

Siguiendo un poco las noticias recientes sobre el soporte multimedia en Java, se ha presentado el proyecto Bindings para VLC. Como muchos de ustedes sabrán Videloan (VLC) es un popular reproductor de videos cuya principal característica es que no necesita de códecs externos para poder reproducirlos.



El objetivo de este proyecto es lograr empotrar un reproductor de video de forma fácil en aplicaciones java. Por ahora van en la versión 0.0.9 , pero ya han liberado una primera versión del reproductor (JVLC) que funciona en Windows y Linux.



Dado el poco interés que Sun le ha dado a este tipo de soporte para Java, los desarrolladores tenemos que buscar otras alternativas como FMJ o las ya casi abandonadas librerías Quicktime de Apple, ahora podemos agregar una más que se apoya en uno de los reproductores de videos más potente del mercado. Quizás el panorama no es tan negro como pareciera a primera vista.

GWT se libera bajo licencia Apache

Google acaba de anunciar que GWT va a pasar a distribuirse bajo licencia Apache 2.0. Esa licencia se aplica ya a la versión 1.3 RC, versión que no incorpora absolutamente ninguna novedad respecto a la anterior y que ha sido creada con el único propósito de cambiar el modelo de licencia del proyecto y de facilitar su compilación por terceras partes.



Hasta ahora las librerías de GWT se distribuían bajo licencia Apache, pero el compilador que genera javascript a partir de código Java y el plugin de Eclipse que permite depurar la interfaz de la aplicación web como código Java (y no como HTML y javascript) eran propietarios.



Es una excelente noticia. La verdad, este tipo de movimientos me sorprenden: hace poco más de seis meses que anunciaban GWT y ahora deciden hacer un cambio tan radical en la licencia. ¿Por qué? ¿Qué es lo que ha cambiado desde entonces?. Son preguntas filosóficas, pero me intrigan.

W3C XML Schemas (XSD) apesta, Tim Bray

Esa afirmación aparece recogida en una entrada realizada a principios de este mes en el weblog Tim Bray, a quien puede considerarse como uno de los padres del XML. Según él los Schemas son difíciles de crear, de mantener e entender y han demostrado ser una idea fallida. Es hora de abandonarlos y moverse a algo nuevo.


Lo nuevo que él propone es RELAX NG (REgular LAnguage for XML Next Generation), un lenguaje que permite especificar la estructura de un documento XML mediante patrones. Posee dos sintaxis equivalentes; una de ellas es XML mientras que la otra (mucho más compacta que la anterior) no.


Nunca he trabajado mucho con XML. Cuando lo he hecho en 90% de lo que quería expresar se podía expresar adecuadamente en una DTD. Y para el 10% restante nunca consideré que me "mereciesen la pena" pelearme con los Schemas, así que no realizaba la validación en el código Java. Dada mi falta de práctica con el XML siempre creí que la gran dificultad de los Schemas surgía de mi ignorancia; sin embargo ahora empiezo a pensar que quizás en muchos contextos "no merece la pena" pelearse con Schemas.