IdentifiantMot de passe
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Java 9 sortira en version stable le 22 septembre 2016

Le , par Hinault Romaric
65 commentaires

55PARTAGES

1  0 
Oracle présente de nouvelles fonctionnalités de Java 9
et fixe les bases pour implémenter la modularité

Oracle a dévoilé de nouvelles fonctionnalités qui seront intégrées à Java 9, la prochaine version majeure de la plateforme de développement, qui sera disponible en 2016.

Java 9 introduira via la JEP 158 (Unified JVM Logging), un système d’enregistrement commun pour tous les composants de la JVM. Cela permettra une refonte complète de la façon dont Java signale les événements dans les sous-systèmes.

Plus de contrôle au niveau de la compilation sera offert par cette version (JEP 165 - More compiler controls). Cette amélioration permettra aux développeurs de changer les options de compilation du compilateur JIT Hotspot afin de pouvoir effectuer des optimisations spécifiques.

Avec la JEP 214 (Remove GC Combinations Deprecated in JDK 8), trois fonctionnalités du garbage collection (ramasse-miettes) seront supprimées. Il s’agit de DefNew + CMS, ParNew + SerialOld et Incremental CMS. Ces fonctionnalités étaient déjà obsolètes dans Java 8.

Quelques petits changements seront apportés au projet Coin (JEP 213), qui avait été introduit dans Java 7. Pour rappel, le projet Coin apporte quelques changements linguistiques à Java.

En plus de ces fonctionnalités, Oracle a l’intention de finaliser avec le projet « Resolve Lint and Doclint Warnings » pour le nettoyage des avertissements, qui avait débuté il y a plusieurs années. Java 9 offrira également un support de Datagram Transport Layer Security, et des sorties HTML5 pour Javadoc. De nombreuses corrections seront également apportées pour améliorer la gestion des importations, et les classes dépréciées ne vont plus générer des alertes.

À ces spécifications, s’ajoutent d’autres JEP qui ont été présentées en aout dernier, qui permettent de doter le langage de programmation d’une nouvelle « API lightweight JSON » pour la production et la consommation de documents JSON, de « HTTP2 Client » pour le support du HTTP 2.0 et des web sockets et de « Process API Updates » qui permet d’améliorer le contrôle, la gestion et l’interaction avec les processus non Java.

Bien que le projet Jigsaw ne soit pas encore intégré au projet, Oracle a réaffirmé son engagement d’offrir la modularité dans Java 9. Les ingénieurs d’Oracle ont fixé les bases pour une mise en œuvre structurée du projet Jigsaw à travers la JEP 152, JEP 201 et JEP 220. Jigsaw représente une nouveauté très attendue. Mais, son développement fait face à plusieurs défis qui doivent être relevés avant son intégration.

Jigsaw apportera des gros changements au JDK. Il permettra de découper la bibliothèque d’exécution de base de Java en différents modules. Ainsi, une machine virtuelle Java (JVM) pourra fonctionner sans le support de certains packages de base.

Mark Reinhold, architecte en chef du groupe de la plateforme Java chez Oracle, a fait savoir qu’avec Jigsaw, le format JAR n’avait plus sa place dans le système d’exécution de Java. « Le format JAR a fait son temps, c'est le moment de passer à autre chose », avait affirmé celui-ci.

Une annonce qui n’a pas manqué de créer une certaine frayeur chez les développeurs. Mais, Oracle rassure. Bien que le système d’exécution de Java reposera sur les modules et non les fichiers jar, la plateforme continuera à prendre en charge et à exécuter les applications empaquetées dans les fichiers Jar. Avec le temps, les développeurs devront, cependant, migrer vers les nouveaux formats modulaires.

Le passage à un système de module aura également un impact important sur les outils de développement et les Framework.

À titre de rappel, les JEP sont les nouveaux processus permettant le développement et le test de fonctionnalités relatives au langage Java ou à sa machine virtuelle, sans recourir au processus complet de spécification (JSR). Par la suite, toute JEP qui a été implémentée avec succès sera intégrée à Java sous la forme de mise à jour ou de nouvelle version.

Source : Oracle

Et vous ?

Quelle fonctionnalité attendez-vous le plus dans Java 9 ?
Vous avez lu gratuitement 6 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

65 commentaires
Commenter Signaler un problème
adiGuba
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 11/05/2015 à 11:51
Citation Envoyé par yahiko  Voir le message
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 HTML : Sélectionner tout 
<script type="text/javascript" src="/script.js"></script>
Code JavaScript : Sélectionner tout 
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 HTML : Sélectionner tout 
<script type="application/java" src="/archive.jar"></script>
Code Java : Sélectionner tout 
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  Voir le message
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  Voir le message
Oui, en fait tu veux que la verbosité et la rigidité contre-productive de Java soit transposée côté navigateur...

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++
2  0 
Washmid
Avatar de Washmid
Membre averti https://www.developpez.com
Le 07/05/2015 à 17:53
Citation Envoyé par MikeRowSoft Voir le message
Je me demande bien comment fonctionne cette machine virtuelle.
La machine virtuelle : http://jmdoudoux.developpez.com/cour...eloppons/java/

Citation Envoyé par MikeRowSoft Voir le message
Je crois qu'il y a des fichiers exécutables pour l'intégration avec les systèmes d'exploitations, mais pas de scripts pour une interaction direct comme pour JavaScript ou Visual Basic Script ou Script Shell ou autres.
On peut créer des exécutables par plateforme (.exe) mais aussi exécuter des scripts (javascript, groovy, python etc.) pas de soucis à ce niveau là. La JVM ne fait pas tourner qu'un langage ! http://en.wikipedia.org/wiki/List_of_JVM_languages

Citation Envoyé par MikeRowSoft Voir le message
Ils ont une priorité défini, même si ils peuvent la changé à leurs guises dans certains cas.
Le Java Community Process a son mot à dire : http://fr.wikipedia.org/wiki/Java_Community_Process

En espérant t'avoir éclairé
1  0 
Gugelhupf
Avatar de Gugelhupf
Modérateur https://www.developpez.com
Le 08/05/2015 à 10:29
Comment améliorer les fichiers de Properties ? Cela a toujours été un fichier plat contenant des paires clé/valeur de chaine depuis le JDK 1.0. Pour des notions plus avancés il y a notamment les fichiers XSD et génération de classes JAXB, qui sont certes lourd à mettre en place, mais je n'ai pas compris l'alternative.
1  0 
Gugelhupf
Avatar de Gugelhupf
Modérateur https://www.developpez.com
Le 11/05/2015 à 11:06
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é).
1  0 
yahiko
Avatar de yahiko
Rédacteur/Modérateur https://www.developpez.com
Le 11/05/2015 à 11:19
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
1  0 
Avatar de
https://www.developpez.com
Le 07/05/2015 à 15:30
Je me demande bien comment fonctionne cette machine virtuelle. Je crois qu'il y a des fichiers exécutables pour l'intégration avec les systèmes d'exploitations, mais pas de scripts pour une interaction direct comme pour JavaScript ou Visual Basic Script ou Script Shell ou autres. Je comprend mieux pourquoi Java... Ils ont une priorité défini, même si ils peuvent la changé à leurs guises dans certains cas.
0  0 
Avatar de
https://www.developpez.com
Le 08/05/2015 à 0:11
Citation Envoyé par Washmid Voir le message


En espérant t'avoir éclairé
Merci, mais je connais déjà cela. Ça ne m'a pas éclairer au sujet l'analyse syntaxique et grammaticale en encore moins au sujet du contenu des dossiers Java. Je crois pas que cela fasse parti de beaucoup de cours universitaires ou de cycles d'ingénieurs, encore moins de B.T.S. ou formations tiers. Cela ce rapproche plus de la certification.
0  0 
_skip
Avatar de _skip
Expert éminent https://www.developpez.com
Le 08/05/2015 à 9:40
Toujours pas d'amélioration sur les Properties après tant d'années. C'est peut être qu'on s'est habitué à l'idée que c'était le travail d'un IDE de générer les 50-200 lignes de plomberie nécessaires aux objets utilisés comme conteneur de données.
Pas non plus de named arguments, de nouveau on va demander à l'IDE de générer un parameter object et une sorte de builder bien lesté. Deux classes pour faire ce qu'une simple syntaxe "name = Jean, age = 10" aurait permis, la sécurité en moins puisqu'on peut toujours oublier de renseigner une propriété dans un builder.

C'est fou mais j'ai l'impression que la puissance des outils de développement a poussé SUN et Oracle a se détourner complètement des lourdeurs à l'écriture de code java.
0  0 
adiGuba
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 08/05/2015 à 11:26
Citation Envoyé par _skip Voir le message
Toujours pas d'amélioration sur les Properties après tant d'années. C'est peut être qu'on s'est habitué à l'idée que c'était le travail d'un IDE de générer les 50-200 lignes de plomberie nécessaires aux objets utilisés comme conteneur de données.
Apparemment il y aura juste enfin le support des fichiers properties en utf8 : http://openjdk.java.net/jeps/226
Quelles genres d'améliorations tu voudrais ?

Citation Envoyé par _skip Voir le message
Pas non plus de named arguments, de nouveau on va demander à l'IDE de générer un parameter object et une sorte de builder bien lesté. Deux classes pour faire ce qu'une simple syntaxe "name = Jean, age = 10" aurait permis, la sécurité en moins puisqu'on peut toujours oublier de renseigner une propriété dans un builder.
Les named arguments c'est bien mais cela pose plusieurs problèmes car c'est peu évolutif :
  • Il faut stocker le nom des paramètres dans les fichiers classes, ce qui n'est pas le cas actuellement sauf à utiliser une option de compilation spécifique.
  • Cela change le status des noms de paramètres, en les rendant "critique" (le simple fait de les changer peut aboutir à une incompatibilité), alors que ce n'est pas plus important qu'un commentaire actuellement.
    Et surtout cela s'appliquerait à tous les paramètres de toutes les méthodes existantes...
  • On s'attend logiquement à ce que cela soit associé à des paramètres par défaut... et cela pose plein de problèmes et d'ambiguités avec la surcharge et la redéfinition !
  • Pire que cela çà rend l'évolution de la méthode complexe et peu intuitive, puisque la moindre modification va générer des incompatibilités binaires, car contrairement à ce qu'on pourrait penser l'ajout d'un paramètre optionnel correspond à un changement incompatible !!


Exemple: Imagine qu'on ait une méthode comme ceci :
Code : Sélectionner tout 
1
2
3
4
5
public class TypeA {
    public void method (String name, int age=0) {
        System.out.println(name + " " + age);
    }
}
Les paramètres nommés/optionnels fonctionnent via du sucre syntaxe à l'exécution, qui s'occupe de remplacer les valeurs et d'effectuer le bon appel de méthode :
Code : Sélectionner tout 
1
2
3
4
5
6
7
8
9
TypeA a = ...

a.method(name:"Fred");
a.method(age: 25, name:"Eric");

// est équivalent à :

a.method("Fred", 0);
a.method("Eric", 25);

Maintenant si on veut faire évoluer notre méthode en lui rajoutant un paramètre ("firstName" par exemple), en toute logique on essayerait ceci :
Code : Sélectionner tout 
1
2
3
4
5
public class TypeA {
    public void method (String name, int age=0, String firstName=null) {
        System.out.println(name + " " + Objects.toString(firstName,"") + " " + age);
    }
}
Et çà marche ! Youpi on est content et on déploie notre code...
Sauf que cela marche bien dans notre éditeur car il va s'occuper de tout recompiler comme il faut... mais on vient de générer une incompatibilité binaire avec tous les codes qui utilisait notre méthode.

En effet si on n'a pas recompilé le code, il tente toujours d'appeler une méthode method(String,int) qui n'existe plus, ce qui va générer un beau MethodNotFoundException...

Et pour éviter cela il faut revenir à la surcharge afin que la méthode originelle soit toujours présente :
Code : Sélectionner tout 
1
2
3
4
5
6
7
8
9
public class TypeA {
    public void method (String name, int age) {
        method(name, age, null);
    }

    public void method (String name, int age=-1, String firstName=null) {
        System.out.println(name + " " + Objects.toString(firstName,"") + " " + age);
    }
}


Second effet kiss-cool : je veux renommer mon paramètre "name" (désormais le terme "lastName" serait plus approprié)... mais cela provoquerait une incompatibilité des sources obligeant la modification de l'appel de la méthode en cas de recompilation !

De même si j'ai une méthode anodine du genre setEnabled(boolean b), et je souhaite renommer le paramètre "b" en "enabled" qui me semble plus approprié... mais cela provoquerait des incompatibilité avec deux qui l'aurait utilisé comme ceci setEnabled(b:true) !

Et encore je n'ai même pas parlé d'éventuelle redéfinition dans une classe fille qui viendrait encore plus embrouillé le tout, ou encore de la valeur par défaut qui dépend aussi de la compilation !!!

Bref les paramètres nommées/optionnels c'est bien dans un langage de script comme PHP (car tout est réinterprété à chaque exécution) ou alors limité au sein d'une même application (mais comment limité cela ?).
Mais dans un langage plus complexe et compilé comme Java cela peut apporter son lot de problèmes...

Le "Builder" reste une bien meilleure solution pour le moment... même si c'est plus lourd.
A la rigueur selon la syntaxe finale cela pourrait être remplacé par des type-values...

a++
0  0 
_skip
Avatar de _skip
Expert éminent https://www.developpez.com
Le 08/05/2015 à 12:35
Citation Envoyé par adiGuba Voir le message
Apparemment il y aura juste enfin le support des fichiers properties en utf8 : http://openjdk.java.net/jeps/226
Quelles genres d'améliorations tu voudrais ?
Je vois que j'ai pas été clair, je parlais de propriétés au sens getter/setter. Pas pensé une seule seconde à la confusion que cela pouvait engendrer avec le format .properties


[*] Il faut stocker le nom des paramètres dans les fichiers classes, ce qui n'est pas le cas actuellement sauf à utiliser une option de compilation spécifique.
Juste, c'est vrai qu'actuellement le nom se perd à la compilation ce qui peut être un problème si on a pas la source à dispositon mais juste les .class ou un jar. Mais plein de langages pour la JVM ont prouvé que c'était largement possible.

Cela change le status des noms de paramètres, en les rendant "critique" (le simple fait de les changer peut aboutir à une incompatibilité), alors que ce n'est pas plus important qu'un commentaire actuellement.
Et surtout cela s'appliquerait à tous les paramètres de toutes les méthodes existantes...
Ca n'a rien d'anodin à mon sens de modifier les paramètres d'une méthode, je trouve pas que changer le nom des arguments soit très normal non plus sur une API destinée au grand monde (encore plus si le changement est aussi sémantique) enfin tout à fait au même titre qu'une modification de signature. Question de point de vue, surtout que si tu utilises nommément un argument dans un appel, tu acceptes de dépendre du nom de l'argument en le considérant comme un élément à part entière de la signature, ce que tu n'es absolument pas obligé de faire puisque la syntaxe positionnelle continuerait de fonctionner.


[*] On s'attend logiquement à ce que cela soit associé à des paramètres par défaut... et cela pose plein de problèmes et d'ambiguités avec la surcharge et la redéfinition !
Non perso je vois plein de cas d'utilisation valide où ça n'a rien à voir avec des défauts. Même si les défauts sont une évolution valide.

Pire que cela çà rend l'évolution de la méthode complexe et peu intuitive, puisque la moindre modification va générer des incompatibilités binaires, car contrairement à ce qu'on pourrait penser l'ajout d'un paramètre optionnel correspond à un changement incompatible !!
Dans le cas où la magie s'opère à la compilation, je vois pas trop ce que ça pourrait venir ennuyer. Pour le reste c'est simple, tu mets à jour ton code, tu dois renommer l'argument auquel tu fais référence, je suis persuadé que si c'était là le problème, les IDE seraient assez intelligents pour te faire ça. Le seul ennui que je vois c'est si tu essaies soudainement de compiler avec une autre version d'un jar externe où un nom a été changé. Là oui ton code compile plus car la liste d'argument est différente, question : C'est aussi grave que ça sachant que c'est détecté à la compilation? Et même est-ce que ça peut pas attirer ton attention sur un possible changement sémantique?


Bref les paramètres nommées/optionnels c'est bien dans un langage de script comme PHP (car tout est réinterprété à chaque exécution) ou alors limité au sein d'une même application (mais comment limité cela ?).
Mais dans un langage plus complexe et compilé comme Java cela peut apporter son lot de problèmes...
Ce ne sont pas des problèmes, mais de possibles inconvénients. L'ancien code continuerait d'être fonctionnel puisqu'on parle d'introduire une syntaxe alternative qui n'existe pas donc ces problèmes se poseraient principalement sur le nouveau code (java 9+).
Perso je trouve que les parameters objects + builders particulièrement lourds, et bien moins sécurisants encore.
0  0 
Commenter Signaler un problème