Nodyn : Node.js s'invite sur la machine virtuelle Java

Une explication ou c'est juste un a priori ?

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.

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 !

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.

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 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

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:
J'ai également lu un billet ici disant précisant que:

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 ...

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

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

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_(...ur_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.

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