Por qué 10 años después, los proyectos Java aún son riesgosos

 Hace  diez años atrás se hacía público un proyecto que aspiraba a concretar ese cáliz sagrado de lograr un entorno de ejecución neutral, implementado en las plataformas más difundidas (Solaris, Windows, Linux, Apple, IBM). La pretensión de ese santo grial era lograr que aplicaciones desarrolladas para ese entorno nuevo estuviesen por consiguiente listas para correr en todas sus implementaciones. La tan ansiada independencia de la plataforma (platform independence)
 
Por aquellos tiempos, paralelamente, otro tipo de aplicación saltaba el cerco del campus universitario y empezaba a entrar a todos los hogares: el navegador web (web browser). El navegador también venía con la premisa de fundarse en protocolos estándares para nuevamente lograr la máxima disponibilidad e independencia. Me refiero al Protocolo de Transporte de Hiper Texto (Hyper Text Transport Protocol o HTTP) y al Lenguaje de Marcas de Hiper Texto (Hyper Text Markup Language o HTML)
 
Con la explosión de Internet algunos analistas comenzaron a considerar que se venían los últimos días de la PC tal como la conocíamos, y que un nuevo rango de equipos de escritorio la iba a terminar desplazando. Se hablaba de la computadora de red (network computing), un equipo de muy bajo costo, minimalista en capacidad de almacenamiento en disco, en CPU y posiblemente en memoria pero con una virtudes inigualables en multimedia y en otro aspecto: iba a vivir conectado a Internet. Los analistas vaticinaban que las velocidades de la red iban a ser crecientemente mayores, lo que efectivamente ocurrió
 
En otros aspectos fallaron. Según sus pronósticos, el navegador iba a pasar a ser el cliente universal y todo el software funcionaría por suscripción. Hasta para usar un editor de textos íbamos a suscribirnos a un sitio web que nos va a proveería de un potente software descargable y ejecutable en el navegador. Los documentos que redactásemos, a su vez, se iban a almacenar en otro servidor remoto al que también íbamos a suscribirnos. Esto no ha sido así más que para aquellas aplicaciones que efectivamente tenían dependencia de la red (sistemas de reservas, extranets bancarias, etc)
 
Otra de las predicciones fallidas, quizás debido a la contemporaneidad de los lanzamientos, vislumbraba que aquellas extensiones a estos clientes universales se iban a desarrollar en un tercer estándar, junto con HTTP y HTML: con ustedes… el Applet Java!! El término applet significa aplicacioncita. Como estos conceptos nuevos eran un intento de universalizar la informática, no podían sino llevarse bien entre sí
 
Por aquel entonces yo trabajaba en una telco, en COBOL y C. Estaba empezando a convencerme de que si bien COBOL era un lenguaje que iba a costar sacar de producción (más bien se iba a ir él solo algún día), C en cambio era lo suficientemente complejo para llegar al rango de mainstream alguna vez (yo lo dominaba, para alegría de mi propio ego, y en la tésis de Licenciatura que había desarrollado en C me había sacado la máxima nota)
 
Presentía que los tiempos que venían iban a ser de C++ cuando Java se presentó en sociedad como un C++ menos menos. Java pretendía ser una versión simple y entendible de C++, ya que el paradigma orientado a objetos era especialmente complicado de entender por gente de la vieja guardia (análisis estructurado, Yourdon, etc). De hecho el políticamente correcto Smalltalk, el iniciador de la vanguardia OO (por Object-Oriented u Orientación a Objetos) había desaparecido tan silenciosamente como lo había sido su entrada en escena
 
Java no tenía punteros. En eso era igual que el COBOL. Sin embargo no se trataba de un retorno al pasado. El lenguaje C se jactaba de ser un lenguaje de alto nivel con la potencia de un lenguaje de bajo nivel como podía serlo el lenguaje ensamblador. Y por ello incluía el concepto de punteros y la posibilidad de hacer con ellos lo que se quisiese. Y más: el lenguaje no iba a hacer chequeo de tipos de ninguna índole. Querés asignarle un flotante a un puntero a nodo? Vale. Vale todo. Quizás Kernighan y Ritchie, los creadores del C, subestimaron que tanta libertad en manos de la fauna de desarrolladores podía llevarnos a no saber qué hacer con ella. Esa base liberal del C se conservó cuando el lenguaje se amplió a C++ en su intento de impedir que Smalltalk y la orientación a objetos le digan sos viejo antes de alcanzar la fama
 
Java venía a decir "basta de libertad irrestricta: libertad, sí, pero con leyes". No es que desaparecían los punteros: pero se iban a dejar lejos del alcance del desarrollador. Y respecto de los tipos, sólo iba a estar permitida la interpretación (casting) de un tipo en otro en casos específicos ligados a la herencia de las clases. Otra virtud del C/C++ era la asignación y liberación de memoria bajo demanda del desarrollador al sistema operativo. Con Java nuevamente libertad bajo vigilancia: él único que pide memoria y la libera es el entorno común de ejecución Java. Esta es la base del concepto de código administrado (managed code) y una reivindicación tardía al, ya por aquel entonces, desaparecido Smalltalk
 
Máquina Virtual de Java (Java Virtual Machine o JVM) era el nombre de ese entorno multiplataforma que, a la par que generaba curiosidad en la industria, también generaba cierta incredulidad. El código que se ejecutaba en la misma no era código máquina: los Java byte codes eran código que la JVM interpretaba. Esto a más de uno en aquellos años iniciales les dio a pensar "es otra elucubración teórica de índole académica: esto no es para misión crítica". También se equivocaron
 
También en aquellos días se asistía a la agonía del sistema operativo OS/2. A pesar del esfuerzo de IBM de acercarlo al ámbito doméstico con su versión 3 (OS/2 Warp), no pudo resistir la ola avasallante provocada por el lanzamiento mundial de Windows 95. La rápida reacción de IBM meses menos de un año más tarde fue necesaria pero no suficiente. Merlín era el code name de OS/2 Warp 4, que incluía capacidades de comandos por voz y algo que pasó desapercibido: incluía la implementación de IBM de la JVM. Por aquellos días yo era miembro activo del Club OS/2 que funcionaba viernes por medio en el edificio de IBM de Catalinas (un complejo de edificios de oficina en el centro de Buenos Aires). Javier Barabás, el gerente de producto de OS/2 en aquellos años, nos recordaba esta ventaja del soft basado en Java con estas palabras: "en la medida en que Java vaya ganando lugar, el software nunca más nos va a determinar el sistema operativo". Seguramente se refería al hecho de que en aquellos tiempos, para el público masivo, PC significaba Word y Excel (además del Buscaminas y el Solitario, claro) y estas aplicaciones sólo estaban disponibles en Windows. No en OS/2 por lo que… lo sentimos. Nadie me va a convencer de que OS/2 fuera peor que Windows 95. Como sistema operativo era mucho más estable que el colgante Windows. Sin embargo seguramente la falta de drivers para los nuevos dispositivos hogareños, así como también la sobre oferta de aplicaciones disponibles para Windows marcaron el final. A los pocos meses de cumplir 10 años de existencia, IBM anunciaba que ya no iba a seguir sacando versiones de OS/2. La plataforma Java, por consiguiente, se quedaba con una infraestructura menos donde correr
 
No obstante, hacía unos años ya que un nuevo sistema operativo para plataforma Intel, alternativo a Windows, venía dando que hablar. Linux era un UNIX gratis y se sumaba al consorcio conformado ya por las aplicaciones HTML/HTTP y Java. El enemigo tácito a vencer, cuando no explícito, era Windows, un monopolio al que había que pagar la licencia para engrosarlo. Así había sido como su dueño llegó a ser el hombre más rico del mundo. Más de uno suponía que ver caer al imperio era cuestión de tiempo: nadie se iba a resistir a usar un sistema operativo gratis. Sobre todo cuando Java finalmente domine la escena y las aplicaciones ya no necesiten un sistema operativo específico. Igual que la computadora de red, eso aún no ocurre. Simplemente no sucede
 
Pero Java sí recibió un golpe de suerte que la iba a catapultar al firmamento. Producto de varios factores, pero destaquemos dos. Quizás el hecho de haber nacido junto con la web hizo que Java evolucione dando una respuesta elegante a varios problemas que la web iba planteando, y que el resto de la industria apenas si parchaba. Los hoy antediluvianos servlets en aquel entonces eran mucho más simples que las interfases de paso comunes (Common Gateway Interface o CGI). Java mostró su potencial en la web en una forma tal que muchos neófitos llegaron a pensar que Java era un lenguaje para programar la web
 
El otro factor que ayudó a Java fue el efecto año 2000 (Y2K effect). Esa crisis motivó a varias empresas a determinar el fin de la vida útil de sus aplicaciones para dar vuelta la página y empezar de nuevo en plataformas noveles. Y dicho sea de paso, del nuevo siglo, no de la década del ’80. Tampoco fueron demasiadas aplicaciones, pero sí las suficientes como para mostrar que Java había pasado los exámenes y no se iba a conformar con la medalla de bronce. Ni con la de plata. La estrategia para lograrlo se llamó Java 2 Enterprise Edition (J2EE, hoy JEE): una federación de API’s para desarrollo web, objetos de negocio distribuidos, demarcaciones transaccionales, seguridad y otras necesidades de misión crítica
 
Aunque timidamente, acá empezó el problema. En mi opinión personal, acá se acabó la mística del C++ menos menos. La idea de la misma o mayor potencia, pero más simple. Las empresas que comenzaron a desarrollar aplicaciones JEE han venido lidiando (o conviviendo) con estas dificultades 
  1. Complejidad creciente. Rod Johnson, un gurú respetado en el mundo Java, lo dice de esta manera:
    "El enfoque tradicional a la arquitectura J2EE ha producido con frecuencia resultados desconcertantes: aplicaciones que son más complejas que lo que los requerimientos de negocio pueden asumir, muestran performance desconcertante, son difíciles de testear, y son demasiado caras de desarrollar y mantener" ("J2EE Development without EJB", Ed Wrox, cap. 1)
    Las API’s del estándar JEE evolucionan según especificaciones elaboradas por el comité Java Community Process (JCP). Este comité está integrado por muchos independientes, así como también empresas prestigiosas (ni que hablar de Sun, Intel, Oracle e IBM; también Siemens, Google, Fujitsu, etc). Cada especificación nace de un requerimiento (Java Specification Request o JSR). En estos requerimientos hay trabajos loables, como la API JDOM para manipulación de XML, hay trabajos intrascendentes como la API JDO para recuperar y persistir objetos en la base de datos (intrascendente no por el objetivo, sino por el grado de interés/adopción por parte de los desarrolladores), y trabajos insólitos como la API J2EE Connector Architecture, cuyos autores deben haber estado sobre demandados de sus respectivos trabajos porque esta API apenas si llega a ser una recomendación más que un prototipo a implementar. Por momentos no se sabe, incluso, si la recomendación es a no implementarla
    Lo cierto es que saber Java implica conocer estas especificaciones evolucionadas a lo largo de estos años por equipos con diferente background e idiosincracia. Que alguien me explique, siendo 0 (cero) el primer índice de arreglos y colecciones, entonces por qué la API JDBC numera las columnas desde el 1 (uno). Parece una trivialidad pero le ha llevado horas de debugging a más de un incauto
  2. Improductividad en la oferta de herramientas. La complejidad no sólo existe al momento de comprender el estándar. Aún habiendolo comprendido, el estándar no define herramientas amigables que aligeren la producción de código Java. Crear un Enterprise JavaBean (EJB) implica crear, con muy poca automatización, un conjunto de clases conocidas como interfaz remota, interfaz local, aparte del bean en sí. A todo eso luego hay que configurarlo en un archivo XML conocido como EJB descriptor. Las herramientas de desarrollo de los diferentes vendors presentan fortalezas y debilidades. Ninguna, hasta el momento, ha ganado reconocimiento por tener una versatilidad igual que Visual Studio .NET. Esto ha llegado a límites insólitos: hacia el 20 de Octubre de 2005 han aparecido una serie de artículos presentando una pieza de Mainsoft. La misma toma código MSIL (Microsoft Intermediate Language, el código intermedio de .NET) desarrollado con la productividad que alcanza Visual Studio, y lo transforma en byte codes para BEA WebLogic. Velo con tus propios ojos acá
  3. Lejanía entre arquitectos y desarrolladores. Es una consecuencia de la complejidad. Termina provocando que los únicos capacitados para desarrollar adecuadamente en Java sean los mismos arquitectos. El concepto de desarrollador puro (raso) en Java es alguien que conoce de 2 (dos) a 4 (cuatro) API’s en profundidad. Con frecuencia no interpreta bien o, en otras palabras, malinterpreta al arquitecto y termina produciendo algo diferente a lo requerido. En la mayoría de los casos es más rápido que el arquitecto lo termine. Hasta ahora la mayoría de los desarrolladores Java con que me topé -salvo honrosas excepciones- no saben explotar los beneficios del paradigma orientado a objetos
  4. La arrogancia del arquitecto. Me tocó toparme con pedantes que no se permitían diseñar algo que fuese entendible por más de tres personas (incluyendo a ellos). En tal caso debía ser revisado hasta que sólo fuese entendido por un conjunto menor de personas, so riesgo de que no fuese realmente arquitectura. Uno de estos arrogantes batía todos los récords, sinceramente. Me estaba entrevistando por una búsqueda de arquitecto Java y me dijo
    -Estoy cansado de los que dicen ser arquitectos pero no lo son realmente. En Santiago sólo hay cuatro o cinco arquitectos de verdad y nos conocemos todos
    Excelente mensaje para CIOs santiaguinos que tengan que optar por una plataforma para los próximos años. Si iban a elegir Java, sepan que en Santiago sólo hay cuatro o cinco arquitectos. En realidad uno menos, habrá tres o cuatro con suerte porque les puedo asegurar, por lo que supe luego, que éste muchacho era también de esos que dicen ser arquitectos y no lo son
  5. La diáspora del estándar. El show debe seguir. Si el JEE oficial va a persistir en su senda de complejidad, alguien iba a terminar viniendo a hacerse cargo de la situación. El proyecto Hibernate le hizo pito catalán al oficialista JDO. Velocity es una alternativa simplísima pero no menos potente que JavaServer Pages (JSP). Frameworks como Spring están siendo exitosísimos en esconder la complejidad real del estándar para suplantarla por API’s más comprensibles. La pregunta es: saber JEE es conocer los estándares? O es conocer Struts, Spring o Hibernate? Esta cuestión fue abordada ya. En el artículo Java en peligro? los autores se preocupan de que la "fragmentación contínua y la discusión política podrían poner en riesgo la visión de Sun"
  6. Obsolescencia. Evidentemente algo funciona mal con el comité JCP. Las especificaciones demoran bastante en salir. Pero cuando salen, los vendors aún las tienen que implementar (más allá de la implementación de referencia que se distribuye con la advertencia de que el que la ponga en producción asumirá las consecuencias pertinentes). Una vez que los vendors las implementen, el público las tiene que adoptar. Vamos a los resultados: a más de un año de haberse lanzado Java 5.0 (code name Tiger), las empresas aún están -las más actualizadas- con Java 1.4.2. Respecto a JEE, hace ya dos años de JEE 1.4 y estaría para salir JEE 1.5. En cambio, el mercado quedó en JEE 1.3
  7. Portabilidad compleja. No me miren ni me digan nada a mí: juro que no fui yo el que dijo "escribalo una sola vez, ejecutelo donde quiera" (write once, run anywhere o WORA). Es más, yo fui una víctima más del cuento del tío: "y bueno, m’ijo, si usted no fue prolijo al construir su aplicación, no pretenda ahora que le corra en nuestra plataforma". Aclaro que no sólo tuve problemas para migrar entre plataformas de diferentes vendors: he tenido problemas de portabilidad para pasar de una versión de servidor de aplicación de un vendor a la versión siguiente… del mismo vendor!!
  8. Falta de profesionales entrenados. Es otra consecuencia de la complejidad actual del estándar. El que no se subió en la primera ola y pudo ir entendiendo la evolución, no va a entender ya la película empezada. Ese efecto es real y hoy las compañías para conseguir desarrolladores y arquitectos Java se los tienen que robar a otras compañías. Peor que eso es que este vacío de profesionales está haciendo que se metan a desarrollar en Java no sólo desarrolladores que no llegaron a completar la carrera de Ingeniero de Sistemas: el mercado le está dando lugar a desarrolladores que jamás comenzaron tal carrera. Me ha tocado conocer, en un importante banco español, a una profesora de música encargada de la construcción de componentes (JavaBeans) de interfaz de usuario. La pura verdad: si tenía ese carácter desarrollando software, no la quiero imaginar haciendo música
  9. Desarrolladores caros. Consecuencia de la falta de profesionales entrenados. Vivimos en un mundo capitalista, no? Qué pasa con los costos cuando la demanda supera a la oferta?
  10. Proyectos fracasados. En casi la totalidad de los casos que me ha tocado conocer, agotaron el presupuesto, para terminar produciendo arquitecturas complejas. Hechas en forma arrogante y que luego, desarrolladores mal entrenados -y no obstante ello, caros– no llegaron a comprender adecuadamente. Como consecuencia, las implementaron en forma incorrecta cuando no incompleta

Diez años después Java es saludablemente fuerte en los cores de todo el arco del sector financiero (banca, créditos, seguros, etc). A mi entender, y en gran medida, gracias a que IBM es un actor importantísimo en esa vertical. En el resto de la industria su presencia está más comprometida. Juega, sí. Pero no es el único jugador y hoy ni siquiera el más vanguardista

Los applets Java son parte del pasado. No resultaron. En gran medida víctimas de haberselos confundido con thin client (cliente delgado)

Mi impresión, en estos diez años de Java, es que se estaría transformando en el COBOL del siglo XXI. No va a salir de un día para el otro. Pero es evidente que la industria necesita otra cosa. Merece otra cosa. Aquellos que me conocen, saben todo lo que he hecho por promover Java y difundirlo. Masificarlo. Los newsletters con novedades. Las opiniones en foros. Las clases de JEE que daba en forma gratuita en la Universidad Mayor (Santiago de Chile). Los cursos dictados en el desaparecido holding Activa

Hemos hecho bastante y hemos sido reconocidos por ello. En el año 2002, la Universidad de Dublin (Irlanda) publicó un trabajo de mi autoría en la Conferencia Inaugural "Principios y Prácticas de la Programación Java" (Principles and Practices of Programming in Java o PPPJ): Hacia un framework de facturación orientado al negocio con JavaBeans. Esto salió sponsoreado por Sun Microsystems, el papá de Java

He ganado bastante reconocimiento por los trabajos que he realizado en Java. Tanto en Argentina, en Chile, en España, en Brasil, y la lista sigue. No creo que deba pedir permiso para opinar sobre Java. A lo largo de estos 10 años el camino original creo que se fue abandonando. No tengo un buen pronóstico de que esta plataforma, que tantos hemos querido alguna vez, vaya realmente a ser mayoría

A modo de epílogo quiero mostrar ciertos comentarios de respetadas figuras de la arena Java:

  • "Con el tiempo J2EE ha sufrido de las dolencias tradicionales que pueden ser descritas como si todo lo que tengo es un martillo, entonces todo me parece un clavo. Peor aún, si tengo un martillo y necesito poner un tornillo, entonces agregarle una cabeza de destornillador a mi martillo no es una gran idea (para más información lea la especificación de J2EE Connector Architecture!) Desafortunadamente, por lo tanto, con el tiempo J2EE se ha hinchado de API’s y funcionalidades adicionales" (Annrai O’Toole, “The Problem with J2EE”)
  • "No me hagan comer un elefante de nuevo" (Bruce Tate, respecto de las mejoras introducidas a la API EJB en la versión 3.0)
  • "La complejidad de Java está creciendo más allá de nuestra capacidad de comprensión. (…) Llamo a esta tendencia la hinchazón. El nuevo relleno es complicado. Obliga a saber demasiadas cosas. (…) Entonces, hay que aprender un conjunto completo de patrones de diseño para evitar las complicaciones de la especificación J2EE. Para empeorar más las cosas, hay que mantener la vista en el futuro, en tecnologías emergentes como Java Server Faces y servicios web, que podrían explotar en cualquier momento" (Bruce Tate, "Better, Faster, Lighter Java")
Esta entrada fue publicada en Software Management. Guarda el enlace permanente.

4 respuestas a Por qué 10 años después, los proyectos Java aún son riesgosos

  1. Unknown dijo:

    Al intentar imprimir este artículo   http://diegumzone.spaces.live.com/blog/cns!1AD5096D63670065!170.entryusando el botón imprimir en la parte superior izquierda de la página, abre una nueva ventana con un listado de los últimos 30 artículos, al usar el enlace "ver más", despliega otros 20 artículos mostrando un total de 50, no obstante sólo llega hasta 18 Marzo del 2007 y no alcanza a llegar a éste de Octubre del 2005, por lo que no se puede seleccionar para imprimir. Finalmente debí usar la opción para imprimir del browser.Salu2

  2. Diego dijo:

    Gracias por el feedback, German. La verdad desconozco si yo puedo cambiar esa conducta. Me parece que es un default de Live Spaces

  3. Daniel dijo:

    Diego, te felicito por la reseña historica que hiciste. Sabe que seguro nos conocemos, ya que yo estaba encargado del area educacion del club de usuarios de os/2 que se hacia en catalinas y llegue a tu pagina buscando a Javier Barabás. Te mando un abrazo, espero estes bien y te felicito por el contenido de este blog.SaludosLeonardo Santagostini

  4. Regina dijo:

    esta genial…….😄

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s