Discussion :

[sekaijin]

J'ai très bien compris de quoi il s'agissait.

Mais en version 8 on introduit un premier shell interactif officiel en version 9 on en mets un second et 10 on en mettra trois de plus parce que la syntaxe des deux premier n'est pas ceci où cela.

je trouve que ça manque de cohérence.
je trouve qu'on devrais réfléchir d'avantage à la sérénité et la portabilité.

Depuis bien longtemps maintenant se pose le problème de la surenchère dans la JVM. à force d'ajouter elle a pris beaucoup de poid et bien souvent de façon inutile.

Aujourd'hui avec la version 8 on a un shell qui de fait et embarqué dans la JVM avec la version 9 on en a deux. sachant que dans 99% des cas ils ne servent pas. et c'est vrais pour beaucoup de techno dans la JVM.
Un des point qui n'arrête pas d'être repoussé et la modularité de la JVM et la définition de profil.

Si on doublonne de cette façon les différents composants de la JVM comment on va définir les profils, et si je dois installer un dev qui utilise le shell de la version 8 sur une plateforme qui à été défini avec un profil qui lui a le shell de la version 9 comment allons nous géré cette prolifération ?

Je crains qu'à agir de la sorte nous allons avoir au final un profil contenant tout et un JVM toujours de plus en plus grosse

A+JYT

[adiGuba]

Mais en version 8 on introduit un premier shell interactif officiel en version 9 on en mets un second et 10 on en mettra trois de plus parce que la syntaxe des deux premier n'est pas ceci où cela.

Il s'agit surtout de deux langages différents...

Depuis bien longtemps maintenant se pose le problème de la surenchère dans la JVM. à force d'ajouter elle a pris beaucoup de poid et bien souvent de façon inutile.

Aujourd'hui avec la version 8 on a un shell qui de fait et embarqué dans la JVM avec la version 9 on en a deux. sachant que dans 99% des cas ils ne servent pas. et c'est vrais pour beaucoup de techno dans la JVM.

Techniquement cela ne fait pas partie de la JVM.
C'est juste un des (multiples) outils disponible avec le JDK...

Un des point qui n'arrête pas d'être repoussé et la modularité de la JVM et la définition de profil.

C'est un énorme travail qui a déjà débuté avec Java 8 (qui instaure 3 profile "compact"), et dont l'aboutissement est justement prévu pour Java 9...

Si on doublonne de cette façon les différents composants de la JVM comment on va définir les profils, et si je dois installer un dev qui utilise le shell de la version 8 sur une plateforme qui à été défini avec un profil qui lui a le shell de la version 9 comment allons nous géré cette prolifération ?

Encore une fois c'est un outil et non pas une API. Cela n'a rien à voir avec les profiles ou la JVM...


a++

[Traroth2]

J'ai très bien compris de quoi il s'agissait.

Mais en version 8 on introduit un premier shell interactif officiel en version 9 on en mets un second et 10 on en mettra trois de plus parce que la syntaxe des deux premier n'est pas ceci où cela.

je trouve que ça manque de cohérence.
je trouve qu'on devrais réfléchir d'avantage à la sérénité et la portabilité.

Depuis bien longtemps maintenant se pose le problème de la surenchère dans la JVM. à force d'ajouter elle a pris beaucoup de poid et bien souvent de façon inutile.

Aujourd'hui avec la version 8 on a un shell qui de fait et embarqué dans la JVM avec la version 9 on en a deux. sachant que dans 99% des cas ils ne servent pas. et c'est vrais pour beaucoup de techno dans la JVM.
Un des point qui n'arrête pas d'être repoussé et la modularité de la JVM et la définition de profil.

Si on doublonne de cette façon les différents composants de la JVM comment on va définir les profils, et si je dois installer un dev qui utilise le shell de la version 8 sur une plateforme qui à été défini avec un profil qui lui a le shell de la version 9 comment allons nous géré cette prolifération ?

Je crains qu'à agir de la sorte nous allons avoir au final un profil contenant tout et un JVM toujours de plus en plus grosse

A+JYT

Je n'arrive pas à comprendre la relation que tu fais entre l'ajout d'un moteur Javascript à la JVM (dans la version 6 et non dans la version 8) et le REPL, qui n'est en rien un nouveau langage. De même, Nashorn n'est pas non plus un shell, mais un moteur Javascript accessible depuis le code Java. Il n'y a aucun "doublon" là-dedans. Ça n'est pas la même chose, ça ne sert pas à la même chose et ça ne fonctionne pas de la même manière.

[adiGuba]

Je n'arrive pas à comprendre la relation que tu fais entre l'ajout d'un moteur Javascript à la JVM (dans la version 6 et non dans la version 8) et le REPL, qui n'est en rien un nouveau langage. De même, Nashorn n'est pas non plus un shell, mais un moteur Javascript accessible depuis le code Java. Il n'y a aucun "doublon" là-dedans. Ça n'est pas la même chose, ça ne sert pas à la même chose et ça ne fonctionne pas de la même manière.

C'est juste qu'avec Java 8 et Nashorn, on a aussi un REPL JavaScript via la commande "jjs"...


a++

[Traroth2]

C'est juste qu'avec Java 8 et Nashorn, on a aussi un REPL JavaScript via la commande "jjs"...


a++

Pas testé. J'ignorais ça. Mais ça n'enlève pas l'intérêt d'un REPL Java.

[sekaijin]

she de la V8

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
jjs> var HashMap = Java.type("java.util.HashMap");
jjs> var mapDef = new HashMap();
jjs> var map100 = new HashMap(100);

shell de la V9

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
jrepl> inport java.util.HashMap;
jrepl> HashMap mapDef = new HashMap();
jrepl> HashMap map100 = new HashMap(100);

Sorry mais je ne vois pas beaucoup de différence

A+JYT

[adiGuba]

Sorry mais je ne vois pas beaucoup de différence

Même si la syntaxe peut être assez proche et que leurs noms sont proche, il y a un monde d'écart entre JavaScript et Java...


a++

[sekaijin]

je maistrise suffisement JS pour le savoir
mais là dans JJS il s'agit de manipuler des objet Java de la JVM
il s'agit d'instance de classe java.

A+JYT

[adiGuba]

je maistrise suffisement JS pour le savoir
mais là dans JJS il s'agit de manipuler des objet Java de la JVM
il s'agit d'instance de classe java.

Oui il s'agit d'instance de classe Java manipulé en JavaScript.
C'est une des fonctionnalité du moteur Nashorn...

Et ?
Ca ne change rien au fait que le language soit du JavaScript... pas du Java.


Et je ne vois toujours pas le problème à proposer deux "REPL" pour deux langages distinct.


a++