Servidores tipo Node.js en la JVM y el fin de JavaEE
javaHispanoDesde hace un tiempo ya podemos afirmar el éxito de Node.js , especialmente en el tema de la escalabilidad. El éxito de dicha escalabilidad en Node.js se basa en que un único proceso en node.js puede servir de forma intercalada gran cantidad de peticiones , evitando de esa forma la perdida de tiempo en los cambios de contexto entre threads como ocurre en los servidores Java. Esto ha hecho que desde el mundo Java se creen frameworks/servidores con la misma filosofía que Node.js en la que un mismo thread pueda servir múltiples peticiones simultaneamente. Ejemplos de esos frameworks son Vert.x o Akka , aunque este último esté mas centrado en el lenguaje Scala. Sin embargo debido al gran cambio de funcionamiento de estos frameworks y no ser unos frameworks mayoritarios (todos sabemos que el uso de nuevas tecnologías y poco usadas suele llevar a problemas de falta de documentación, falta de profesionales, etc. ) en el entorno Java puede hacer que sigamos usando servidores “clásicos” de Java como por ejemplo Tomcat.
Pero todo ésto puede estar cambiando. La semana pasada en DZone publicaron un post sobre uso de frameworks Web Java Survey Results, Part II - Web Frameworks. Estas encuestas salen de vez en cuando y no suelen deparar muchas sorpresas, pero esta vez si que ha habido una. El segundo puesto de frameworks web mas usados ha sido para Vert.x. Personalmente me parece una sorpresa el gran uso de Vert.x aunque visto el éxito de Node.js también podríamos pensar que en el entorno de Java llevamos ya unos años de retraso y que este paso debería de haberse dado hace unos años.
Por otro lado éste tipo de frameworks hace que no sean necesario los servidores de Servlets como Tomcat o Jetty y sabiendo que éstos son los servidores mas usados en Java podemos preguntarnos: ¿Que queda de JavaEE si ya no usamos sus servidores? El uso de Spring puso el primer clavo en la tumba de JavaEE, el siguiente se lo puso el mismo JavaEE debido a lo pesado de sus servidores de aplicaciones , últimamente hay rumores con Oracle respecto al futuro de JavaEE, ¿son finalmente frameworks como vert.x el último clavo en su tumba?
Nota: noticia enviada por logongas
Reader Comments (22)
Cabría preguntarse sobre que nivel de confianza puede tener esta encuesta.
No veo datos sobre cuantas respuestas se han recogido en esa segunda entrega. En la primera parece que fueron ¿120?
Recomiendo ser prudente a la hora de sacar conclusiones de algunos blogs.
No estaba nada al tanto de estas tecnologías y la verdad es que me sorprende que después de tantos años hayan pasado a los frameworks java por la derecha. Esto es como cuando los primero móviles aparecieron y el NOKIA era la leche y de repente llegaron los smartphones y ......... donde está nokia???
¿Se avecinan malos tiempos para los Javeros después de 20 años dando guerra?
No lo creo ya que eso 20 años pesan y hay mucho trabajo detrás y muchas tecnología y librerías implementadas, probadas, y en funcionamiento pero....
¿Será este un punto de inflexión para abandonar J2EE?
Desde mi punto de vamos para atras como los cangrejos, en cuanto a lenguajes de programación, parece que ahora todo está basado en JS.
Para mi tanto Java para el backend (he currado con ello durante más de 10 años), como AS3 - flex4 (4 años trabajando) para el front son las dos combinaciones perfecta de como conseguir hacer un código estructurado, en capas, con tus infaces y legible perfectamente en base a patrones de diseño.
Vale que todo ha avanzado más pero el JS no es para nada un leguaje que se puede estructurar, da mucha libertad y leer código de otros puede ser ...... imposible.
Para mi lo más importante que un código además de funcionar tiene que estar bien documentado y ser legible por otro programador que vaya a retomar la tarea.
Tampoco estoy muy al tanto del los frameworks de JS pero creo que no son capaces de resolver esto.
@antuansoft
Para nada estoy diciendo que se avecinan malos tiempos para los Javeros, es justo lo contrario. Node.js ha popularizado otro tipo de Servidores y gracias a vert.x y a su aparentemente popularidad podemos subirnos al tren de la escalabilidad sin necesidad de ir a Node.js. Lo único malo de ésto (o quizás es una ventaja) es que vert.x o Akka no son un estándar de JavaEE. Pero decir que está muerto JavaEE no es necesariamente malo para los Javeros si dicha muerte es debida a nuevas opciones en el ecosistema Java que lo substityen.
Por mi parte creo que el futuro es JavaScript tanto en la parte del BackEnd como en el FrontEnd.
Solo hay que ver como esta quedando ECmaScript 6.
Ya se está dando pasos agigantados en implantar patrones de diseño y esas cosas en JavaScript con proyectos como http://aurelia.io y otros más que estan apareciendo...
@antuansoft: "Para mi tanto Java para el backend (he currado con ello durante más de 10 años), como AS3 - flex4 (4 años trabajando) para el front son las dos combinaciones perfecta de como conseguir hacer un código estructurado, en capas, con tus infaces y legible perfectamente en base a patrones de diseño."
No puedo estar más de acuerdo contigo. Pero en el caso de Flex4, el mundo se está moviendo hacia otro lado. Te recomiendo que veas, si no lo conoces ya, el tema de polymer. No llega a lo que es Flex, pero al menos se aproxima algo.
Por definición de thread, diría que un mismo thread no puede atender distintas peticiones simultáneamente. Ni de forma paralela ni de forma concurrente. Igual se puede rehacer un poco la noticia :) . Ah, el modelo de actores de akka no es single-thread de por sí, a menos que el redactor quiera decir 'por actor'. En ese caso sí se puede decir que hay una 'apariencia' de thread único _por actor_. Como dice su doc: "Akka actors conceptually each have their own light-weight thread"
@Luis
Usé la expresión "simultaneamente" en vez de "paralelamente" o "concurrentemente" ya que esas dos últimas palabras son las que usamos para expresar "en el mismo instante de tiempo". ¿Sería mejor "intercaladamente"?
@logongas
Creo que sí, 'interacaladamente' sería más correcto. E.g. se podría decir "(...) múltiples peticiones de forma aparentemente simultánea (esto se consigue intercalando el procesado de las diferentes peticiones)".
Sinceramente a corto plazo no es posible que Nodejs quite lo que Java EE ha hecho, que puntos fuertes tiene Java?, sus APIs, como por ejemplo JPA, que hizo posible la estandarización de los ORMs, tengo rato jugando con Nodejs para proyectos propios y trabajando con Java EE en empresas y el punto que mas fuerte de Java EE son los ORM's, en Nodejs aun no existen de la talla de los que tenemos en Java.
Javascript por su parte avanza muy rapido, con ES6 incorporan clases y herencia de la forma clasica, aquel que dice que no se puede tener un buen código legible en javascript esta equivocado, el uso del modo estricto asi como los clousures ayudan, asi como la incorporacion de palabras reservadas como let y const en la declaracion de variables estan dando la robustes a javascript de la que siempre se han quejado los javeros, un error muy comun es querer programar en javascript como se programa en java, pero de algo no me queda duda, javascript es el futuro pero java no morira.
Se que JPA e Hibernate ha sido un gran impulso en java. Pero como ha sucedido con PHP y Doctrine. En el mundo JavaScript de empieza a tejer nuevos ORM's.
Lo que hay que tomar en cuenta es la Velocidad con la que aparecen estas nuevas librerías. En su mayoria para trabajar con Nodejs
Ej.
sequelizejs, persistencejs, node-orm2, bookshelfjs, mapper etc. etc...
un saludo...
El futuro de la web siempre ha sido y será JavaScript, por otro lado Java quedará para aplicaciones empresariales medianas/grandes como hasta ahora, en donde incluso NodeJS está incursionando también, pero que por cuestiones de madurez, en la mayoría de casos no es la opción elegible.
NodeJS te permite realizar aplicaciones web realmente rápido. Las librerías que existen y que se crean a diario, te facilitan enormemente el trabajo. Solo basta mirar NPM y ver la cantidad de paquetes que existen y que tienes a disposición. Su API estándar es realmente sencilla, solo hay que entender Streams, TCP/HTTP, Buffer, etc. Además, su integración con AngularJS es perfecta, puedes usar view engines como Jade, EJS, preprocesadores como Stylus cuya compilación es automática, etc.
Java, por otro lado, no le veo mucha evolución y es justamente por esta razón que ha sido la opción de facto entre las empresas. Su lentitud entre versiones hace que las aplicaciones hacen que no se necesite migrar a una nueva versión cada poco tiempo.
Oracle no invierte lo suficiente en Java, eso es notorio. Con cada versión solo se arregla rendimiento, bugs, y se mejora las APIs de Java EE. Sin embargo, el lenguaje sigue siendo el mismo de hace muchos años, salvo la incursión de Lambdas, que C# tenía hace casi una década. C# es un ejemplo claro de un lenguaje que evoluciona, que mejora, que a su dueño le importa.
Sinceramente preferiría a Ceylon o Groovy como lenguaje predeterminado para la JVM, a Java con Oracle no le veo ningún futuro.
No estoy de acuerdo en que los nuevos frameworks sean lo mejor: http://www.haneycodes.net/to-node-js-or-not-to-node-js/
MGGM, Java tiene tan poco futuro como lo tiene C, SQL o incluso Cobol. En cambio, cada vez que oigo hablar maravillas de Node.JS o Angular.JS me acuerdo del Clipper o del Natural. Y a javascript le salva la presentacion en el navegador, vamos, jquery y html5.
Vamos a ser serios, una cosa es de lo que habla la "comunidad" y otra lo que se usa de verdad. En una de esas cosas que organiza JavaHispano de vez en cuando uno de los conferenciantes (de hibernate, creo) pregunto a la audiencia (toda ella formada por tipos suficientemente frikis como para ir despues de trabajar a oir hablar de Java) quien habia trabajado en Scala, grooby y unas cuantas cosas de esas que suenan mucho (igual no eran scala y grooby exactamente, pero eran cosas asi). Solo levanto la mano uno cada vez. Y ademas siempre el mismo.
Una cosa puede generar ruido en la blogocosa, pero al final lo que vale es el "Su lentitud entre versiones hace que las aplicaciones hacen que no se necesite migrar a una nueva versión cada poco tiempo" que tu mismo apuntas. Una empresa no puede hacer una reingenieria de una aplicacion de su core porque alguien ha descubierto que en Ruby hay mixines, molan mucho y lo petan...
Lo mejor de Java es que es estable y no esta cambiando cada cuatro dias. Que cada vez es mas rapido. Que los cambios en la arquitectura de las aplicaciones (dependen de modas) se hacen con frameworks ajenos al lenguaje en si, asi que si de pronto el "servlet director" es una antigualla y lo que molan son los aspectos cambias el framework y haces la aplicacion de nuevo (que se escribe pronto) pero como no cambias demasiado con suerte no tienes que convencer a los administradores que tienen que cambiar los servidores de aplicaciones o la configuracion de los los balanceadores. Ni esperar a que los que conocen la logica de negocio aprendan otro lenguaje o a que la sangre nueva aprenda la logica de negocio.
C# evoluciona mas, es cierto, pero lo que importa de C# no tiene nada que ver con las lambdas (en la proxima de javahispano, que alguien pregunte quien las usa en su trabajo) ni con ninguna de las cosas que se leen en blogs, si no con que, si quieres, puedes gestionar tu mismo la memoria sin tener que esperar a que el GC libere la memoria o acceder al hardware directamente. Es lo que envidio de C#, tener un free como el de aqui (https://msdn.microsoft.com/es-es/library/aa664786(v=vs.71).aspx) para liberar la memoria si no puedo esperar al GC o poder plantar un valor en una direccion de memoria. No lo voy a usar casi nunca, pero ese casi es suficiente para tener que usar C++ (que tambien esta muy bien,por cierto).
Que yo sepa COBOL es el lenguaje más usado para aplicaciones empresariales. Posiblemente el nuevo COBOL sea Java y yo no lo veo como algo negativo para Java, sino todo lo contrario.
Aquí se ha comentado que en JavaScript aparece un framework de persistencia nueva cada semana, como algo positivo. Pero para alguien que tiene que tomar una decisión pensando en su organización y sus usuarios (y no en la adrenalina de los programadores) eso es algo negativo. Ellos quieren que dentro de cinco años el sistema siga funcionando y tenga soporte.
No nos comprariamos un coche si sabemos que posiblemente dentro de cinco años no habrá piezas de recambio para él, sin embargo nos encantaría usar Angular para una aplicación seria. Pero si Angular2 no es compatible con Angular1. Si es un producto de Google, la que descataloga productos sin ton ni son.
A nivel personal, JavaScript me parece un lenguaje muy malo. Cuando la industria se pasó de C++ a Java, ganamos, pero si la industria va a pasar de Java a JavaScript vamos a perder.
En realidad intentaba que eso fuera ironico porque C, SQL y Cobol tienen aun mucho futuro por delante aunque la gente se empeñe en decir que estan acabados.
De acuerdo en lo que dices sobre javascript.
Pues no parece muy descabellado el que empecemos a ver aplicaciones NodeJS empezar a ejecutarse en la JVM, para muestra un botón de lo que Oracle está probando para JDK9:
http://www.oracle.com/technetwork/oracle-labs/program-languages/overview/index.html
Soy Javero desde 1995. Eso no hace que deje de ver más allá de mis narices.
Hace tiempo escuche decir una frase "En una empresa la gente es la que cambia las empresas permanecen" , solo por poner un poco de analogía decir que alrededor de html y javascript se han montado un montón de framework. Muchos de los cuales han desaparecido o han sido sustituidos por otros. Pero html por si mismo sigue ahí y no hay que lo reemplace.
Html 6 y ES 6 ya están a la vuelta de la esquina.
Html 6 por si mismo ya se ha convertido en un framework. y si le añades los web components. Que tenemos?
JavaScript sigue dando sorpresas, os acordáis de http XMLHttpRequest/Ajax, pues ahora son los Workers. Personalmente considero que dará más sorpresas.
Es cuestión de tiempo para que se forme un ecosistema de patrones de diseño y frameworks a su alrededor.
NodeJS es ligero, consume bajo recurso de Hardware, no produce tanta latencia a otros servidores. Es un nuevo mundo basado en Mensajes. Por que no aprovecharlo.
Solo he dado una miradita mental al futuro...
Comencé mi carrera profesional programando en JavaScript y PHP. Me encantaban los lenguajes con tipado dinámico. Se hacía todo a muy buen ritmo. Poco después, redescubrí Java y su tipado estático. Y me entraron los siete males. Me vi obligado a continuar con él por cuestiones laborales. En proyectos más o menos grandes y con mantenimiento a largo plazo. Cuando me tocó volver a programar en lenguajes con tipado dinámico, para mi sorpresa, me di cuenta de que me había enamorado de Java y su tipado estático, entre otras de sus características.
Actualmente, no quiero otra cosa que no tenga tipado estático. Tanto por la detección de errores en tiempo de compilación, como por las herramientas que existen para análisis y para reconstrucción del código. Y el autocompletado preciso en IDEs. Incluso el código se me hace mucho más fácil de asimilar con tanto tipo explícito. Se ha convertido en algo fundamental para mí. Mantener un gran proyecto sin esa característica se me hace una pesadilla.
Por eso no me puedo creer que realmente se esté planteando un futuro de completo dominio de JavaScript. Para proyectos pequeños puedo entenderlo. ¿Pero para proyectos empresariales de mediano-gran tamaño? Miedo me daría mantener eso :S .
Y que conste que siempre me ha gustado JavaScript. Y me ha gustado que ECMAScript 6 haya introducido todos esos conceptos que ya manejamos en Java y otros lenguajes (especialmente las constantes y el alcance de las variables a nivel de bloque). Pero para mí se sigue quedando corto por ese motivo que comento (y algún otro).
Justo ayer hubo una mesa redonda cuyo tema era java vs NodeJs. Autentia iba a grabarla así que imagino que en breve estará disponible y puede ser interesante el ver a pesos pesados de ambas partes defender lo bueno y malo de cada lenguage.
http://autentia.com/2016/01/12/java-vs-nodejs-el-encuentro-moderado-por-david-bonilla/
Además, el próximo martes 26 hay un meetup en Valencia sobre introducción a Vert.x
Meetup de Enero ValenciaJUG - Introducción a Vert.x
Decir que JavaScript es el futuro me parece un error,
JavaScript esta muy bien para para ciertas cosas, por ejemplo en cliente web, un cliente web sin javaScript es prácticamente inconcebible, pero en el tema del servidor es distinto, por ejemplo
Node hasta donde yo se, si quiero hacer temas de pki's? tiene algo parecido a x509 que me permita coger un certificado extraer datos comprobar su validez ver si la firma de un documento es valida etc...etc...
En cuanto a frameworks web a elegir esta muy lejos de Java y mucho mas lejos de la JVM en general, JavaScript te obliga a que todo sea single thread, En Java puedes elegir programar en multithread o hacer una aplicación monothread asíncrona con Java NIO, Netty, Akka, Atmosphere, socket.io, vert.x....
Si me dan a elegir prefiero un lenguaje de programación que se ejecute en un entorno multithread y que pueda implementar asincronia, pero atarme a un lenguaje cuyo entorno de ejecución no me permita hacer un multithread me parece una limitación de cara a tu futuro muy grande.¿Cuando comienzas un proyecto puedes asegurar que nunca vas a poder necesitar multithread?.
El tema de la información, puedes buscar información de prácticamente cualquier biblioteca o framework de Java y encontraras información y libros seguro.
Existen bases de datos por ejemplo Cassandra que están escritas enteramente en Java...¿Hay alguna Base de datos escrita en Node?
Ademas del plus de complejidad que supone la asincronía, una aplicación asíncrona monothread esta llena de callbacks por todas partes, fácil lo que es fácil de leer, no es...
doStuff(writetoFile(transformData(getRequestData())))
Ahora que se esta tendiendo hacia la programación funcional, minimizar en lo posible el estado para evitar problemas con concurrencia...JavaScript se pone a implementar las "clases". Al revés de todos.
Desde mi punto de vista Node mola....si quieres hacer una aplicación que conecte a una base de datos, y devuelva un front y poco mas, es asíncrono sin mucha carga de operaciones lógicas para el procesador... pero si vas a hacer tareas como análisis de big data, pki's, machine learning, operaciones matemáticas pesadas (Recordemos que las operaciones lógicas pesadas bloquean el thread en el que se ejecutan), Node simplemente no sirve.
Ahora mismo si tuviera que apostar por un lenguaje no JVM con poca información y experimental apostaría por Rust o Go, o incluso Elixir.
Un saludo.
Muchos programadores tienden a desconocer aspectos del negocio de las empresas donde trabajan, principalmente lo relacionado a la administración y gobierno de TI .Esto ha hecho que en muchas empresas se tomen decisiones incorrectas lideradas por lo programadores, quienes en ciertas ocasiones se guían por la tendencias de moda, que generalmente permiten hacer las cosas más escalables o que permiten hacer el trabajo del programador más fácil. Pero esto deja de lado los intereses reales de las empresas.
Personalmente conocí el caso de una empresa de gran tamaño que usaba alrededor de 20 frameworks diferentes para el desarrollo web, toda una pesadilla para la integración, esto se debió a que no había un rol de toma de decisiones centralizado y que velara por los intereses de la empresa, por el contrario, las decisiones a nivel del uso de tecnología siguieron los intereses de los proveedores y en ultimas de los programadores.
Esta problemática se ha vuelto en contra de los programadores, quienes en ocasiones son vistos con malos ojos por parte de la empresa. Porque la administración de gran cantidad de frameworks de lenguajes y de tecnologías resulta ser costosa e ineficiente para empresa, esto se hace muy evidente a la hora de integran aplicaciones con tecnologías diferentes.