Oracle présente de nouvelles fonctionnalités de Java 9

Java et C++ ne sont pas vraiment 2 langages comparables, l'un utilise un compilateur JIT via une VM et l'autre est compilé en langage machine.
Concurrencer C++ à quel niveau ?
Si Minecraft n'est pas "stable", cela ne veut pas dire que Java n'est pas stable.

Citation:

---

Envoyé par benedict010198

J'attends de voir si Java vas pouvoir un jour concurrencer des langage comme le C++

---

Sur quel critère? La portabilité? La gestion mémoire? La vitesse d'exécution? La vitesse de développement? La qualité des IDE? Le nombre de binaires l'utilisant? ....

Citation:

---

Envoyé par benedict010198

Et de voir si minecraft pourra devenir un peu plus stable.

---

Ben d'après ce que j'ai compris de certaines discutions, ça arrivera quand ils apprendront à programmer :mouarf:

Citation:

---

Envoyé par tchize_

Si les paramètres par défaut sont du sucre syntaxique uniquement, ça ne devrais pas poser de problème de compatibilité au niveau binaire:

---

Le problème c'est que cela ne fonctionne pas comme cela. Enfin dans C#, PHP ou d'autre langage qui les supportent.

Si Java reprenait le principe de C#, on aurait plutôt ceci :

Code:

---

public X maMethode(String val1, String val2 default "Hello", String val3 default "Prout"){....}

---

Qui serait compilé tel quel (les valeurs par défaut étant simplement des metadonnées, voir même des annotations) :

Code:

---

public X maMethode(String val1, @DefaultValue("Hello") String val2, @DefaultValue("Prout") String val3){....}

---

Et en fait ce serait les appels de méthodes qui serait modifiés via du sucre syntaxique.
Ainsi ceci :

Code:

---

1 2 3

x.maMethode("a"); x.maMethode("a", "b"); x.maMethode("a", val3:"c");

---

:arrow: Serait en réalité compilé en quelque chose comme cela :

Code:

---

1 2 3

x.maMethode("a", "Hello", "Prout"); x.maMethode("a", "b", "Prout"); x.maMethode("a", "Hello", "c");

---

Du coup si tu rajoutes un paramètre optionnel comme ceci :

Code:

---

1 2	// On veut rajouter un paramètre par défaut. Il semblerait évident de faire ceci : public X maMethode(String val1, String val2 default "Hello", String val3 default "Prout", String val4 default "Test"){....}

---

Les codes existant vont générer des MethodNotFoundException car maMethode(String,String,String) n'existe plus...

Pour pallier à cela il faut utiliser la surcharge en plus (ou éviter d'utiliser les paramètres par défaut dans les librairies) :

Code:

---

1 2 3 4 5 6 7

// On rajoute un paramètre par défaut : public X maMethode(String val1, String val2 default "Hello", String val3 default "Prout", String val4 default "Test"){....}   // Mais on doit conserver l'ancienne signature : public X maMethode(String val1, String val2, String val3) { return maMethode(val1, val2, val3, "Test"); }

---

Bref on retombe un peu dans les mêmes travers :(
Sans compter les problèmes liés à l'héritage...



Ta solution serait adapté pour avoir seulement des paramètres optionnels... mais cela n'apporte rien de plus que ce qu'on a maintenant (si ce n'est qu'on ne voit pas les surcharges).
Comme tu le dis si tu veux spécifier uniquement le dernier paramètre il faut définir tous ceux qui le précède...
Et cela ne règle pas les problèmes liés à l'héritage...


Surtout que pour moi le principal intérêt de cela c'est d'éviter les builders ou les surcharges multiples pour des méthodes qui pourraient contenir plusieurs paramètres optionnels.
Il suffit de voir ResourceBundle.getBundle() qui possèdent seulement 4 paramètres (1 obligatoire + 3 optionnel) et qui propose 6 surcharges (et encore sans proposer toutes les alternatives possibles).


a++

Dans votre discussion, il y a un truc qui m'échappe, je ne vois pas du tout l'intérêt de cette syntaxe "default" sur un paramètre d'appel de méthode.
Pour moi, c'est la méthode qui doit avoir un défaut pour un paramètre non spécifié, ce que vous montrez est du registre de

Code:

---

1 2	maMethode(parametre1, parametre2 == null ? defaultParametre2Value : parametre2, parametre3 == null ? defaultParametre3Value : parametre3);

---

Quel intérêt de changer cette syntaxe ?

Qu'on puisse changer une valeur par défaut dans une méthode me paraît intéressant, soit par une annotation ce qui oblige a recompiler, soit par un fichier externe (xml par exemple) comme ce qu'on fait déjà avec JPA est un plus.
Bref, il faudrait peut-être faire autre chose que des sucres syntaxiques...
Dans le registre des appels de méthodes, on pourrait faire un appel avec paramètres nommés du genre

Code:

---

1 2	maMethode("parametre2"=laValeurDeParametre2);

---

ce qui permettrait de ne pas avoir à préciser tous les paramètres qu'il y a avant et/ou après... mais bon, il n'y aurait plus de surcharge de méthode possible et il faudrait déterminer les variantes dans la méthode en fonction des paramètres transmis, je ne crois pas que ce soit un gain :aie:

Ce qui me manque (un peu) en java, c'est plutôt d'être limité à la taille de la mémoire de la jvm, de ne pas pouvoir forcer une libération de mémoire (même si ça peut être casse-gueule)

@OButterlin : c'est un peu ce que je veux dire... même si j'ai un peu de mal à l'expliquer.

Les paramètres nommés/optionnels sont généralement implémenté par un simple sucre syntaxique.
Si cela devait arriver un jour dans Java il faudrait un truc un peu plus fiable.


Et le gros problème pour cela c'est la surcharge des méthodes...


a++

Citation:

---

Envoyé par adiGuba

Il serait donc possible de voir des navigateurs inclurent un Java "minimum", le tout couplé à un module "browser" permettant une communication simple avec le browser, et des modules optionnelles représentant les fonctionnalités "html5"...
Et on pourrait se retrouver à codé des applications Java qui tourneraient directement dans le navigateur.

---

Citation:

---

Envoyé par OButterlin

Personnellement, je trouve l'idée excellente... on aurait presque l'équivalent de l'applet que tout le monde a tué alors que le potentiel était énorme ;)

---

Le principal souci des applets Java, en plus de mettre trois plombes à se charger, c'est que d'abord c'est ultra moche au sein d'une page Web. Quand au potentiel énorme, avec l'amélioration de JavaScript tant côté serveur que côté client, j'ai du mal à voir l'énormité du potentiel des applets.

Citation:

---

Envoyé par yahiko

Le principal souci des applets Java, en plus de mettre trois plombes à se charger, c'est que d'abord c'est ultra moche au sein d'une page Web. Quand au potentiel énorme, avec l'amélioration de JavaScript tant côté serveur que côté client, j'ai du mal à voir l'énormité du potentiel des applets.

---

Et bien, essaye de faire une application RIA qui fonctionne de la même manière sur tous les navigateurs...

Pour ce qui est des temps de chargement, ça va surtout dépendre du volume à télécharger, la première fois... ensuite, il n'y aurait plus que les données qui transitent et là, on serait à peu près au même niveau qu'une application massivement ajax mais sans les inconvénients.
Et essaye de faire un appel d'EJB à partir de javascript... pas possible directement...

Pour ce qui est du look, c'est très discutable... on peut faire des choses super sexy en Swing, et beaucoup plus facilement qu'en html / javascript...
D'ailleurs, si on se réfère à la tendance du moment, on est parti pour faire des applications "single page" à coup d'AngularJS, Ember et autres framework javascript... un client swing le fera bien plus simplement...

Et que dire du langage lui même... même si javascript est "marrant", je préfère un langage fortement typé comme java.

Bref, le potentiel était là... libre à chacun de le voir... ou non...

Je ne crois pas que l'Applet reviendra sur le marché de sitôt, son nom a trop été souillé.
Et puis j'ai remarqué qu'il y a toujours un problème lorsqu'il est question de faire tourner une application qui nécessite une VM via le navigateur (Applet, Silverlight, Flash ...).
J'aurais pour ma part apprécié d'avoir comme remplaçant de JS un Java très light (pour son paradigme très Objet et son typage explicite forcé).

Il existe des transpileurs qui permettent d'écrire dans un langage de départ en paradigme Objet ou autre d'ailleurs, puis d'avoir un code en sortie en JavaScript, interprétable par tous les navigateurs.

Il y a Scala, Dart ou TypeScript par exemple. On a ainsi les avantages d'un langage typé et/ou orienté objet tout en ayant la portabilité de JS sur les navigateurs.

Pas besoin d'un Java light donc. CQFD ;)

Pour Dart (dynamic) ou TypeScript le typage est optionnel, j'ai bien précisé "explicite forcé". Scala est trop exotique pour moi.
Et puis quand j'ai dit paradigme Objet, cela exclu d'office "procédural", donc le fait d'avoir des fonctions globales.

Citation:

---

Envoyé par OButterlin

Et bien, essaye de faire une application RIA qui fonctionne de la même manière sur tous les navigateurs...
(...)
Bref, le potentiel était là... libre à chacun de le voir... ou non...

---

Du côté des applets, c'est clair il y avait du potentiel tout comme silverlight en avait aussi. Je n'ai moi-même jamais eu l'impression que javascript se soit imposé comme langage principal du web de par ses qualités, bien au contraire, on nous a dit "voilà c'est ça ou rien". Je pense également que l'avenir semble plutôt du côté de typescript, dart et autres technos qui rendent javascript plus buvable, je crois pas que ce qui est à base de plugins ait encore une chance. Du côté de java, après l'abandon de fait de Swing et le pétard mouillé javaFX, on a presque plus de chances de voir les technos web conquérir le desktop que l'inverse.

Citation:

---

Envoyé par yahiko

Il existe des transpileurs qui permettent d'écrire dans un langage de départ en paradigme Objet ou autre d'ailleurs, puis d'avoir un code en sortie en JavaScript, interprétable par tous les navigateurs.

---

Pas du tout d'accord avec toi, et pour cause, on a fait l'acquisition d'un logiciel basé sur un framework javascript et il ne fonctionne QUE avec IE9/10/11 ou Chrome.

Si ta conception d'un logiciel est compatible avec l'imposition du navigateur, c'est ton droit ;)

Citation:

---

Envoyé par _skip

Du côté de java, après l'abandon de fait de Swing et le pétard mouillé javaFX, on a presque plus de chances de voir les technos web conquérir le desktop que l'inverse.

---

C'est clair :mouarf:

Citation:

---

Envoyé par Gugelhupf

Pour Dart (dynamic) ou TypeScript le typage est optionnel, j'ai bien précisé "explicite forcé". Scala est trop exotique pour moi.
Et puis quand j'ai dit paradigme Objet, cela exclu d'office "procédural", donc le fait d'avoir des fonctions globales.

---

Oui, en fait tu veux que la verbosité et la rigidité contre-productive de Java soit transposée côté navigateur... :ptdr:

J'ajoute que pour faire un truc 3D un peu sympa, les applets sont plutot pas mal. J'ai essayé de voir coté browser mais WebGL à pas l'air de marcher tres bien en multi plateforme.

D'ailleurs, si quelqu'un connait un outil qui permet de faire de la 3D via le browser et qui marche pas trop mal, ca m'interesse :D

Citation:

---

Envoyé par hwoarang

J'ajoute que pour faire un truc 3D un peu sympa, les applets sont plutot pas mal. J'ai essayé de voir coté browser mais WebGL à pas l'air de marcher tres bien en multi plateforme.

---

Wot? Jette un oeil sur BabylonJS, c'est développé part un Frenchie de chez Microsoft (mais en Open source pour ceux qui sont encore à l'époque microsoft == Satan)

Citation:

---

Envoyé par yahiko

Le principal souci des applets Java, en plus de mettre trois plombes à se charger, c'est que d'abord c'est ultra moche au sein d'une page Web.

---

Je ne parlais pas d’insérer des applets, mais de pourvoir utiliser du Java à la place du JavaScript.

Le problème de lancement des applets disparait si la JVM est inséré dans le navigateur (comme la machine virtuelle JavaScript).
Quand aux différentes couches UI il n'en serait même pas question puisque je parle d'un Java "minimum".
Grosso-modo on aurait accès uniquement aux packages de base (java.lang, java.util), et à un package "java.browser" permettant de communiquer avec le navigateur.

Toute la partie UI passerait pas une manipulation du DOM comme on le fait actuellement en JavaScript.
Grosso-modo au lieu de faire :

Code:

---

<script type="text/javascript" src="/script.js"></script>

---

Code:

---

1 2 3 4 5

document.getElementByID("title").innerText = "Titre de mon application"; document.getElementByID("button").addEventListener("click", function(e) { window.alert("click on button"); }

---

On pourrait faire la même application en Java :

Code:

---

<script type="application/java" src="/archive.jar"></script>

---

Code:

---

1 2 3 4 5 6

Document document = Browser.getDocument(); document.getElementByID("title").setInnerText("Titre de mon application"); document.getElementByID("button").addEventListener("click", (e) -> { Window.alert("click on button"); }

---

Citation:

---

Envoyé par yahiko

Quand au potentiel énorme, avec l'amélioration de JavaScript tant côté serveur que côté client, j'ai du mal à voir l'énormité du potentiel des applets.

---

Avoir du code typesafe et un vrai langage bien pensé.

Citation:

---

Envoyé par yahiko

Oui, en fait tu veux que la verbosité et la rigidité contre-productive de Java soit transposée côté navigateur... :ptdr:

---

JavaScript c'est bien pour foutre une ou deux animations sur une page...
Mais quand tu développes une application un tant soit peu consistant c'est agréable d'avoir un langage qui ne vas pas te pêter à la gueule pour un oui ou pour un non.
Je revis depuis que je fais du GWT et que mon JavaScript se limite à une ligne par-ci par-là...



a++

Citation:

---

Envoyé par adiGuba

JavaScript c'est bien pour foutre une ou deux animations sur une page...
Mais quand tu développes une application un tant soit peu consistant c'est agréable d'avoir un langage qui ne vas pas te pêter à la gueule pour un oui ou pour un non.

---

ça sent le vécu :ptdr:

C'est clair que c'est over rassurant de développer en se disant que le type d'une variable risque de changer d'une ligne à l'autre :mouarf:

Citation:

---

Envoyé par OButterlin

Pas du tout d'accord avec toi, et pour cause, on a fait l'acquisition d'un logiciel basé sur un framework javascript et il ne fonctionne QUE avec IE9/10/11 ou Chrome.

Si ta conception d'un logiciel est compatible avec l'imposition du navigateur, c'est ton droit ;)

---

Ton raisonnement : Il y a un framework écrit en JS qui n'est pas compatible avec certains navigateurs. Donc c'est la faute au langage JavaScript... :weird:
Si tu crois à ce que tu racontes, je ne peux rien pour toi.
D'autant plus que si tu codes un programme avec une applet Java, il y a de fortes chances pour qu'elle soit bloquée par beaucoup de navigateurs.

Citation:

---

Envoyé par adiGuba

Je ne parlais pas d’insérer des applets, mais de pourvoir utiliser du Java à la place du JavaScript.

Le problème de lancement des applets disparait si la JVM est inséré dans le navigateur (comme la machine virtuelle JavaScript).

---

Ce n'est pas du tout la tendance actuelle où les navigateurs ont plutôt tendance à délaisser le support de Java...

Citation:

---

JavaScript c'est bien pour foutre une ou deux animations sur une page...
Mais quand tu développes une application un tant soit peu consistant c'est agréable d'avoir un langage qui ne vas pas te pêter à la gueule pour un oui ou pour un non.
Je revis depuis que je fais du GWT et que mon JavaScript se limite à une ligne par-ci par-là...

---

Content que tu aies trouvé ton bonheur avec GWT. Même si je suis surpris que Google n'ai pas encore officialisé sa mort (ce ne serait pas le premier produit à subir un tel sort).

Comme je l'ai dis plus haut, tu peux passer par des langages intermédiaires typés et objet qui transpilent en JS si ce langage te donne la nausée.
Je me suis d'ailleurs réconcilier avec JS grâce à TypeScript.

Citation:

---

Envoyé par yahiko

Ton raisonnement : Il y a un framework écrit en JS qui n'est pas compatible avec certains navigateurs. Donc c'est la faute au langage JavaScript... :weird:
Si tu crois à ce que tu racontes, je ne peux rien pour toi.
D'autant plus que si tu codes un programme avec une applet Java, il y a de fortes chances pour qu'elle soit bloquée par beaucoup de navigateurs.

---

Tu es un comique toi... c'est vrai que s'il y a des différences d'interprétations d'un navigateur à l'autre dans ce type d'applications, c'est certainement la faute à java :roll: