26 de septiembre de 2010

Oracle y el trono perdido de Java ME

The Register tiene este domingo un interesante artículo (consecuencia de este otro) sobre los planes de Oracle para la versión de Java para móviles, Java ME. Junto al ataque legal por patentes de Java a Google, parece obvio que Oracle pretende sustituir a Android como plataforma Java para móviles, y ya de paso adelantar a todas las demás. Desde luego, al señor Ellison no se le puede acusar de no tener más moral que el Alcoyano.

Si mi memoria no me falla, en todos los artículos que he leido en todos estos años desde que el iPhone inauguró la "tactilitis", no he leido a nadie mencionar a Java ME como plataforma de desarrollo con futuro. A día de hoy el éxito de una plataforma para teléfonos móviles se cuenta por el número de aplicaciones disponibles en su tienda de aplicaciones, y los números son estos: 250.000 para iPhone, 120.000 para Android, 7.422 para Blackberry, 6.118 para Nokia, 4.475 para Palm y 1.200 para Microsoft. Sun anunció con mucha grandilocuencia la que iba a ser la tienda de aplicaciones más grande del mundo, para aplicaciones Java de todo tipo, multiplataforma y todo eso, pero a día de hoy aun está en beta, y de una versión específica o una adaptación para Java ME no se sabe nada.

Resulta sorprendente que Oracle tenga fe en Java ME. Para empezar, porque a día de hoy se ha convertido en sinónimo de "obsoleto". La propia noticia detalla las mejoras que Oracle planea (es decir, planea añadir en el futuro, aun no están disponibles): aceleración gráfica para crear interfaces fluidas. Guste o no, el iPhone es quien ha sentado las bases de lo que se considera "requisitos mínimos" en un teléfono móvil, y la aceleración gráfica que hace más intuitiva las necesarias transiciones de las interfaces táctiles está entre esos requisitos. Para hacerse una idea, vean esta captura del toolkit con el que andaban coqueteando, inspirado en Swing. Ahora pasan de eso y parece ser que quieren usar JavaFx, imitando a Microsoft con Silverlight en el Windows Phone 7. Solo que Oracle está aun más retrasado que ellos.

Pero hay otro problema con Java ME, que es la fragmentación. A Sun siempre le gustó llenarse la boca con palabras bonitas sobre la multiplataforma de Java, hablar sobre el "ejecutar en cualquier sitio", pero la realidad es distinta. Java ME como plataforma estaba muy fragmentada, no tanto por la plataforma en si, sino por las diferentes configuraciones de hardware existentes y la manera en la que los fabricantes lo integraban en sus teléfonos. En realidad, este es el mismo riesgo que Android sufre -en realidad ya está sufriendo-, que una aplicación funcione o deje de funcionar dependiendo del modelo de teléfono.

Uno no puede evitar pensar que Oracle lo hubiera tenido más fácil intentando adoptar la plataforma Android como sustituto de ME, en vez de intentar -inútilmente- de cargársela y sustituirla, que es algo que difícilmente va a lograr. Especialmente teniendo en cuenta que a Oracle le falta algo crítico: un sistema operativo para móviles. Pero oiga, si Ellison cree que Html5 es una chapuza y que JavaFx es la mejor manera de programar páginas web y que no hay nada más que discutir [1], ¿por qué no iba a creer que Java ME puede eclipsar al resto de plataformas de desarrollo para teléfonos móviles? Quizás Apple acabe rindiéndose a sus pies y pidiéndoles que les ayuden a incluir Java ME en el iPhone.

[1]: A pesar de que Ellison piensa eso, la realidad es que en JavaFx 2.0 han cambiado completamente su punto de vista. Han añadido un motor de aceleración gráfica que, aparte de renderizar en DirectX o OpenGL, también será capaz de hacerlo en Html5. Si, como suena: escribir aplicaciones que se visualizen en Html5 pero escritas inicialmente en JavaFx, supongo que al estilo del Google Web Toolkit.

1 comentario:

  1. Anónimo1:02 p. m.

    'Si, como suena: escribir aplicaciones que se visualizen en Html5 pero escritas inicialmente en JavaFx, supongo que al estilo del Google Web Toolkit.'

    Me parece que te has liado un poco. JavaFx va a tener un componente (basado en WebKit) capaz de renderizar HTML5. Además JavaFx 2.0 no tendrá su lenguaje de script, que muere, sino que se desarrollará en Java.

    http://www.h-online.com/open/news/item/JavaFX-Script-is-dead-long-live-JavaFX-1082823.html

    http://javafx.com/roadmap/#web

    La idea es calcada de AdobeAIR: escribir
    aplicaciones - RIA's- en HTML5 y/o JavaFX que se ejecuten dentro de la VM de Java (de hecho, seguramente se pueda llamar a las APIs de Java/JavaFX desde el HTML5/Javascript )

    Es decir, un entorno que puede ejecutar HTML5 y graficos vectoriales y además extenderlo con Java nativamente (en applets, web star, escritorio )

    ResponderEliminar