Pero Java, como lenguaje de programación, no es sino una pieza más -aunque importante- dentro de la Plataforma Java entendida en su conjunto. En el fondo, se buscaba compatibilizar cualquier dispositivo de forma que una misma aplicación pudiera funcionar sin cambios en un PC de escritorio, un servidor, un televisor, un teléfono móvil o hasta un PLC industrial. Daba igual cual fuera del sistema operativo que gestionase el dispositivo porque por encima de él se situaría la Máquina Virtual Java (JVM) que lo haría todo compatible.
Como peaje a esa maravilla tecnológica, todos los desarrollos de aplicaciones deberían hacerse en el nuevo lenguaje de programación: Java. No importaba si se trataba de una aplicación de gestión financiera o la gestión de la tarjeta SIM en un teléfono móvil, todo debía hacerse en Java.
...Y la realidad quince años después
La realidad es que Java es el lenguaje de programación más popular en la actualidad compartiendo ese primer puesto con alguno de los lenguajes (VB o C#) de la plataforma .NET, según quien haga la medición. Sin embargo, del sueño de compatibilizar las plataformas no queda ni rastro.
Y no es que una aplicación diseñada para un servidor no funcione en un TV o un teléfono. Es que una aplicación diseñada para un servidor de aplicaciones J2EE no funciona en ningún otro servidor J2EE, al menos sin cambios. En muchas ocasiones incluso hay problemas en función del sistema operativo anfitrión o el motor de base de datos.
Seguramente habrá muchos teóricos que piensen que eso es una barbaridad. Pero no lo es, es la simple constatación de la realidad.
Además de los problemas de compatibilidad, prácticamente nadie se plantea desplegar Máquinas Virtuales Java en nada que no sea un servidor (muy potente) porque poner una capa de homogeneización por encima del sistema operativo y el hardware tiene un coste de recursos inasumible, máxime teniendo en cuenta los gravísimos y frecuentes problemas que la plataforma Java ha sufrido en la gestión de la memoria.
Es decir, hemos cambiado de lenguaje de programación, con todo lo que ello implica en la curva de aprendizaje de las personas y en los costes de migración, sin tener ni una sola de las ventajas que Java prometía. Visto en perspectiva, un disparate provocado en exclusiva por la moda.
Usamos Java para funciones muy dispares como diseñar sitios y aplicaciones web, para las aplicaciones Android, para la gestión interna de dispositivos de red o para aplicaciones empresariales internas. Y lo hacemos aún teniendo en cuenta que Java no es lenguaje de programación más óptimo en todos esos escenarios. De hecho, en su afán de compatibilizarlo todo, probablemente no sea el lenguaje de programación más óptimo en ninguno de ellos porque no es lo mismo gestionar las librerías gráficas de un teléfono móvil que realizar un proceso masivo de emisión de recibos. Aún así, usamos Java para todo ello.
El canon que nos toca pagar viene en forma de mayores plazos y costes de programación, sobre todo en aplicaciones de gestión (que son la mayoría en el ámbito corporativo) donde se han dejado de lado otros lenguajes de programación infinitamente mejor preparados para esa función pero bastante menos fashion.
Como el chaval del r9
Para compensar muchas de esas carencias y nuevas necesidades en Java han surgido un gran número de frameworks de desarrollo y tecnologías que complementan la funcionalidad original.
De hecho, saber Java es solo el principio para hacer aplicaciones Java. Hace falta tener conocimientos de otras tecnologías y frameworks como JavaServer Faces, Spring, Struts, Hibernate, servlets, applets, JSP, JDOM, Apache Velocity, JBoss Seam, Apache Wicket,... según las preferencias del equipo de desarrollo y el tipo de aplicación que se quiera desarrollar.
En cierta medida, Java se parece a la leyenda del chaval del r9, que partiendo de un coche más bien normalito y a base de complementos intenta igualar al Kadet GSI de su cuñado.
Terminando
Estoy convencido de que si pusieran a un informático a analizar el oleaje con el objetivo de fijar la mejor posición para un generador eléctrico, acabaría desarrollando un modelo para normalizar el tamaño, posición, fuerza, caudal y frecuencia de las olas. Seguramente nadie se lo habría pedido, no podría ser implementado en la vida real y obligaría a desperdiciar datos vitales de cada ola a fin de hacerlas compatibles. Pero quedaría de lo más mono en un mercado absolutamente dominado por las modas. Qué le vamos a hacer, somos así.
Para no flagelarnos, quizá sea un buen momento para aprender algo de JAMon.
Enlaces relacionados
› Programación, ¿arte o ciencia?
› El día que SAP entró en la empresa
› ¡Que poco sexy eres COBOL!
› La fashion week tecnológica
www.tonsofit.com
Muy bueno el post,como siempre. Pero tengo una matización sobre la compatibilidad de aplicaciones j2ee en diferentes servidores de aplicaciones.
ResponderEliminarEs cierto que una aplicación diseñada para funcionar en un determinado servidor j2ee no funciona en otro servidor sin realizar ningún cambio.
Pero también es cierto que una aplicación desarrollada siguiendo las especificaciones del estándar j2ee, funciona perfectamente en cualquier servidor de aplicaciones. Hay que ser consciente de que cuando usamos funcionalidades fuera del estandar j2ee que nos proporcionan los servidores de aplicaciones, estamos haciendo la aplicación incompatible con el resto de servidores.
Por otra parte, una cuestión importante que deberían plantearse las empresas es: realmente necesito un servidor de aplicaciones que me ofrece gran cantidad de funcionalidades fuera del estandar j2ee, y de las que sólo voy a usar un 2%, si llega?
Sobre el papel tienes toda la razón pero en la práctica eso no ocurre o al menos esa es mi experiencia. A eso me refería con lo de normalizar las olas, a que sobre el papel todo funciona pero luego la práctica es mucho más tozuda. ;-)
EliminarTengo casos para aburrir pero citaré solo dos muy recientes. Primero, el de una aplicación que te venden y es supuestamente J2EE pero en la que el sistema operativo tiene que ser obligatoriamente RedHat, el servidor de aplicaciones Jboss y la base de datos MySQL. Cualquier cosa que se salga de eso exige cambios.
La segunda es la de un conocido gestor de contenidos (lo conoces, si es ese en el que estás pensando, aunque yo no quiera dar el nombre ;->>) que soporta prácticamente cualquier servidor de aplicaciones excepto Jboss en la versión enterprise. Lo alucinante es que soporta Jboss community, WAS, Weblogic,... pero la enterprise de Jboss no. Está claro que son razones comerciales.
Cada vez que alguien nos quiere vender una app J2EE me 'divierto' un poco jugando a cambiarle las piezas para que acabe diciendo que no sigue el estándar. Y no falla una oiga!!! :-]
Y respecto a lo de que usamos el 2% de las cosas que incorpora el software, totalmente cierto.
Feliz Año Fife!
Saludos, Manu
Ya se te echaba en falta, casi dos meses sin novedades.
ResponderEliminarQue el año que viene siguas dandole vidilla a este blog tan interesante.
Urte berri on!
/Pablo Isusi
Por falta de ganas de contar historias no ha sido. Más bien falta de tiempo por un final de año curioso. :-)
EliminarUrte berri on