Oracle cuestiona la liberación de Java bajo GPL

Primero fue IBM en la que se quejó de que no le gustaba la licencia que Sun había empleado para liberar a Java. Ahora Oracle se une a la queja. Los argumentos son exactamente los mismos: que la licencia GPL es incompatible con la que emplea Harmony y Eclipse (cuando hablan de eclipse supongo que la única parte que les interesa es el compilador, ya que Eclipse implementa su propio compilador). Según Oracle, e IBM, estos dos proyectos son el principal esfuerzo de la comunidad para conseguir una implementación de Java SE libre y la licencia que ha elegido Sun impide que haya sinergias entre la implementación de referencia y estos proyectos.



Nuevamente, Oracle se olvida de que los proyectos en los que ella participa, si bien quizás para ella sean los más importantes, no tienen porqué ser "el mayor esfuerzo de la comunidad para conseguir una implementación de Java SE libre". Como ya mencioné en su día, Harmony es una promesa de futuro que aún no ha dado prácticamente ningún fruto y en el caso de Eclipse sólo estamos hablando de un compilador. Kaffe, GCJ y Classpath son los que hasta la fecha han permitido (y por lo de ahora siguen permitiendo) que las aplicaciones Java se ejecuten en Linux sin emplear software propietario. Ellos son hechos y no promesas. Ellos sí son el mayor esfuerzo de la comunidad. Y todos ellos son GPL.



Yo también quería una licencia tipo Apache, igual que IBM y Oracle. Aunque por motivos diferentes. Lo mío es cuestión de ideología. Sin embargo, lo de ellos es una cuestión puramente económica. Lo que a ellos les duele es que van a seguir teniendo que pagar a Sun por el código de la implementación de referencia de Java EE (y probablemente también por la de Java SE). No les queda más remedio. Sus servidores de aplicaciones son propietarios. Y no se les va a pasar por la cabeza hacerlos GPL. Así que no podrán usar el código GPL y tendrán que seguir empleando el código SCSL, como hasta ahora, y pagando por él.



Supongo que cuando piensan que si Sun hubiese liberado sus implementaciones bajo licencia Apache podrían coger el código y emplearlo en sus implementaciones sin pagar un duro...

El fundador del Java Community Process deja Sun

Graham Hamilton, fundador del Java Community Process, dejó Sun la semana pasada de un modo un tanto discreto. La compañía se ha negado a dar explicaciones de por qué Hamilton ha dejado su puesto (era uno de los vicepresidentes); simplemente se ha limitado a agradecerle todas las aportaciones que a lo largo de los años ha realizado.



Hamilton no era favorable a la liberación de Java ya que creía que de este modo se correría el riesgo de perder la compatibilidad en la plataforma. Por lo de ahora no está claro si esto ha sido lo que le ha impulsado a dejar la empresa.

JavaSVN cambia a SVNKit

JavaSVN ha sido una librería opensource para interactuar con repositorios de subversion a través de java. Esta librería es usada por algunos plugins como subversive y subeclipse para añadir soporte a este controlador de versiones en Eclipse.




Los desarrolladores han liberado la versión 1.1 y han aprovechado para cambiarle el nombre a su producto a SVNKit en respuesta a la petición que Sun les hizo ya que no es posible utilizar el nombre Java en un producto; lo que es coherente con el anuncio de Sun de que después de la liberación de Java ocurrida hace unas semanas se iba a vigilar de forma más estricta la protección de la marca. Por otra parte, esta nueva versión incluye soporte completo para subversion 1.4. Si quieren descargarla desde Eclipse, es necesario cambiar el antiguo repositorio de esta API a http://www.svnkit.com/ .

¿Estamos preparados para el SOA?

Me llama la atención un artículo de JavaWorld "SOA for the real world" y sobre todo esta imagen . En ella se muestra un sistema de servicios y registros SOA, básicamente servicios web (se incluye también el posible papel de servicios a medida) orquestados a través de BPM.



No discuto que es probable que los sistemas software del futuro sean así (de forma habitual), ahora bien, la arquitectura no es totalmente nueva, pues recuerda al mundo de servicios CORBA + algún sistema de workflow (existen estándares basados en CORBA), cambiando CORBA por servicios web y workflows CORBA por BPMs basados en XML/web services tenemos más o menos lo mismo (salvando las diferencias).



Si los sistemas CORBA+workflow no tuvieron gran éxito (salvo temas de firewalls nada impedía este tipo de tecnologías en sistemas más o menos acoplados), en un mundo en donde todavía abunda el paradigma cliente/servidor (por mucha tercera capa añadida para las aplicaciones web) en donde el verdadero centro sigue siendo la base de datos...



¿existe demanda de verdad de implantar este tipo de sistemas?



¿la habrá?



¿hay experiencias de éxito?



Nota: cuando me refiero a workflow me refiero a la capacidad de un sistema software de poder definir *y cambiar* de forma casi o exclusivamente visual el comportamiento del sistema, no a un flujo de pasos codificado a medida.

Virtual ant, la herramienta más simple para construir scripts ant

Hacía tiempo que una herramienta no me impresionaba tanto. Virtual ant permite construir scripts ant sin necesidad de escribir ni una sola línea XML o sin necesidad de aprender a emplear ningún tipo de asistentes. Virtual ant crea un sistema de ficheros virtual, que replica tu sistema de ficheros, para el cual proporciona una interfaz similar a la que cualquier sistema operativo proporciona para interaccionar con el sistema de ficheros (una herramienta similar al explorador de Windows).



En ese sistema virtual de ficheros el programador simplemente mueve ficheros, copia, crea archivos .jar de un modo intuitivo,... sin que todas estas acciones afecten al sistema de ficheros real. Virtual ant graba en una macro todas las acciones que realiza. Una vez el programador ha terminado de interactuar con el sistema de ficheros la herramienta genera un script de ant que reproduce todas las acciones realizadas por el programador. También es posible ejecutar scripts ant sobre el sistema de ficheros virtual, sin que realmente modifiquen nada en el sistema de ficheros real, para ver sus efectos.



Por lo de ahora la herramienta no se encuentra completamente terminada y no se puede descargar, sólo hay un vídeo demostración. Pero es bastante impresionante.



Ahora vienen las malas noticias. La herramienta será una herramienta comercial. De todos modos, viendo el precio de otro producto ofrecido por la compañía (20 $) me atrevo decir que su precio final no será prohibitivo.