Los tiempos cambian, los tipos de proyecto también. Y con ellos se demandan nuevas soluciones tecnológicas. El mantra de crear arquitecturas robustas, extensibles y reutilizables ha dejado paso a la idea de construir software desechable, escalable y ajustado a las necesidades del día a día. Java es una víctima de este cambio.

Nadie puede negar méritos a Java. Este lenguaje de programación nació y se ha mantenido honrosamente durante la friolera de más de 20 años como el abanderado de las arquitecturas robustas, extensibles y reutilizables. Podías buscar soluciones en otros stack tecnológicos o decantarte por hacer las cosas bien y el primer paso en esa dirección era usar Java. Sus propios creadores lo mantuvieron sin complejos,

El código en Java es más verboso pero más legible y mantenible.

Y es verdad, trabajar con Java siempre fue una garantía de éxito en tanto que, a poco que no fueras demasiado torpe, las soluciones de Java funcionaban. La tostada se mantuvo caliente durante muchos años y al olorcillo de ese café se vieron atraídas muchas empresas con necesidades de negocio importantes. No podemos ser injustos, muchos de nosotros hemos desayunado muchas mañanas gracias a Java.

Pero si hay una verdad constante en el mundo del software es que nada es eternamente cierto. La premisa de base en la que se sustentaba toda una maquinaria que llego a ser enorme residía en que los proyectos de desarrollo eran grandes inversiones de negocio con tiempos mínimos de al menos 3 años y una duración estimada en producción de más de una década.

Paradójicamente, Java y su asesino nacieron y fueron creciendo a la vez y su historia se encuentra entrelazada como las vidas de Holmes y Moriarti. Internet y la Web llegaron a los hogares del usuario a la vez que Java daba sus primeros pasos. Java fue avanzando de versión en versión, de acuerdo a una extraña política incremental dicho sea de paso mientras que la Web se convertía en una plataforma de ejecución y era el nicho de las .com primero y de las redes sociales que hoy gobiernan nuestras vidas, después. Durante esos días cada progreso de Java alimentaba la Web y cada necesidad en la Web era un reto que invitaba a Java a dar una respuesta.

Y de esta manera, y casi sin darnos cuenta, la carrera de negocios en Internet se fue acelerando. Era importante tener un negocio en Internet. Era importante correr más que tu competencia en ese entorno. Y sobretodo, si tenías que morir, era importante que murieras pronto. La receta era sencilla. Construir un producto mínimo viable, validar rápido tu negocio y salir en 6 meses para garantizar que, si mueres, lo hagas con pocas pérdidas.

De repente, todo en lo que creíamos firmemente ha dejado de ser cierto. Los proyectos ya no sólo están movidos por grandes empresas con gran capacidad de financiación sino por spin-offs y start-ups que creen firmemente en un modelo de negocio que les va a permitir salir de la precariedad económica con la que comienzan su andadura. La tecnología ya no es lo importante. El software no se monta para que sea robusto, reutilizable y extensible. Hoy las arquitecturas son desechables . Muchos ejemplos de ello los encontramos en empresas como Twitter o Facebook que han pasado de soluciones basadas en tecnología más estándar a crear desde cero arquitecturas reactivas y escalables montadas con microservicios. Lo importante es que la tecnología de respuesta a la necesidad presente de estas empresas sin importar promesas de futuro.

Una vez más, la historia nos enseña que la reutilización es una puta mentira, que lo que importa es crear arquitecturas de alto rendimiento y que sean fácilmente escalables en respuesta a la demanda de carga de trabajo transaccional concurrente. Java, en esta película, es una especie mal adaptada. Trata de subsistir creando nuevas variantes de si mismo más competidoras en este sentido, como es el caso de Scala, e incluso se reinventa renunciando a sus férreos principios para incluir entre sus constructos rasgos característicos de otros paradigmas como las lambda expresiones , el orden superior o las clausuras.

Pese a esos no poco meritorios esfuerzos, es difícil sobrevivir a otras tecnologías que vinieron con el modelo asíncrono debajo del brazo y donde el esfuerzo de desarrollo parece estar mucho más adaptado a las necesidades actuales. NodeJS es un buen ejemplo en esta dirección. Lo que se tarda en desarrollar un servicio en NodeJS y la respuesta concurrente que éste da en virtud de su modelo de ejecución nativo basado en programación asíncrona lo convierten en caballo ganador. Tanto más cuando se incluye en esta formula de éxito el hecho de que es posible diseñar arquitecturas isomorfas que reaprovechan y comparten código entre back y front, permitiendo un considerable ahorro de esfuerzos y de sus tiempos asociados.

El pasado 19 de Enero me invitaron a una mesa redonda donde hablamos de este eterno debate. ¿Que mola más Java o JavaScript? Siempre es un placer encontrarse con buenos amigos. Tal vez sólo lo sentí por estos tres últimos ;). No es que sean malos técnicos. Muy al revés, son unos figuras que están en las primeras filas de la profesión. Pero claro, si bien Java es un lenguaje con muchas bondades, es difícil defender un barco que se hunde. Aquí os dejo los videos para que lo juzguéis por vosotros mismos.

Ronda de Debate

Ronda de Preguntas

Para mis amigos Javeros he de decir que en mi opinión, y pese a todo lo anterior, Java no morirá. Hay muchos huevos puestos en esa cesta, aunque viaje dentro de un barco que va a la deriva. Java se mantendrá para dar respuesta a todos aquellos negocios donde la premisa de partida sigue siendo una realidad: hay dinero, hay tiempo y hay larga duración. La historia se repite. Algo de esto pasó en el mundo de la banca 20 años antes de que Java si quiera hubiera nacido. Cobol es uno de los lenguajes con mayor número de líneas de código en ejecución hoy en día. Si quieres tener una profesión que te de seguridad, especialízate en este lenguaje. Dentro de poco esto mismo se podrá decir de Java.

La pregunta que te debes formular ahora es, ¿tu en qué barco quieres estar, en el de Java o en el de JavaScript?