El OpenSolaris Governing Board lanza un ultimátum a Oracle

O dejas de ignorarnos, o hacemos las maletas y nos vamos para casa. Esta es, básicamente, la posición del OpenSolaris Governing Board, el cuerpo que se encarga de supervisar y dirigir la dirección del proyecto opensource OpenSolaris. Las relaciones entre la comunidad de OpenSolaris y Oracle han sido bastante frías desde la adquisición de Sun. 

Uno de los principales puntos de fricción es el hecho de que Oracle no parece tener ninguna intención de permitir despliegues de cualquier forma de Solaris de modo gratuito. Solaris ha pasado a ser una de las piezas centrales del stack integrado que quiere construir la compañía y no está dispuesto a regalarlo.

La gota que colmó el vaso fue el hecho de que a una reunión del OpenSolaris Governing Board a la que debía haber asistido un alto ejecutivo de Oracle el ejecutivo no asistió, y la compañía no dio ninguna explicación de la ausencia. En esa reunión, el Comité debatió las tres posibles opciones que tenían: no hacer nada y seguir esperando a que Oracle tome una decisión de un modo más claro; intentar reavivar por su cuenta la comunidad (francamente, creo que aunque quisieran hacer esto no tienen medios para ello) o darle un ultimátum a la compañía.

Tras debatir, se han decantado por esta última opción. Si Oracle no establece una conversación de modo estable con ellos antes del 23 agosto, día del cual tienen prevista su próxima reunión, en esa reunión disolverán el OpenSolaris Governing Board y devolverán todo el control sobre OpenSolaris a Oracle.

Las cosas no pintan nada bien para la comunidad de OpenSolaris...

Los tweets más populares del último mes

Aquí tenéis los 10 tweets que han despertado más interés en la cuenta de Twitter de javaHispano del último mes. En este último mes, también pasamos la barrera de los 1000 seguidores en la cuenta. Muchas gracias a todos los que nos seguís a través de este medio.

1. http://ow.ly/223WL	10 libros de programación modernos que te ayudarán a ser un mejor programador http://ow.ly/223WL
2. http://ow.ly/27nJ9	cómo funciona Google en una imagen http://ow.ly/27nJ9
3. http://ow.ly/283bG	Interesante artículo sobre cómo conseguir ser un programador excelente http://ow.ly/283bG
4. http://ow.ly/295BU	Tras 3.5 años vendiendo móviles en BestBuy, un empleado explica porqué la gente compra el iPhone (humor) http://ow.ly/295BU
5. http://ow.ly/23Zkr	Fotografías/retratos de las que probablemente son las siete mujeres programadoras más famosa de la historia http://ow.ly/23Zkr
6. http://ow.ly/22f74	La fundación Eclipse acaba de anunciar Eclipse Helios http://ow.ly/22f74
7. http://ow.ly/24xGi	Comparativa de rendimiento entre Java y C++; cada uno gana en diferentes campos pero básicamente empatan http://ow.ly/24xGi

8. http://ow.ly/2aFY8	¿Te has preguntado alguna vez cuántas líneas de JavaScript tiene Gmail?443.000; 978.000 con comentarios http://ow.ly/2aFY8
9. http://ow.ly/28z6Z	En los comentarios de la noticia, buenas recomendaciones sobre libros de programación

Google App Inventor para Android, una revolución de la programación de terminales móviles

Google App Inventor para Android es una herramienta WYSIWYG para crear aplicaciones para Android. Hasta aquí, nada nuevo bajo el sol. La novedad es el perfil de usuario al cual está enfocada a la herramienta: usuarios finales, no programadores.

Se trata de una ingeniosa estrategia para fomentar la adopción de la plataforma Android a través de la oferta de algo que no está presente en ningún otro terminal móvil. Aquí tenéis un video que demuestra cómo incluso un usuario final podría crear aplicaciones básicas sin esfuerzo.

La idea en sí me parece ingeniosa. Sin embargo, no es primera vez que se intenta algo parecido, aunque en otros campos de aplicación. Yahoo pipes es un ejemplo, y no ha conseguido una popularidad aplastante. Habrá que ver cuanto de éxito tiene esta iniciativa de Google.

Java SE 6 Update 21

Oracle ha anunciado Java SE 6 Update 21. No se trata de una versión de Bug fixes; todo lo contrario, esta versión no corregir ningún bug y sólo soluciona un único problema de seguridad relacionado con Drag-and-Drop. Sin embargo, incluye una nueva versión del compilador Hotspot  con nuevas autorizaciones de rendimiento, y una nueva versión de la herramienta de monitorización Visual VM.

Al hilo de la noticia, aprovecho para llamar la atención sobre el hecho de que podríamos estar ante el fin de Java SE tal y como lo conocemos a día de hoy. Java SE es una especificación que puede ser implementada (y es implementada) por varios fabricantes y proyectos opensource. La implementación de Sun/Oracle es sólo una de las varias implementaciones existentes (de hecho, Oracle tenía una versión propia de Java SE antes de adquirir Sun, llamada JRockit).

El JDK 7 se encuentra muy avanzado y teóricamente debería estar terminado este otoño, si bien es cierto que con la inclusión de última hora de las closures (no contempladas en ese roadmap) es posible que se acabe retrasando (aunque también es posible que nos demos una sorpresa en la JavaOne). En cualquier caso, si las cosas se hubiesen hecho como se hicieron con las últimas versiones de Java SE, hace al menos 2 años que debería haberse definido la especificación de Java 7, de la cual el JDK de Sun sería la implementación de referencia, pero no necesariamente la única implementación.

Me costa como un hecho por conversaciones que he tenido con empleados de Sun que la compañía en no sacó la especificación de Java 7 en su día porque quería dar cancha a sus potenciales compradores (IBM u Oracle) para hacer lo que quisiese con Java.

Ahora la pregunta es ¿qué va a hacer Oracle con Java SE? ¿Van a cambiar las reglas del juego? ¿Cuáles podrían ser esas nuevas reglas? Y ¿cuando nos las van a explicar?. No estoy, ni mucho menos, implicando que podría pasar a ser de pago, una estupidez que Oracle no va a hacer. Pero, por ejemplo, ¿Se van a cambiar las reglas del juego para que Harmony de Apache pueda certificarse? ¿Podrán otras compañías seguir creando sus propios JDKs? ¿bajo qué condiciones podré empaquetar y distribuir  un JRE/JDK con mi aplicación?

Aplicaciones web o nativas ¿cuál es el futuro del desarrollo para móviles?

Recientemente Arstechnica ha publicado una comparativa de rendimiento entre los motores de JavaScript de Android 2.2 (usando un Nexus One) e iPhone Os 4.0. Los resultados son contundentes: Android es más del doble de rápido.

Este dato puntual creo que en cierto modo también deja ver la diversa estrategia de ambas compañías respecto a las aplicaciones para terminales móviles. Apple apuesta definitivamente por las aplicaciones nativas, entre otras cosas porque le proporcionan beneficios económicos considerables y porque son un eficaz herramienta de lock-in tanto por parte de los desarrolladores (iAds es un buen ejemplo de ello) como por parte de los usuarios.

Google tiene una estrategia, cuanto menos, mixta. Las aplicaciones nativas siguen mejorando; destacable en Android 2.2 ha sido la introducción de un JIT para el "bytecode"; hasta ahora la ejecución de las aplicaciones era totalmente interpretada. Esto proporcionado incremento de rendimiento considerable para las aplicaciones nativas. Y en Android 3.0 los componentes de interfaz de usuario van a ser mejorados considerablemente; en general da la impresión de que el look&feel va a ser la prioridad de la siguiente versión mayor de Android.

Sin embargo, en vista de los resultados del benchmark, no se han olvidado tampoco de las aplicaciones web. Y no nos olvidemos de que Android 2.2 es la primera plataforma móvil con soporte completo para Flash, que nos guste o no es una parte considerable de la web actual.

Mantener aplicaciones nativas para distintas plataformas móviles consume una gran cantidad de recursos. No sólo es el tiempo de desarrollar varias veces la aplicación, sino la necesidad de contar con gente formada en ambas plataformas. Por lo general, especialmente a largo plazo, es algo que sólo grandes compañías pueden plantearse. Una broma entre desarrolladores de terminales móviles es que es posible sacar una versión 1.0 de una aplicación nativa para varias plataformas móviles. Pero no es posible sacar la versión 2.0.

Sin embargo, usando aplicaciones web no se consigue tomar ventaja de toda la funcionalidad del terminal móvil, ni se logra obtener la experiencia de usuario óptima. Con HTML 5 caerán bastantes barreras. Pero no todas. La gran ventaja de esta opción es que sólo hay que desarrollar una vez la aplicación para todos los terminales móviles.

¿Cuál es la estrategia ganadora a largo plazo? ¿Apostar por aplicaciones nativas o web? ¿Apostar sólo por una plataforma móvil, o llevar el trabajo de soportar varias plataformas móviles con aplicaciones nativas?