Java 9 sortira en version stable le 22 septembre 2016
Le gel des fonctionnalités est prévu pour le 10 décembre 2015
Le 2015-05-07 14:15:15, par Hinault Romaric, Responsable .NET
Mark Reinhold, architecte en chef du groupe de la plateforme Java chez Oracle, vient de présenter la feuille de route pour le développement de Java 9, qui devrait aboutir à la publication de la version stable dans 15 mois.
Le calendrier prévoit ce qui suit :
Le responsable du développement de Java précise que ces dates ont été définies de façon à laisser suffisamment de temps pour l’examen général, les tests des caractéristiques importantes, en particulier l’introduction d’un système de module.
Toutefois, le calendrier doit être pris avec réserve. Car avec les fonctionnalités importantes dont dispose cette version, il n’est pas exclus qu’un blocage puisse entrainer un report. Il faut rappeler que Java 8 avait été reporté afin de colmater les failles de sécurité dans la plateforme.
Actuellement, Java 9 peut être testé à travers la dernière préversion (Early Access) du JDK 9 qui est disponible sur le site du projet. Au menu des caractéristiques qui avaient été présentées par Oracle, on peut noter :
La fonctionnalité la plus attendue est, sans aucun doute, la prise en charge de la modularité (projet Jigsaw). Cette fonctionnalité a entrainé de gros changements au JDK. Elle 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.
Les défis a relevé avec ce projet ont été nombreux pour les ingénieurs d’Oracle. Son implémentation avait été initialement prévue avec Java 8. Le projet a été repoussé à Java 9 et il a été redéfini à maintes reprises.
Avec Java 9, Oracle se donne pour mission de publier une nouvelle version de la plateforme tous les deux ans.
Télécharger la Early Access du JDK 9
Source : OpenJDK
Le calendrier prévoit ce qui suit :
- 10/12/2015 : intégration de toutes les fonctionnalités dans la branche principale ;
- 04/02/2016 : finalisation des tests sur toutes les plateformes supportées ;
- 25/02/2016 : contrôle des changements entrants ;
- 21/04/2016 : finalisation avec le traitement du carnet des bogues :
- 16/06/2016 : deuxième série de contrôle des changements entrants ;
- 27/06/2016 : publication de la Release Candidate finale ;
- 22/09/2016 : disponibilité générale de Java 9, pour une utilisation en environnement de production.
Le responsable du développement de Java précise que ces dates ont été définies de façon à laisser suffisamment de temps pour l’examen général, les tests des caractéristiques importantes, en particulier l’introduction d’un système de module.
Toutefois, le calendrier doit être pris avec réserve. Car avec les fonctionnalités importantes dont dispose cette version, il n’est pas exclus qu’un blocage puisse entrainer un report. Il faut rappeler que Java 8 avait été reporté afin de colmater les failles de sécurité dans la plateforme.
Actuellement, Java 9 peut être testé à travers la dernière préversion (Early Access) du JDK 9 qui est disponible sur le site du projet. Au menu des caractéristiques qui avaient été présentées par Oracle, on peut noter :
- l’intégration de « HTTP2 Client » pour le support du HTTP 2.0 et des web sockets ;
- l’ajout de « Process API Updates » qui permet d’améliorer le contrôle, la gestion et l’interaction avec les processus non Java ;
- l’introduction d’un système d’enregistrement commun pour tous les composants de la JVM ;
- Plus de contrôle au niveau de la compilation ;
- Des améliorations pour le projet Coin, qui avait été introduit avec Java 7 ;
- Le support des modules et bien plus.
La fonctionnalité la plus attendue est, sans aucun doute, la prise en charge de la modularité (projet Jigsaw). Cette fonctionnalité a entrainé de gros changements au JDK. Elle 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.
Les défis a relevé avec ce projet ont été nombreux pour les ingénieurs d’Oracle. Son implémentation avait été initialement prévue avec Java 8. Le projet a été repoussé à Java 9 et il a été redéfini à maintes reprises.
Avec Java 9, Oracle se donne pour mission de publier une nouvelle version de la plateforme tous les deux ans.
Source : OpenJDK
-
adiGubaExpert éminent séniorJe 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 : <script type="text/javascript" src="/script.js"></script>
Code JavaScript : 1
2
3
4
5document.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 : <script type="application/java" src="/archive.jar"></script>
Code Java : 1
2
3
4
5
6Document document = Browser.getDocument(); document.getElementByID("title").setInnerText("Titre de mon application"); document.getElementByID("button").addEventListener("click", (e) -> { Window.alert("click on button"); }
Avoir du code typesafe et un vrai langage bien pensé.
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++le 11/05/2015 à 11:51 -
WashmidMembre avertiLa machine virtuelle : http://jmdoudoux.developpez.com/cour...eloppons/java/
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
Le Java Community Process a son mot à dire : http://fr.wikipedia.org/wiki/Java_Community_Process
En espérant t'avoir éclairéle 07/05/2015 à 17:53 -
GugelhupfModérateurComment 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.le 08/05/2015 à 10:29
-
GugelhupfModérateurJe 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é).le 11/05/2015 à 11:06 -
yahikoRédacteur/ModérateurIl 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. CQFDle 11/05/2015 à 11:19 -
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.le 07/05/2015 à 15:30
-
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.le 08/05/2015 à 0:11
-
_skipExpert éminentToujours 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.le 08/05/2015 à 9:40 -
adiGubaExpert éminent séniorApparemment 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 ?
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 : 1
2
3
4
5public class TypeA { public void method (String name, int age=0) { System.out.println(name + " " + age); } }
Code : 1
2
3
4
5
6
7
8
9TypeA 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 : 1
2
3
4
5public class TypeA { public void method (String name, int age=0, String firstName=null) { System.out.println(name + " " + Objects.toString(firstName,"") + " " + age); } }
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 : 1
2
3
4
5
6
7
8
9public 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++le 08/05/2015 à 11:26 -
_skipExpert éminentJe 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.
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 !!
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...
Perso je trouve que les parameters objects + builders particulièrement lourds, et bien moins sécurisants encore.le 08/05/2015 à 12:35