Discussion :

[Hinault Romaric]

PayPal abandonne Java pour JavaScript
Node.js a permis un gain important en performance et en temps à l’entreprise

JavaScript est très critiqué par certains pour ses faiblesses. Pourtant, au fil du temps, le langage continue à jouir d’une grande popularité sur le Web.

PayPal, le service de paiement en ligne, a récemment abandonné le langage Java sur ses serveurs pour Node.js, avec un gain considérable dans le rendu des pages Web.

Jeffe Harrell, directeur de l’ingénierie chez PayPal, décrit dans un billet de blog, les avantages architecturaux de passer de Java à JavaScript. « Imaginez un développeur HTML qui doit demander à un développeur Java de lier la page A et B », explique Harrell.

Devant ce problème, PayPal devait avoir recourt des développeurs ayant des compétences différentes pour l’application Web et l’application serveur. « Chez PayPal, le bloqueur primaire a toujours été la limite artificielle que nous avons établie entre le navigateur et le serveur », explique celui-ci.

Pour surmonter cette situation, PayPal s’est tourné vers Node.js, qui a permis à la fois d’écrire les applications devant s’exécuter dans le navigateur et les applications serveurs en JavaScript. « Il [N.D.L.R : Node.js] unifie nos spécialités pour nous permettre de créer une équipe qui comprend et réagit rapidement aux besoins des utilisateurs à n’importe quel niveau dans la pile de technologie », justifie Jeffe Harrell.

PayPal a dans un premier temps commencé à utiliser Node.js comme plateforme de test avant de passer celui-ci en production cette année.

Avant d’adopter la plateforme de développement JavaScript événementiel, PayPal par mesure de prudence, à développer un équivalent en Java de son application Node.js. Pour l’application Node.js, il a fallu deux ingénieurs et pratiquement la moitié du temps utilisé par cinq personnes pour créer la déclinaison Java. L’application Node.js avait 33 % moins de lignes de code et 44 % moins de fichiers utilisés, que l’application Java.

Les tests de performances en production sur du matériel identique ont montré que l’application Node.js était de 35 % plus rapide que son équivalent Java. S’appuyant sur ces résultats, PayPal envisage de développer toutes ses applications Web orientées client avec Node.js. « Il y a une douzaine d’applications dont la migration a été amorcée », écrit Harrell.

Source : Paypal


Et vous ?

Qu'en pensez-vous ? JavaScript avec Node.js est-il une meilleure solution pour les services Web que Java ?

[Paul TOTH]

Qu'en pensez-vous ? JavaScript avec Node.js est-il une meilleure solution pour les services Web que Java ?

Je ne suis pas fan de Java, mais je pense surtout que l'équipe de développeurs JS de Paypal est plus réactive que l'équipe de développeurs Java, voir plus compétente et là ça fait un grosse différence.

D'autre part, JS a depuis quelques années était l'objet d'un gros travail d'optimisation part plusieurs acteurs, ce qui l'a propulsé vers le haut...Java n'a pas connu cette course à la performance pour autant que je sache. Google a d'ailleurs décidé de créer la machine virtuelle Dalvik pour Android jugeant que celle de Java n'était pas adaptée aux smartphones.

Ceci dit, je n'aime pas Java, mais je n'ai pas que de l'amour pour JS, son modèle objet est des plus casse pied.

[LSMetag]

Qu'en pensez-vous ? JavaScript avec Node.js est-il une meilleure solution pour les services Web que Java ?

Je n'ai jamais utilisé NodeJS (je ne suis d'ailleurs pas du tout fan de JS), mais j'ai bien constaté que JS était vraiment très performant et léger. J'ai au contraire constaté l'aspect poussif de Java (peut-être OpenJDK est-il meilleur ?), pas simplement niveau développement, exécution et maintenabilité, mais également côté installations serveur. Sans oublier le manque de réactivité d'Oracle niveau support, contrairement à l'époque où Java était chez Sun...

Et bien sûr, il y a la question des coûts. Javascript et NodeJS sont totalement gratuits.

Donc bonne initiative de Paypal. Par contre, Oracle devrait commencer à se poser des questions... Si des grands comptes se mettent à abandonner Java, c'est qu'il y a un pb...

[_skip]

Je veux pas recommencer un énième troll java vs reste du monde mais tout de même :

Je n'ai jamais utilisé NodeJS (je ne suis d'ailleurs pas du tout fan de JS), mais j'ai bien constaté que JS était vraiment très performant et léger. J'ai au contraire constaté l'aspect poussif de Java (peut-être OpenJDK est-il meilleur ?), pas simplement niveau développement, exécution et maintenabilité, mais également côté installations serveur. Sans oublier le manque de réactivité d'Oracle niveau support, contrairement à l'époque où Java était chez Sun...

Euh non je pense pas que ce genre de critique se vérifie complètement, les performances de java sont carrément bonnes à l'heure actuelle. On est plus dans les années 90. Et niveau maintenabilité il y a l'avantage amené par l'aspect statique du typage et la compilation, à qualité de code égale, je préfère 100 fois maintenir une app d'un million de lignes en java qu'en javascript.

Et bien sûr, il y a la question des coûts. Javascript et NodeJS sont totalement gratuits.

Faire du java cela coûte quoi? Autant les outils que les frameworks sont gratuits et largement aboutis.

Pour en revenir à l'article, je pense que c'est un peu chaud de tirer des conclusions JS > java ou Java > js. Cela dépend aussi de l'équipe et des stacks qui ont été employées. Si côté java ils ont utilisé du JSF + EJB ou d'autres standards du même style, je veux bien croire qu'ils devaient être plus nombreux pour faire moins. Ca aurait été plus intéressant si on avait su exactement ce qui était comparé ici. Car "java" tout seul pour une application web ça ne nous dit pas grand chose, y'a une infinité de possibilité qui peuvent donner des résultats très variables. Ca peut être des des pommes, des poires, des choux et des patates...

[Washmid]

Je veux pas recommencer un énième troll java vs reste du monde mais tout de même :



Euh non je pense pas que ce genre de critique se vérifie complètement, les performances de java sont carrément bonnes à l'heure actuelle. On est plus dans les années 90. Et niveau maintenabilité il y a l'avantage amené par l'aspect statique du typage et la compilation, à qualité de code égale, je préfère 100 fois maintenir une app d'un million de lignes en java qu'en javascript.



Faire du java cela coûte quoi? Autant les outils que les frameworks sont gratuits et largement aboutis.

Pour en revenir à l'article, je pense que c'est un peu chaud de tirer des conclusions JS > java ou Java > js. Cela dépend aussi de l'équipe et des stacks qui ont été employées. Si côté java ils ont utilisé du JSF + EJB ou d'autres standards du même style, je veux bien croire qu'ils devaient être plus nombreux pour faire moins. Ca aurait été plus intéressant si on avait su exactement ce qui était comparé ici. Car "java" tout seul pour une application web ça ne nous dit pas grand chose, y'a une infinité de possibilité qui peuvent donner des résultats très variables. Ca peut être des des pommes, des poires, des choux et des patates...

+1000

Comparer un framework (node.js) à un language (java) c'est sans grande signification.

Et le côté statique permet de faire des choses aussi basiques qu'indispensables comme autoriser le factoring, la navigation dans le code, etc. etc.

[Voyvode]

Double the requests per second vs. the Java application. […] our initial performance results were using a single core for the node.js application compared to five cores in Java. We expect to increase this divide further.

Entre les lignes : notre code Java était pourri.

There’s a disclaimer attached to this data: this is with our frameworks and two of our applications.

[Edit]
http://benchmarksgame.alioth.debian....=java&data=u64
Java a une performance brute clairement supérieure à JavaScript (et un code source effectivement plus lourd).

PayPal obtient de meilleurs performances avec Node.js parce que :

1. leur code Java était, au mieux, mal adapté ;
2. ils se sont retroussés les manches avec Node.js ;
3. ils veulent faire du buzz trollesque.

[fr1man]

Je rejoins tout à fait _skip.
J'adore ces superbes analyses avec de beaux graphiques pour prouver qu'on a raison, alors qu'on ne sait rien sur la façon dont tout a été développé.

[la.lune]

Ce que j'aime juste souligner ici avant de dire ce que je pense, c'est que je me demande quand est ce que les gens vont oublier l'idée que java est lent en exécution?

Et comme _skip l'a mentionné le java d'aujourdui n'est pas le java des années 90, le moment où on a voulu créer le concept d’écrire une seule fois et exécuter partout utilisant les machines virtuelles.

Java a pourtant des performances à l’échelle de C/C++. A titre d'info, il faut savoir que ce n'est pas un bon matin que Facebook a décidé de compiler son code php en C++, puis en binaire, mais c'est après des analyses qui sont bien faites sur tous les autres langages.

Je vous invite à lire la présentation "Facebook architecture de 600 millions d'utilisateur", ici, sur la 24e slide, ils ont présenté les résultats des performances entre les langages comme illustre cette image:



Au lieu d'utiliser java qui dépasse de très loin php en performance, ils ont choisit de profiter du petit gain que C++ en a au dessus de java.

Comme vous voyez java est très performant devant ces concurrents sur le web excepté relativement JavaScript qui n'est pas sur la graphe .

J'ai vu un exemple avec de petit portion de code que vous pouvez même tester par ici, un même code qui s’exécute 1 minute 16 secondes en python, et 1 minute 9 secondes en php, et 41 seconde en Perl, s’exécute en seulement 18 seconde en java.

Mais il ne faut pas penser que c'est le seul côté que java gagne en performance, sur script à longue durée, mais c'est plutôt en trafic et en activités que les ingénieurs qui ont conçu Java EE ont fait le grand boulot. Ça ne va pas s'observer en exécuter une requête ou deux, mais quand vous allez exécuter des milliers de requêtes à la fois.

Une seule servlet(java) vivant répond à un millier de requête à la fois, le moment où par exemple php créer un nouveau programme pour chaque requête, étant donné qu'il est basé sur le modèle CGI(Common Gateway Interface). C'est pour cela que beaucoup sites à fort trafic choisissent java vu sa robustesse.

Pour ce qui est Java vs JavaScript côté serveur, d'abord c'est que personne ne peut nier les performance de node et sa légèreté qui sont aussi relatives.

J'aime bien Node.js sur le fait que tu crée ton propre serveur et tu choisit les modules à charger et tu peux choisir les objets que tu veut garder en mémoire tout long de la vie du serveur, car ce qui fait la force d'une plateforme web c'est composants serveurs vivant ou mort sous la décision du développer.

Alors en Java EE, ils ont voulus standardiser les choses et ne pas obliger le développeur à créer ses propres serveurs, mais créer juste les composants et paramétrer leurs cycle de vie.

Ainsi, ce qui fait ce ce n'est pas nous même qui gèrent nos composants mais c'est le serveur(midlware), lui aussi qui s’exécute sur la machine virtuelle java, donc quelques milliseconde en retard et quelques charges en mémoire qui font que JavaScript lui dépasse.

Mais a mon avis, vu que java c'est du compilé contrairement à JavaScript, si on pourrait développer avec comme on développe avec Node.js, mais avec une bonne architecture, java dépasserait bien JavaScript.

Mais tout reste que côté architecture et bonne structure des applications, java ne se compare pas à JavaScript, et Java EE ne se compare pas à Node.js. De même que les framwork et les outils de développement, test, débogage, intégration continue.... Tout cela, doit être pris en compte et là je rejoint ce que _skip a mentionné.

[Mr_Exal]

Entre les lignes : notre code Java était pourri.




[Edit]
http://benchmarksgame.alioth.debian....=java&data=u64
Java a une performance brute clairement supérieure à JavaScript (et un code source effectivement plus lourd).

PayPal obtient de meilleurs performances avec Node.js parce que :

1. leur code Java était, au mieux, mal adapté ;
2. ils se sont retroussés les manches avec Node.js ;
3. ils veulent faire du buzz trollesque.

Tout est dit. Leur code java devait vraiment être merdique niveau optimisation ...

[garheb]

Node.js est un excellent outil, ça fonctionne très bien, c'est relativement simple à utiliser.

Par contre, AUCUN moduleque j'ai pu utiliser (parmis les plus populaires) n'ont une API à jour. Une partie non négligeable des fonctions disponibles dans un module ne sont pas connues de la documentation officielle. C'est absolument lamentable. Et ça gâche totalement node.js.

En plus de ça, le fait que le typage soit faible avec js rend l'utilisation d'un IDE complétement inutile et coder du node.js devient un cauchemar.

De l'autre coté, on a un langage connu pour être verbeux, mais dont la documentation est impeccable et le typage fort. En l'état actuel, je n'hésiterais pas une seule seconde dans le choix entre node et java.

Mais Paypal est une grande entreprise, qui codera sans doute en interne ses propres modules ou les modifiera de manière à ce que tout soit clair dans la documentation. Mais pour un projet lambda, ce n'est pas toujours possible.

NB: l'application utilisant node.js que j'ai eu à faire comportait: lodash, express, jade, knockout, d3 et cradle

[Mickael_Istria]

Je pense qu'adopter JavaScript cote serveur, c'est se tirer une balle dans le pied en terme de maintenance compare a Java. Java est quand meme ultra-robuste et bien que certains frameworks soient lourds, la plupart sont clairement des solutions de tres bonne qualite a des problemes concrets de l'industrie informatique (persistence, queuing, messaging, securite...). Toutes ces problematiques ont un cout sur les performances, qui vaut souvent le coup d'etre paye.
En JavaScript, il n'y a (a ma connaissance) rien d'aussi mature pour l'instant, on est en train de tout reinventer, pour s'en plaindre dans 10 ans de la meme maniere que certains se plaignent de JEE maintenant. Quel aura ete le benefice au final? Je suis plutot pessimiste a ce sujet...

Ok, il y a un gain de performance sur certaines applis, mais au final ce gain est peut-etre plutot lie au fait qu'au lieu de consommer plus de perf cote server et d'y faire plus de calcul, on met de plus en plus de dynamicite cote client. C'est un peu facile de dire "on est plus performant" alors que la verite est "on fait moins de chose cote serveur pour les faire faire au client".
Au final, dans bien des cas, on a du contenu quasi-statique (un application) qui est envoye au client, et c'est le client qui se debrouille. Niveau serveur, ca demande pas beaucoup plus que de faire un Hello World.

Bref, je suis peut-etre ultra pessimiste, mais je pense que la mode du tout JavaScript a vraiment du mal a etre justifiee techniquement. Des applis dynamiques en JavaScript dans des navigateurs, ok; mais mettre en place des services et servir des donnees en JavaScript, je vois pas ce qu'on peut en attendre de mieux qu'en Java.

[LSMetag]

Je veux pas recommencer un énième troll java vs reste du monde mais tout de même :



Euh non je pense pas que ce genre de critique se vérifie complètement, les performances de java sont carrément bonnes à l'heure actuelle. On est plus dans les années 90. Et niveau maintenabilité il y a l'avantage amené par l'aspect statique du typage et la compilation, à qualité de code égale, je préfère 100 fois maintenir une app d'un million de lignes en java qu'en javascript.



Faire du java cela coûte quoi? Autant les outils que les frameworks sont gratuits et largement aboutis.

Pour en revenir à l'article, je pense que c'est un peu chaud de tirer des conclusions JS > java ou Java > js. Cela dépend aussi de l'équipe et des stacks qui ont été employées. Si côté java ils ont utilisé du JSF + EJB ou d'autres standards du même style, je veux bien croire qu'ils devaient être plus nombreux pour faire moins. Ca aurait été plus intéressant si on avait su exactement ce qui était comparé ici. Car "java" tout seul pour une application web ça ne nous dit pas grand chose, y'a une infinité de possibilité qui peuvent donner des résultats très variables. Ca peut être des des pommes, des poires, des choux et des patates...

Je sais que Java et ses frameworks sont bien pour de très grosses applis, devant gérer beaucoup d'accès concurrentiels. La communauté est très importante aussi. Le langage en lui même est très fonctionnel et beaucoup de créations de la communauté sont disponibles gratuitement.

Alors oui il aurait été bien d'avoir plus de détails sur comment avait été développé Paypal.

Chaque fois que j'ai utilisé Java, il fallait toujours rajouter un serveur d'applications bien lourd, style JBoss, WebsPhere,... La grosse usine à gaz.
J'ai utilisé Eclipse (Juno, même Kepler). Ok c'est bourré de fonctionnalités, mais ça rame quand même pas mal. Par contre, j'ai apprécié IntelliJ de JetBrain, mais peu utilisé en entreprise.

Tous les projets sur lesquels j'ai dû bosser, il fallait payer. Pour le support d'Oracle, pour le serveur d'applications WebSphere avec Portal et WCM (et même pour un Eclipse modifié par IBM). Ces trucs étaient tellement lourds qu'il était impossible de les installer sur nos machines en local. D'ailleurs ils n'ont acheté qu'une licence tellement c'était cher, nous privant de la possibilité de debugguer (un seul serveur pour tout le monde). Et les utilisateurs en étaient mécontents.

Je préfère Java question développement, mais je sens toujours une lourdeur, même sur des applications simples. Au contraire, Javascript, on est toujours dans l'"instantané" quand on le voit à l'oeuvre.

Je ne vois pas l'intérêt de Java/J2EE si le projet n'est pas énorme, avec de très gros besoins (IOC, AOP, internationalisation, une tonne d'utilisateurs en simultané, Log4J, 10 projets,...).
Ces fameux graphiques ont quand même été faits en comparant 5 coeurs avec Java à un seul coeur avec JS. Alors oui peut-être que ça avait été programmé avec les pieds.

Il est idiot de dire JS>Java et vice versa je suis d'accord.

Mais je suis assez surpris qu'un gros compte décide de refondre toute son infrastructure Java (qui a dû coûter bonbon en matos et ingénieurs et qui a fait des années) avec une techno bien différente, qui n'est pas encore mature.

[la.lune]

Chaque fois que j'ai utilisé Java, il fallait toujours rajouter un serveur d'applications bien lourd, style JBoss, WebsPhere,... La grosse usine à gaz.

Je me demande pourquoi tu dis que tu dois rajouter tel serveur, pourquoi "rajouter", quand vous utilisez les EJB, ranger Tomcat à côté, et utiliser un seul serveur qui a toutes les fonctionnalité.

Tous les projets sur lesquels j'ai dû bosser, il fallait payer.

Pourquoi payer, alors qu'il y a des version open source de conteneur d'EJB, il y a Glassfish de sun, fourni part défaut en téléchargeant Netbeans.

Pour le support d'Oracle, pour le serveur d'applications WebSphere avec Portal et WCM (et même pour un Eclipse modifié par IBM). Ces trucs étaient tellement lourds qu'il était impossible de les installer sur nos machines en local. D'ailleurs ils n'ont acheté qu'une licence tellement c'était cher, nous privant de la possibilité de debugguer (un seul serveur pour tout le monde).

Quand vous voulez acheter une Ferrari c'est que vous êtes riche et il faut assumer aussi la responsabilité de la consommation.

Mais vous n'êtes pas obligé d'acheter un serveur WebSphere pour debugguer, dans le moment où on installe par exemple GlassFish dans nos PC local, et on debugguer.

Moi, je dis que ce qu'empêche au gens d'utiliser les versions free et opensource, les spécifications sont les même que pour JDK et OpenJDK, j'allais dire que c'est le support qui manque pour les version free.

[LSMetag]

Je me demande pourquoi tu dis que tu dois rajouter tel serveur, pourquoi "rajouter", quand vous utilisez les EJB, ranger Tomcat à côté, et utiliser un seul serveur qui a toutes les fonctionnalité.

Pourquoi payer, alors qu'il y a des version open source de conteneur d'EJB, il y a Glassfish de sun, fourni part défaut en téléchargeant Netbeans.



Quand vous voulez acheter une Ferrari c'est que vous êtes riche et il faut assumer aussi la responsabilité de la consommation.

Mais vous n'êtes pas obligé d'acheter un serveur WebSphere pour debugguer, dans le moment où on installe par exemple GlassFish dans nos PC local, et on debugguer.

Moi, je dis que ce qu'empêche au gens d'utiliser les versions free et opensource, les spécifications sont les même que pour JDK et OpenJDK, j'allais dire que c'est le support qui manque pour les version free.

Pour être franc, je ne vois pas trop une entreprise utiliser GlassFish OpenSource Edition. Donc oui même pour GlassFish il faut passer à la caisse.

Sur un projet Websphere qui utilise ses spécificités portail (WCM et WPA), pas possible d'installer un autre serveur d'applications pour débugguer.
Je ne suis pas responsable des choix techniques, malheureusement. C'est une DSI qui a décidé à la place des gens sur le terrain.

Qu'une entreprise utilise OpenJDK, je n'ai encore jamais vu. Ils sont tellement attaché au support (utile ?).

Sinon, j'avais commencé à développer une petite appli console pour garder un suivi des tâches en cours. Récupération de données, calculs et écriture du résultat dans document Excel.
Je l'ai ensuite portée derrière en .NET. Performances n'ayant rien à voir, beaucoup moins de lignes de code (merci LINQ et les Lambda expressions).
Pourtant, à part les requêtes LINQ, je n'ai fait qu'un portage de code.
Après peut-être qu'il y a des subtilités entre les 2 technos.

[Saverok]

Mettons face à face un 4x4 baroudeur et une micro citadine
Je vais en en montagne en traversant des chemins de terre tout pourris
j'arrive 5x plus vite à ma destination avec le 4x4
Conclusion : le 4x4 est meilleur et je vais équiper toute la flotte de mon entreprise avec des 4x4!!

[Markand]

Personnellement je pense que les graphismes ont du sens.

1. Node.js est un framework javascript extrêmement simple. De base, il fournit qu'une API JavaScript pour coder une application rapidement. On a aucun système de template, de session, d'ORM de base. Ça peut justifier un gain en rapidité.

2. Node.js est codé en C++. Bien que Java soit aussi un langage compilé, le C++ reste plus performant dans certains domaines.

3. Pour avoir travaillé dans une entreprise où on faisait du développement Java. Je peux assurer que ce n'est pas que le code qui fait la rapidité. Pour installer une application web java il faut un conteneur (Tomcat, Glassfish, JBoss, etc.) Ces derniers rajoutent une couche d'exécution supplémentaire ce qui ralentit encore une fois l'application. De plus, la plupart des applications web java inclue des gros framework nécessitant pas mal de ressources (JSF, Primefaces, Hibernate (ou JPA), Spring, etc).

Mais effectivement, il aurait été intéressant de savoir plus en détails ce qui était utilisé côté Java chez PayPal.

[Sange844]

Personnellement je pense que les graphismes ont du sens.

1. Node.js est un framework javascript extrêmement simple. De base, il fournit qu'une API JavaScript pour coder une application rapidement. On a aucun système de template, de session, d'ORM de base. Ça peut justifier un gain en rapidité.

2. Node.js est codé en C++. Bien que Java soit aussi un langage compilé, le C++ reste plus performant dans certains domaines.

3. Pour avoir travaillé dans une entreprise où on faisait du développement Java. Je peux assurer que ce n'est pas que le code qui fait la rapidité. Pour installer une application web java il faut un conteneur (Tomcat, Glassfish, JBoss, etc.) Ces derniers rajoutent une couche d'exécution supplémentaire ce qui ralentit encore une fois l'application. De plus, la plupart des applications web java inclue des gros framework nécessitant pas mal de ressources (JSF, Primefaces, Hibernate (ou JPA), Spring, etc).

Mais effectivement, il aurait été intéressant de savoir plus en détails ce qui était utilisé côté Java chez PayPal.

1 La comparaison faite par Paypal aurait eût beaucoup d'intérêt avec GWT

2 Sauf que le code exécuté par NodeJS est interprété et qu'en perfs brutes JS<Java généralement. Et puis la JVM n'est pas codée en Java.

3 Là par contre, je dois avouer que J2EE est une sacrée usine à gaz que j'évite autant que possible.

[la.lune]

Je vois ici des gens écrire le terme "J2EE", et bien je vous rappel que ce terme n'existe pas, il existe "Java EE", J2EE est un terme très ancien qui désigné Java 2 Edition Entreprise, lorsque Java était en version 1.4, ce terme n'est plus à la une depuis long temps.

Nous somme à Java la version 1.7, qu'on dit tout court Java 7. Alors on dit tout simplement Java EE (Java Edition Entreprise) comme on dit Java SE , ou Java EE 7 pour préciser la version.

A noter aussi que le Java SE et EE n'évoluent pas ensemble, c'est recemment que nous somme passé à Java EE 7 alors que la bêta de Java SE 8 est déjà sortie.

[LSMetag]

Je vois ici des gens écrire le terme "J2EE", et bien je vous rappel que ce terme n'existe pas, il existe "Java EE", J2EE est un terme très ancien qui désigné Java 2 Edition Entreprise, lorsque Java était en version 1.4, ce terme n'est plus à la une depuis long temps.

Nous somme à Java la version 1.7, qu'on dit tout court Java 7. Alors on dit tout simplement Java EE (Java Edition Entreprise) comme on dit Java SE , ou Java EE 7 pour préciser la version.

A noter aussi que le Java SE et EE n'évoluent pas ensemble, c'est recemment que nous somme passé à Java EE 7 alors que la bêta de Java SE 8 est déjà sortie.

Dites ça aux entreprises qui font leurs annonces sur les sites de recrutement (et aux sites de recrutement).

[ddoumeche]

1 La comparaison faite par Paypal aurait eût beaucoup d'intérêt avec GWT

2 Sauf que le code exécuté par NodeJS est interprété et qu'en perfs brutes JS<Java généralement. Et puis la JVM n'est pas codée en Java.

3 Là par contre, je dois avouer que J2EE est une sacrée usine à gaz que j'évite autant que possible.

2> Le moteur V8 de Node.js compile le code Javascript en code machine dès lors qu'il y a un nombre suffisant d'itérations. Mécanisme inspiré d'HotSpot d'ailleurs. Cela n'a donc rien à voir avec le langage utilisé pour coder Node.js

Sur le fond du problème, Twitter est passé de RoR à Java avec un gain de performance x3 (je ne pense pas que RoR bénéficie des mêmes mécanismes d'optimisation que les jvm). Mais ca n'a pas fait un tel foin sur développer.com.

Il me semble donc que les consultants envisagent de réécrire les anciennes applis Java. De toutes manières, de nombreuses arrivent en fin de vie, à commencer par les plus mal fichues, les utilisateurs s'en plaignent.

De la à constater que Node.js est 2x plus rapide ? C'est possible car il utilise un mécanisme asynchrone (que l'ont retrouve aussi sur Play! framework).
Mais par contre on perd énormément de choses : typage fort, débugage, tests unitaires, profiling, etc
Et on en arrive sur une plateforme immature, dont on fait les frais. Personnellement, j'ai donné pour ce genre de délire adolescent.

Mais après tout pourquoi pas, il faudra bien les refaire dans 10 ans parce que immaintenable. C'est bien cela le métier de consultant