Java pourrait être doté d’un interpréteur boucle : lecture - évaluation – impression

Ouais non, j'ai vérifié, il ne lit pas que des expressions, il lit :
- des expressions, avec affichage du résultat
- des instructions, et il les exécute. Notamment des déclarations de variable
- des déclarations de classe et méthodes
- des commandes internes de son shell

Après déclaration d'une variable/classe/méthode, on peut la redéclarer.
On peut déclarer des classes et méthodes qui font appel à des classes, méthodes ou variables qui n'existent pas ou qui ne sont pas du bon type. Auquel cas on obtient une liste, chaque fois qu'on est dans cette situation, de ce qu'on doit faire pour réparer la situation (déclarer telle variable, changer son type...)

Bref, le shell REPL lui-même n'est pas du Java à proprement parler mais il fait son boulot de permettre de jouer avec la syntaxe Java.

Si le programme s'écrivait en une seule ligne de commande le projet n'aurait aucun intérêt, ça doit surement être instruction par instruction, comme en python.

Je pense qu'un tel outil est très utile pour convaincre les adeptes de Java de changer de langage de programmation pour un plus souple, à l'image de ce REPL.

Citation:

---

La prise en charge de REPL est l’une des fonctionnalités les plus attendues de Java 9

---

Plus que le projet Jigsaw, l'api Json, et autres ?

Personnellement, sans vouloir critiquer négativement cet ajout qui reste bon à prendre, je ne vois pas trop ce que ça va apporter en plus à part à ne pas à avoir à lancer un IDE pour pouvoir tester en live 3 ligne de codes.

Tant d'énergie dépensée pour séduire des débutants qui n'en seront pas moins performant en java en ayant commencé (et continué) sur un langage permettant une plus grande facilité de compréhension de la programmation.

Ça me donne l'image d'un vendeur de produit qui va faire les sorties d'écoles afin de rendre le plus tôt possible accro à sa marque...

Pendant ce temps Microsoft sort son IDE phare en gratuit avec un émulateur Android et des fonctionnalités web qui semble (sur le papier) géniales,
Google prévois un langage spécifique à Android et le support de Dart pour cette dernière plateforme histoire de ne plus être dépendant d'Oracle (sans compter les X langages et frameworks avant-gardistes),
Php améliore ses performances,
Javascript permet de faire des applications robustes aussi bien en client qu'en serveur....

Bref si oracle veut prendre la place des langages débutants, autant qu'ils le fasse en améliorant le langage, ses fonctionnalités, son accèssiblité, sa pérennité (cf: google et android) ... pas en lachant un shell qui sera utilisé pendant 4 heures par les débutant avant de lancer un éclipse, netbeans, intellij, etc...

Bonjour.

Je n'ai jamais utilisé Java de ma vie, mais j'utilise au quotidien Python.
Alors, je ne sais pas si c'est lié à ça, mais je suppose que oui. Corrigez moi si je me trompe. Et si ce que j'explique plus bas existe aussi en Java, alors mes excuses pour les explications inutile.

Edit: en fait, ça a l'air de déjà exister.

En Python, il y a effectivement l’interpréteur qui permet d'exécuter des instructions rentrés au fur et à mesure. Mais pour moi, c'est pas le plus primordial (quoi que très utile pour tester des nouvelles bibliothèques par exemple).
Il y a aussi un debugger interactif. Par exemple :

Code:

---

1 2 3 4 5 6 7

def my_function(arg1, arg2): result = arg1 + arg2 import pdb; pdb.set_trace() # On utilise le debugger return result * result   my_function(2, 5)

---

Quand j'exécute le code :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

> <ipython-input-2-cb762d1cb91c>(4)my_function() -> return result * result (Pdb) arg1 2 (Pdb) arg2 5 (Pdb) args arg1 = 2 arg2 = 5 (Pdb) result 7 (Pdb) result * result 49 (Pdb) result = 22 (Pdb) result * result 484 (Pdb) c Out[2]: 484

---

Ce qui est intéressant, c'est que ce qu'il y a préfixé par (Pdb), c'est moi qui ai inséré les instructions en temps réel.
Le programme executé s'est mis en pause quand il a vu "pdb.set_trace()" et il m'a donné la main, me laissant accès à l'environnement en mémoire.
Il y a des tas d'autres trucs possible (voir les lignes au-dessus et en dessous du code dans lequel on est, mettre un point de rupture ailleurs à la volée, etc.).
Être au cœur du programme et de le "modifier" en temps réel permet facilement de debugger un truc. C'est vraiment une feature qui me manque, par exemple, en javascript du coté front-end.
En javascript, le debugger du navigateur permet d'insérer des instructions déterminés à l'avance ou de voir telle ou telle variable, mais pas d'exécuter du code avec saisie en temps réel.


Quelqu'un parlait plus haut de permettre d'écrire dans un fichier ce que l'on tape en temps réel. En python, c'est possible avec, par exemple, ipython (qui proposent des tas et des tas features).

En conclusion, avoir ça dans Java, ça ne peut être que bénéfique pour vous, à mon avis (évidemment, faut pas laisser traîner un point de rupture du debugger sur un truc en production...).

Bah moi dans mon Université on commencer par Pascal puis C ensuite C++ et enfin Java

Citation:

---

Envoyé par L4goon

Plus que le projet Jigsaw, l'api Json, et autres ?

Personnellement, sans vouloir critiquer négativement cet ajout qui reste bon à prendre, je ne vois pas trop ce que ça va apporter en plus à part à ne pas à avoir à lancer un IDE pour pouvoir tester en live 3 ligne de codes.

Tant d'énergie dépensée pour séduire des débutants qui n'en seront pas moins performant en java en ayant commencé (et continué) sur un langage permettant une plus grande facilité de compréhension de la programmation.

Ça me donne l'image d'un vendeur de produit qui va faire les sorties d'écoles afin de rendre le plus tôt possible accro à sa marque...

Pendant ce temps Microsoft sort son IDE phare en gratuit avec un émulateur Android et des fonctionnalités web qui semble (sur le papier) géniales,
Google prévois un langage spécifique à Android et le support de Dart pour cette dernière plateforme histoire de ne plus être dépendant d'Oracle (sans compter les X langages et frameworks avant-gardistes),
Php améliore ses performances,
Javascript permet de faire des applications robustes aussi bien en client qu'en serveur....

Bref si oracle veut prendre la place des langages débutants, autant qu'ils le fasse en améliorant le langage, ses fonctionnalités, son accèssiblité, sa pérennité (cf: google et android) ... pas en lachant un shell qui sera utilisé pendant 4 heures par les débutant avant de lancer un éclipse, netbeans, intellij, etc...

---

Je ne comprends pas le sens de ta remarque, alors que tu commences justement par rappeler que c'est loin d'être la seule nouveauté prévue de Java 9.

bonne nouvelle!!! c'est vrai java reste un langage incontournable!!:mouarf:

Citation:

---

Pour les cours de programmation j'ai commencé direct en C mais si je m'en suis si bien sortie c'est parce-que j'ai commencé à faire du PHP(en autodidacte) 2 ans avant,
et de l'assembleur l'année précédente en terminale Electronique.
C'est pour ça que dans ma classe de BTS IRIS on était 4 les 3 premiers mois bien en avance sur les autres

---

Tiens c'est drôle, moi c'est tout l'inverse (pour un parcours presque similaire).
BTS IRIS également, après un Bac STI Electro..technique.
Je suis content d'avoir appris le C en premier, car cela te forme bien à la rigueur.

Personnellement je pense qu'apprendre un langage "difficile" comme le C/C++ ou le Java en premier est plus avantageux. Cela t'apprend la rigueur nécessaire au métier.
Alors que quand tu apprends direct le PHP, tu crois que tu peux faire n'importe quoi, et le passage à un autre langage est beaucoup plus difficile.

Apprendre le C ou le Java en premier t'apprend la rigueur. Ainsi quand tu passes à PHP (dans le sens professionnel du terme, pas en mode dimanche après-midi), et que tu découvres sa permissivité, tu sais de suite ce que tu peux faire et ce que tu ne dois pas faire.

Le gros point faible du PHP réside vraiment (toujours selon moi) dans son principal avantage: son ouverture pour réaliser des choses basiques. C'est comme cela que tu te retrouves avec des pseudo-dev PHP et des applications ultra bancales, et entendre des âneries du style "On s'en fout PHP c'est pas typé" ou avec des envies de meurtre pour ceux qui te disent "C'est quoi les PSR? Y'a pas de normes en PHP". :aie:
Ce qui au passage, donne énormément de grain à moudre aux anti-PHP, et autres trolls.

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

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.

Citation:

---

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.

---

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.

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

Citation:

---

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.

---

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.

Python a la base a un interpréteur, donc oui je peut comprendre que les jeunes pouce apprennes python avec l'interpréteur.

Citation:

---

Envoyé par Gouyon

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

---

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

Citation:

---

Envoyé par adiGuba

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

---

Je m'en doutais bien un peu

Citation:

---

Envoyé par adiGuba

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

---

Moi non plus.

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

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

Citation:

---

Envoyé par sekaijin

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

Citation:

---

Envoyé par sekaijin

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

Citation:

---

Envoyé par sekaijin

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

Citation:

---

Envoyé par sekaijin

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

Citation:

---

Envoyé par sekaijin

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

Citation:

---

Envoyé par 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

---

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.

Citation:

---

Envoyé par Traroth2

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

Citation:

---

Envoyé par adiGuba

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.

she de la V8

Code:

---

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:

---

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

Citation:

---

Envoyé par sekaijin

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

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

Citation:

---

Envoyé par 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.

---

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