Discussion :

[Hinault Romaric]

Nodyn : Node.js s’invite sur la machine virtuelle Java
le projet permet de combiner Java et Node.js pour des projets plus performants

« JavaScript est partout … ou est en passe de se retrouver partout. » Critiqué par certains, adulé par d’autres … le langage de script continue à conquérir des adeptes et s’étend désormais au-delà du Web.

JavaScript s’est retrouvé sur les serveurs grâce à Node.js. La plateforme de développement événementiel a conquis plusieurs entreprises américaines, qui ont abandonné notamment Java et Ruby On Rails pour celle-ci, avec des gains en performances et en productivité.

Fort de ce succès qui repose essentiellement sur son modèle de programmation événementiel I/O non bloquant, Node.js vient jouer sur les plates bandes du langage Java.

Grâce au projet open source Nodyn, Node.js peut désormais fonctionner sur la machine virtuelle Java (JVM). Soutenu par Red Hat, l’objectif du projet est de fournir une meilleure intégration entre Java et Node.js, et permettre ainsi aux applications Java de tirer parti des atouts de Node.js.

Avec Nodeyn, les développeurs seront également capables de faire travailler les applications Node.js avec les applications Java existantes. Ainsi, des travaux sont en cours pour intégrer le projet au sein de l’écosystème JBoss, et ses développeurs ont pour ambition de permettre son utilisation avec l’ensemble de l’univers Java, y compris les applications utilisant d’autres langages qui s’exécutent sur la JVM, à l’instar de Scala ou Clojure.

« Imaginez votre application Node fonctionner sur la JVM, ou avez immédiatement accès à tout ce que le monde Java peut fournir, directement à partir de JavaScript. Vous avez tout l’écosystème Java à votre disposition depuis DynJS. Pourquoi ne pas injecter un peu de JRuby ou Clojure à votre application », peut-on lire sur le site du projet

Nodyn est un surensemble de Node.js qui s’exécute au dessus de Dyn.js, un compilateur bytecode JavaScript, qui utilise les caractéristiques dynamiques de Java 7. Dyn.js est une alternative open source au moteur d’exécution JavaScript d’Oracle Nashorn. Le projet repose également sur Vert.x, un framework open source basé sur la JVM pour le développement d’applications Web évolutives « event-driven ».

Pour l’instant, le projet est encore au stade de préversion. Certaines API Node.js n’ont pas encore été intégrées à celui-ci.

Le site du projet

Le code source de Nodyn sur GitHub

Et vous ?

Que pensez-vous de ce projet ? Etes-vous attiré par celui-ci ?

[Calmacil]

Je suis toujours choqué de voir associés "Java" et "performance" dans la même phrase.

[Xinu2010]

Que pensez-vous de ce projet ? Etes-vous attiré par celui-ci ?

Pas du tout

[sizvix]

Du JS dans la JVM, c'est ce que Rhino fait déjà depuis de longues années ( je crois qu'il est même déjà intégré dans le JVM, à moins que ça ne soit dans certaine version )
Mais apparement Rhino dans Node à la place de V8 est plus rapide, ça serait ralentir le tout que de faire l'inverse...
Sans intérêt donc ...
Ça existe déjà, et depuis longtemps.
Si on veut avoir tout NodeJS avec plus de perf et en plus de l'intégration se Java et ses objets, autant voir remplacé V8 par Rhino, c'est bien plus efficace ...

[cryo94]

Je suis toujours choqué de voir associés "Java" et "performance" dans la même phrase.

Comparé à quoi ? Desktop ? Web ? Php ? Temps de développement ?

Que pensez-vous de ce projet ? Etes-vous attiré par celui-ci ?

NE connaissant pas node.js ca peut être intéressant.
En tout cas je trouve que la prise en charge d'autres technos dans java une bonne option pour le langage.

Microsoft attire de plus en plus de monde avec la possibilité de coder ses sites web en C# / C++ / C / VB

[abriotde]

Rhino n'est pas plus rapide que V8. Il peut juste rivalisé avec en mode compilé. Mais l'intérêt de javascript c'est en partie son mode interprété.
CF : http://fr.wikipedia.org/wiki/Rhino_(moteur_JavaScript) : "En mode compilé, Rhino peut rivaliser en performances avec SpiderMonkey, son équivalent implémenté en C, mais il serait toutefois victime de fuites de mémoire5. En mode interprété, la compilation du script est plus rapide, et aucune fuite de mémoire n'a lieu, mais le script est alors plus lent."

Rhino est toutefois un projet intéressant pour tout développeur java qui veut manipuler du javascript.

[lunatix]

Rhino est maintenant vieillissant : il a été developpé avant les evolution de la jvm pour faciliter le developpement de langages dynamiques (introduction du mot clé bytecode : invokeDynamic)
c'est plutot pas mal de voir apparaitre de nouvelles implementations nashorn et Dyn.js qui devraient etre bien plus performantes que rhino

[ymajoros]

Je suis toujours choqué de voir associés "Java" et "performance" dans la même phrase.

Une explication ou c'est juste un a priori ?

[Traroth2]

En gros c'est un moyen de rendre Vert.x compatible Node.js en utilisant DynJS et le module dynJS pour Vert.x. Si ça marche bien, ça peut être carrément intéressant. Faire tourner npm et Grunt, par exemple, ça pourrait être vraiment cool.

[leminipouce]

Du JS dans la JVM, c'est ce que Rhino fait déjà depuis de longues années

Nashorn est justement le remplacement du très vieillissant Rhino. Je l'utilise régulièrement et pour sûr, il est lent, très lent, trop lent.

Dyn.JS est juste une alternative FLOSS à Nashorn.

Nodyn s'appuie dessus pour faire tourner Node.js. Pour moi, ça me semble très intéressant !

[la.lune]

Fort de ce succès qui repose essentiellement sur son modèle de programmation événementiel I/O non bloquant, Node.js vient jouer sur les plates bandes du langage Java.

Je ne pense pas, et je ne pense non plus que Java vit une vraie limite devant la programmation événementielle I/O non bloquante. Ceci est tout juste une question d'architecture entre les technologies web de Java.

Les conteneurs de servlet ont choisit le modèle piloté par des thread et Node.js est basé sur le modèle événementielle.

Mais, je tiens à souligner que les travaux de Red Hat qui ont donné naissance à Vert.x deux ans après la sortie de Node.js, fut la réponse sur une architecture équivalente à celle de à Node.js dans le monde Java. Vert.x est aussi basé sur la programmation événementielle non bloquante .

Vert.x s'exécute de façon asynchrone, ainsi, les entrées sortie sont entre le client et le serveur sont gérés par un seul thread, qui gère toutes les requêtes de façon asynchrone. On peut bien évidement mettre en place un cluster, récupérer des données de façon asynchrone depuis le cluster au client.

Vert.x représente des performances considérables devant celle de Node.js, et spécialement le Vert.x écris en Java qui prend la première position en performance. Comme vous savez qu'on peut exécuter plusieurs langages sur le JVM.

Ce qui est surprenant c'est qu'avec Dyn.js(js->baytecode), les applications Vert.x écrites en JavaScript pressentent des performances énormes au dessus de celles écrites en JavaScript pour Node.js basé sur sur le moteur V8, qui lui aussi compile JavaScript en code machine.

Certes, Vert.x s'est inspiré de Node.js, mais là où je veux en venir ce qu' voit que la question n'est pas sur le langage Java, mais sur la manière dont les architectures sont conçus. Car on reproche aux technologie Web de Java de manque de légèreté( et non pas les performance car java est très performant) et consommation un plus en mémoire et en énergie.

Personnellement j'ai commencé à donner une grande importance à cette technologie Vert.x, et je me disais que j'aurais aimé que des expert sréalise un outils pareil et je croyais fortement à sa réalisation. Voila Vert.x qui réalise ce que je rêvais. Tu crées toi même ton propre serveur http et tu paramètre tes composants comme tu veux.

Tout reste que je vois que le fait de porter Node.js sur la JVM est une bonne chose, car elle pourra aussi faire gagner tout avantage existant sur Java et n'existant pas sur Node.js et vis-versa, car aucun langage est exempte de faiblesse.

Et comme c'est ajouté aussi dit dans le site, que avec ça tu va pouvoir non seulement exécuter ton application en Node.js sur la JVM, mais tu va pouvoir exploiter la puissance de le technologie du clustering de Vert.x, car celle de Vert.x est très puissante que celle de Node.js il y a des benchmark qui prouvent cela.

Imagine running your Node.js app on the JVM with clean, clear access to Java directly in your Javascript. All that with vert.x's powerful clustering technology built right in.

Et je crois que parmi l'utilité de l'autre côté, c'est sur les grosse applications de transfert de fichier, ou téléchargement ne sont pas aussi géré avec la légèreté de Node.js.

Nashorn est justement le remplacement du très vieillissant Rhino. Je l'utilise régulièrement et pour sûr, il est lent, très lent, trop lent.
Dyn.JS est juste une alternative FLOSS à Nashorn.

Nashorn n'est qu'a ces débuts et déjà le code JavaScript exécuté dessus n'est pas compilé Nashorn l'interprete, contrairement au code écris et compilé avec Dyn.JS, qui tourne sur Java comme les autres langages tourant sur la JVM(Scala, Clojure, JRuby...).

Alors Dyn.JS fonctionne avec les Apis MethodHandles et InvokeDynamic, comme nom l'indique "Dyn":dynamic. Mais tout reste que Nashorn aussi exploite l'invocation dynamic de méthode de la JVM, donc elle a devant elle toute la pile de l'API Java

En gros c'est un moyen de rendre Vert.x compatible Node.js en utilisant DynJS et le module dynJS pour Vert.x.

Oui c'est un moyen mais il ne veut pas se limiter à Vert.x dans le moment où Nodyn fait partie de l’écosystème JBoss, qui dit JBoss dit Java EE.
Déjà c'est dit dans l'article:

Ainsi, des travaux sont en cours pour intégrer le projet au sein de l’écosystème JBoss

J'ai également lu un billet ici disant précisant que:

le projet Nodyn fait également partie de l'écosystème JBoss pour garantir la poursuite de l'intégration avec le reste du monde d'applications Java

[leminipouce]

Nashorn n'est qu'a ces débuts et déjà le code JavaScript exécuté dessus n'est pas compilé Nashorn l'interprete, contrairement au code écris et compilé avec Dyn.JS, qui tourne sur Java comme les autres langages tourant sur la JVM(Scala, Clojure, JRuby...).

My bad. Quand j'ai dit que je l'utilisais... je parlais de ce bon vieux Rhino, pas de Nashorn

[la.lune]

Ok j'ai bien compris. Je souligne tout juste même si je ne suis aussi calé en français mais dans ta phrase tu as bien dit :

Nashorn est justement le remplacement du très vieillissant Rhino. Je l'utilise régulièrement ...

Là en français le pronom "le" dans je "l'utilise" refaire au sujet décrit dans la première phrase, et nom pas le complément. Si tu voulais désigner Rhino il fallait dire:

Nashorn est justement le remplacement du très vieillissant Rhino. J'utilise ce dernier régulièrement ...

[Logan Mauzaize]

Etrange d'apporter une surcouche à Vert.x pour le rendre compatible Node.js (et quelques part forcés l'utilisation de JavaScript ...).

Justement ce que je trouvais intéressant dans Vert.x c'est le modèle asynchrone sur la plateforme Java. Certes programmer avec du pure Java (jusqu'à l'apparition des lambdas) ca doit être un calvaire. Mais rien n'empêchait d'utiliser un des langages alternatifs plus adapté (Scala, Groovy, autre).

Concernant la développement avec un serveur Web asynchrone, quelqu'un s'est-il déjà essayer à Apache Mina ?

[Traroth2]

Oui c'est un moyen mais il ne veut pas se limiter à Vert.x dans le moment où Nodyn fait partie de l’écosystème JBoss, qui dit JBoss dit Java EE.
Déjà c'est dit dans l'article:

Non mais en fait, c'est carrément ça. C'est une surchouche pour Vert.x. Le projet de Red Hat (initialement créé chez Pivotal). Développé dans le même département ("project:odd") que DynJS, Netty et Nodyn. JBoss est une marque de Red Hat, tu sais...