No se trata de bits, bytes y protocolos, sino de beneficios, pérdidas y márgenes.

— Louis Gerstner, Jr. (n. 1942). Empresario estadounidense, mejor conocido por su rol como director general de IBM entre 1993 y 2002.

Una tendencia aparentemente irreversible, es la lenta pero inexorable muerte de Java Enterprise Edition (Java EE). No me refiero al lenguaje de programación Java (también conocido como Java Standard Edition o Java SE), el cual está teniendo un enorme impulso gracias a su facilidad de aprendizaje e implementación, sino a todas aquellas tecnologías/librerías basadas en Java, que en su momento eran consideradas el non plus ultra para desarrollar aplicaciones multi-capa y empresariales: Servlets, Java Server Pages (JSP), Enterprise Java Beans (EJB), Java Persistence Architecture (JPA), así como Java Server Faces (JSF).

Cómo llegamos hasta aquí

En 1999, Sun Microsystems publicó Java EE, con la finalidad de desarrollar aplicaciones «de nivel empresarial», que en su forma más simple, son aplicaciones web con alta disponibilidad, escalabilidad y mantenibilidad. Así, dicha versión de Java incluía los EJBs, Servlets y JSPs; tecnologías bastante complejas que requerían de al menos un día para mostrar el proverbial «Hola Mundo». Debido a esta dificultad de implementación, la comunidad open-source respondió casi de inmediato, desarrollando y liberando en el año 2000 ciertos frameworks como Struts e iBATIS, los que disminuían enormemente el tiempo para terminar un delivery. Eventualmente, surgieron algunos frameworks más ligeros y ergonómicos que el propio Java EE, como Hibernate y Spring, los que forzarían a Sun adoptar su filosofía, en la sexta versión de Java EE, liberada en 2009.

Sin embargo, a raíz de la adquisición de Sun por Oracle, completada en 2010, la empresa dirigida por Larry Ellison ha dejado de apostar a esta plataforma, relegándola poco a poco al olvido. ¿La razón? Que Oracle es un conocido mercenario en la industria, y Java EE no está generando los suficientes ingresos como para asegurarle un presupuesto. Lo peor de todo es la poca transparencia y falta de un pronunciamiento claro al respecto, lo que está poniendo nerviosos a programadores, integradores y clientes por igual. Y no es para menos, pues considerando el historial de Oracle con los desarrollos open-source, existen muchas razones para preocuparse por el bienestar de esta plataforma; especialmente desde que Oracle perdió una batalla legal contra Google en Mayo pasado por el uso de Java en Android, la que ha desembocado en la demora de Java SE 9, cuya fecha de liberación se moverá hasta 2017, y la paralización de cualquier trabajo relacionado a Java EE.

Pic: Is Java dead?

Si bien la plataforma Java EE se encuentra en franca decadencia, el lenguaje de programación Java es parte de una era dorada empujada principalmente, por el explosivo crecimiento de los smartphones y tablets:

• Los applets de Java ya son cosa del pasado debido a que inicialmente apareció Flash; en última instancia, fueron liquidados por HTML5.

• La popularidad de Java en desktop siempre ha sido relativamente baja, debido sobre todo a otras opciones como C++ y Python. Sin embargo, definitivamente no está acabada y todavía se mantiene en evolución constante.

• Muchas empresas tienen enormes cantidades de código escrito en Java. Y si algo hemos aprendido de lenguajes legados como COBOL, es que frecuentemente, se niegan a morir – aunque ya no representaría una ventaja curricular conocerlo, a menos que seamos especialistas en alguna de sus tecnologías, como digamos, EJB 2.1.

• Java es el principal lenguaje de programación de los dispositivos Android, que son muy populares: en Otoño de 2015 existían alrededor de 1,400 millones de dispositivos activos alrededor del mundo.

En resumen, Java no va a desaparecer, incluso si Oracle se lo propusiera.

(Fuente de la imagen: ExtremeTech.com)

La cuestión es que al detener el soporte a Java EE, Oracle está poniendo en riesgo 15 años de desarrollo aplicativo y literalmente, millones de empleos alrededor del mundo. Hoy en día, ya hay competidores de Oracle que estarían dispuestos a tomar el relevo para continuar con el proyecto, como IBM y RedHat, quienes ciertamente tienen los recursos para soportar la plataforma, además de tener la capacidad de agregarle funcionalidad de acuerdo al actual entorno tecnológico, como los microservicios. Claro que Oracle siendo Oracle, puede comportarse como el siniestro Guasón de The Dark Knight (2008): esta compañía preferiría convertirse en un agente del caos, antes de permitir que las joyas de la corona caigan en manos de la competencia. Esto podría desestabilizar la industria, ya que daría lugar a una situación extrema en la que decenas de proveedores de TI, que dirigidos por Google, IBM y RedHat, se unan para generar su propia versión de Java EE, dejando a Oracle fuera de la jugada.

¿Qué pasará?

Lamentablemente, Oracle no ha sabido cómo capitalizar la ventaja competitiva que tiene al haber adquirido Java EE. Por el contrario, se puso un balazo en el pie, eliminando o echando a perder algunas de sus mejores adquisiciones, como WebLogic, GlassFish, OpenOffice ó Hudson. Y es que este siempre ha sido el modus operandi de Oracle: en vez de tomar un producto para hacerlo el líder de su respectivo nicho de mercado, se la ha pasado coleccionando buenos desarrollos, para poco a poco, retirarles el financiamiento. Eventualmente, los deja morir o los «tira a la basura», al donarlos a la comunidad open-source cuando ya no representan un riesgo para su negocio central.

Si Ellison y su equipo tiene un mínimo de visión, en algún punto se darán cuenta que su verdadero negocio central son las bases de datos; no los servidores de aplicaciones y por supuesto, tampoco Java EE. En ese momento, darán las gracias y dirán adiós, permitiendo que el Java Community Process tome las riendas de la plataforma, dejando que algunos de sus miembros más fuertes se hagan cargo de su evolución. Sin embargo, si Oracle no hace absolutamente nada, tan sólo se necesitan un par de años más para que la entropía se haga tan evidente, que nadie querrá adoptar su funcionalidad, convirtiéndola en tan sólo algunas librerías de uso común en los productos de Oracle. Esto de hecho, ya está pasando en la actualidad: algunos de los clientes con los que he trabajado, están reemplazando sus servidores de aplicaciones empresariales (RedHat JBoss o IBM WebSphere) por simples Tomcats con Spring debido a que «Nos han pedido diversificar nuestro stack tecnológico, porque nuestra dependencia [en Java EE] se ha vuelto potencialmente peligrosa.» Siendo así las cosas, ya no habrá nada que hacer, dando el paso libre para otras tecnologías como MEAN (MongoDB + Express.js + AngularJS + Node.js»).

En fin, el único consuelo de tontos en este caso, es que Oracle se está disparando en el pie una y otra vez, repetidamente. Entonces, después de haber generado suficiente antagonismo con socios y clientes por igual, tal vez finalmente sangre lo suficiente como para que muera y sea comprada por alguien que sí tiene la visión necesaria para llevar esta plataforma hacia el futuro.