Tiens, mais c'est beanshell ...
J'espère qu'il n'y a pas que ça dans java9. Sinon c'est un peu décevant. Certes c'est un outils supplémentaire qui aura surement son utilité maintenant en apprenant ça j'ai pas sauté de ma chaise en poussant des hurlements de joie
Python possède cette fonctionnalité est ce une raison pour la mettre dans Java. Si on va par là il y a aussi des GOTO en BASIC pourquoi ne pas implanter ça dans Java 10![]()
Sa me gêne un peu quand même, car Java n'as jamais été conçue pour pouvoir s'utiliser avec un interpréteur.
Surtout que c'est pour des fin éducative, on apprend quelque chose de "faux" aux étudiants. Ou en tous cas c'est pas une bonne utilisation de Java.
C'est loin d'être la seule nouveauté de Java 9 : http://openjdk.java.net/projects/jdk9/
Le plus gros changement viendra sûrement de la modularité (jigsaw)...
Sinon concernant le REPL, c'est juste un outil d'apprentissage qui vient s'ajouter aux multiples outils du JDK.
Je ne vois pas vraiment le problème en fait...
a++
Ben non ... Java a été conçu pour fonctionner dans des mobiles (mais il fallait voir les prototypes de l'époque : rien à voir avec Android) et pour faire des applets dans des navigateurs.le 14/08/2015 à 12:52
Sa me gêne un peu quand même, car Java n'as jamais été conçue pour pouvoir s'utiliser avec un interpréteur.
Surtout que c'est pour des fin éducative, on apprend quelque chose de "faux" aux étudiants. Ou en tous cas c'est pas une bonne utilisation de Java.
Si on utilise une chose inventée uniquement pour son objet initial, on passe quasiment à côté des utilisations les plus intéressantes (cf. https://fr.wikipedia.org/wiki/S%C3%A9rendipit%C3%A9).
Ta pas compris le sens de ma remarque, le but est d'enseigner a des débutants qui n'ont jamais fait de prog, autant enseigner les pratiques courante de java, pas quelques chose de nouveau que personne n'utilise en entreprise.Ben non ... Java a été conçu pour fonctionner dans des mobiles (mais il fallait voir les prototypes de l'époque : rien à voir avec Android) et pour faire des applets dans des navigateurs.
Python a la base a un interpréteur, donc oui je peut comprendre que les jeunes pouce apprennes python avec l'interpréteur.
L'Edi de squeak serait plus intéressant pour mettre au point une classe ou un algorithme et vérifier immédiatement. (smalltalk ou squeak est un langage objet ou tout est objet plus ou moins hiérarchisés). Un langage facile à apprendre (très peu de règles syntaxiques) où l'Edi est lui même écrit en squeak
J'avoue que j'ai un peu de mal à suivre
Avec Java8 on a ajouté le support de JavaScript et cela aurait pu se faire comme pour tout autre langage embarqué dans la JVM, mais on lui a ajouté un élément: JJS, un Shell.
Chose louable, ou pas. Je ne me prononcerais pas.
Mais, avoir un Shell officiel pour interagir avec la JVM apportait une chose que les solutions par ailleurs plutôt bonnes des diverses communautés: le coté officiel justement.
Enfin on avait un Shell standard et on allait être sur d'une convergence. (à condition bien sûr que la sauce prenne)
Et voilà que Java9 nous pond un 2e Shell.
Comme souvent dans les évolutions de Java je me demande où est la cohérence.
A+JYT
En fait, il y a un moteur Javascript embarqué dans la JVM depuis Java 6, Rhino. Java 8 en introduit simplement un plus rapide, Nashorn.
L'interface REPL n'est pas un nouveau langage, mais une manière d'entrer des instructions Java de manière interactive, possibilité qui existe déjà pour de nombreux langages (Python, Ruby, Erlang, Clojure) et dont l'objectif est surtout (mais pas que) didactique.
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
Il s'agit surtout de deux langages différents...
Techniquement cela ne fait pas partie de la JVM.
C'est juste un des (multiples) outils disponible avec le JDK...
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...
Encore une fois c'est un outil et non pas une API. Cela n'a rien à voir avec les profiles ou la JVM...
a++
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.
Au passage, Eclipse fournit depuis très longtemps déjà une fonctionnalité similaire via les scrapbook pages.
http://help.eclipse.org/mars/index.j...pbook_page.htm
Partager