IdentifiantMot de passe
Loading...
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 !

Le JDK 16 est déjà en cours de développement, bien que les travaux sur le JDK 15 continuent,
Et devrait arriver avec la prise en charge des fonctionnalités du C++ 14

Le , par Bill Fassinou

212PARTAGES

9  0 
Bien que les travaux sur le JDK 15 continuent, avec une disponibilité générale prévue pour le 15 septembre, le JDK 16, son successeur, est déjà en cours de développement. Le site Web de l’OpenJDK dédié à cet exercice recense désormais 3 JEP (JDK Enhancement Proposals). Prévu pour mars 2021, le JDK 16 devrait arriver avec la prise en charge des fonctionnalités du C++ 14 dans le code source C++ du JDK. La communauté de l’OpenJDK prévoit également de migrer les référentiels de code source OpenJDK de Mercurial vers Git (GitHub) pour diverses raisons.

Activation des fonctionnalités du langage C++ 14

Selon la description donnée par le JEP 347, ce changement vise l'utilisation des fonctionnalités du C++ 14 dans le code source C++ du JDK et à donner des indications spécifiques sur les fonctionnalités qui peuvent être utilisées dans le code de la VM HotSpot. Par le biais du JDK 15, les caractéristiques du langage utilisées par le code C++ dans le JDK ont été limitées aux normes du langage C++ 98/03. Avec le JDK 11, le code source a été mis à jour pour permettre la construction avec des versions plus récentes du standard C++.


Cela inclut la possibilité de construire avec des versions récentes de compilateurs qui prennent en charge les caractéristiques du langage C++ 11/14. La présente proposition ne propose aucun changement de style ou d'usage pour le code C++ utilisé en dehors du HotSpot. Les règles sont déjà différentes pour le code du HotSpot et pour le code non HotSpot. À titre d’exemple, les exceptions C++ sont utilisées dans certains codes non HotSpot. Par contre, elles sont interdites dans HotSpot par les options de compilation.

Cependant, les exigences de cohérence de la construction rendront les nouvelles fonctionnalités du langage disponibles pour une utilisation dans tout le code C++ du JDK. Ensuite, pour tirer profit des fonctionnalités du langage C++, certaines modifications doivent être apportées au fil du temps, les détails dépendant du compilateur de la plateforme. Les versions minimales acceptables des différents compilateurs de plateforme doivent également être spécifiées. Le standard de langage souhaité doit être spécifié explicitement.

Migration des dépôts de code source OpenJDK de Mercurial vers Git

Le développement du JDK 16 se fera en même temps que la migration des référentiels de code source de la communauté OpenJDK de Mercurial (hg) vers Git. Le JEP 357 donne plusieurs raisons à cela. L’une d’entre elles est que les premiers prototypes de dépôts convertis montrent une réduction significative de la taille des métadonnées de contrôle de version. Par exemple, le répertoire .git du dépôt jdk/jdk est d'environ 300 Mo avec Git et le répertoire .hg est d'environ 1,2 Go avec Mercurial, selon la version de Mercurial utilisée, ce qui présente plusieurs avantages.

Le JEP 357 indique que cette réduction des métadonnées préserve l'espace disque local et réduit les temps de clonage, car moins de bits doivent passer par le fil. Git comporte également des clones peu profonds qui ne clonent que des parties de l'historique, ce qui permet de réduire encore les métadonnées pour les utilisateurs qui n'ont pas besoin de l'historique complet. Ainsi, l’objectif de cette action est de migrer tous les projets OpenJDK à dépôt unique de Mercurial vers Git, conserver l'historique du contrôle des versions, y compris les balises, reformater les messages d'engagement selon les meilleures pratiques de Git, porter les outils jcheck, webrev et defpath vers Git et créer un outil de traduction entre les hachages Mercurial et Git.

La migration vers GitHub

La migration vers GitHub est liée à la migration de Mercurial vers Git, avec des dépôts de code source JDK 16 qui seront sur le populaire site de partage de code. Mais pourquoi GitHub ? Le JEP 369 indique que la motivation pour choisir GitHub est qu'il excelle dans les trois principales raisons de choisir un fournisseur externe. Les performances de GitHub sont aussi bonnes, voire supérieures à celles des autres fournisseurs, c'est le plus grand service d'hébergement de code source au monde (50 millions d'utilisateurs en mai 2020), et il possède l'une des API les plus complètes.

Ce choix est aussi motivé par l'API étendue de GitHub qui permet la prise en charge de nombreux outils, notamment des éditeurs de texte, des EDI, des outils de ligne de commande et des clients de bureau graphique. Les versions préliminaires du JDK 16 pour Linux, Windows et macOS sont disponibles à l'adresse jdk.java.net. Comme le JDK 15, le JDK 16 sera une version à court terme, supportée pendant six mois. Le JDK 17, prévu pour septembre 2021, sera une version de support à long terme (LTS) qui bénéficiera d'un support pendant plusieurs années. La version actuelle du LTS, le JDK 11, est sortie en septembre 2018.

Source : Site de l’OpenJDK

Et vous ?

Qu'en pensez-vous ?

Voir aussi

Java 15 est déjà sur les rails : la prochaine version standard ajoutera des blocs de texte et des Garbage Collectors et supprimera le moteur JavaScript Nashorn

Java 14 est disponible en version définitive avec de nouvelles fonctionnalités de productivité des développeurs, dont Switch Expressions, Records et autres

JDK 14 va apporter plus de fonctionnalités que les deux versions précédentes combinées. Petit tour d'horizon sur celles qui sont susceptibles d'intéresser le plus les développeurs

Le JDK 9 va supporter la compilation anticipée (AOT) en commençant par les systèmes Linux 64-bit exécutant Java 64-bit

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

Avatar de thelvin
Modérateur https://www.developpez.com
Le 18/03/2021 à 16:02
Ça tombe bien, ça fait un sacré bail que Java 8 n'est plus supporté. En tout cas pas sa version canonique, fournie par Oracle. D'autres comme Coretto fournissent leur propre mouture du JDK 8 et le maintiennent encore, jurant à qui veut l'entendre que ça continuera pendant un bon moment.

Sinon, l'approche recommandée, c'est de fournir des exécutables natifs aux clients chez qui on installe pas Java nous-même. jpackager (pour faire des .exe, .msi ou équivalents MacOS et linux à partir d'un programme Java) est justement mis en avant dans cette nouvelle release. Il existait avant, et puis il y avait des alternatives tierces.

"Mais l'intérêt de Java n'est-il pas d'être indépendant des système et machine hôtes ?" Ça fait un sacré bail que Java n'est plus le seul, et les autres qui font pareil, ne distribuent que des exécutables natifs. Autrement dit, ça fait bien plus de 10 ans qu'on a compris que s'abstraire de l'hôte, ça donne de gros avantages d'architecture de conception, mais que le fait qu'à la fin le livrable binaire puisse tourner sur n'importe quelle machine ça n'a aucun intérêt. Il en existe trois, de toute façon, des machines différentes. L'abstraction précitée permet de partir du programme Java et de générer les trois binaires pour les trois machines clientes possibles, sans effort.

Quant aux cas où on a vraiment besoin d'être abstraits du système, c'est pour être capable de s'adapter aux changements d'écosystèmes qui ne préviennent pas. C'est pour les applications hébergées, pas les applications qui tournent sur un ordi de salon. Et même si c'est pas le fournisseur qui héberge, en 2019 (pardon, 2021,) les livrables de ce genre d'applis ce sont des images docker. Sur lesquelles Java entre autres est installé. Dont le fournisseur a bien évidemment lui-même choisi la version.
1  1 
Avatar de thelvin
Modérateur https://www.developpez.com
Le 18/03/2021 à 18:20
Citation Envoyé par walfrat Voir le message
Car si tu livre avec un .bat, il faut autoriser la ligne de commande.
? Curieuse idée... Il suffit de double-cliquer sur le .bat.

Et de fournir un raccourci avec icône qui se contente de lancer le .bat.
1  1 
Avatar de lvr
Membre extrêmement actif https://www.developpez.com
Le 18/03/2021 à 21:39
Citation Envoyé par thelvin Voir le message
Sinon, l'approche recommandée, c'est de fournir des exécutables natifs aux clients chez qui on installe pas Java nous-même. jpackager (pour faire des .exe, .msi ou équivalents MacOS et linux à partir d'un programme Java) est justement mis en avant dans cette nouvelle release. Il existait avant, et puis il y avait des alternatives tierces.
Je crois que je vais me pencher vers .jarpackager. Mais, bon, comme mes apps sont des apps perso fait sur mon petit temps libre et que je mets à dispo de qui ça intéresse, cette hétérogénéité ne motive pas trop à partager son taf...
0  0 
Avatar de lvr
Membre extrêmement actif https://www.developpez.com
Le 21/03/2021 à 22:13
Citation Envoyé par thelvin Voir le message
Sinon, l'approche recommandée, c'est de fournir des exécutables natifs aux clients chez qui on installe pas Java nous-même. jpackager (pour faire des .exe, .msi ou équivalents MacOS et linux à partir d'un programme Java) est justement mis en avant dans cette nouvelle release. Il existait avant, et puis il y avait des alternatives tierces.
Je suis parti vers le plugin Maven io.github.fvarrui.javapackager .
Je cale sur comment faire un exe Linux (e.g. un ".deb" sous Windows...De manière, avec javapackager, c'est possible où la seule option est de faire un ".tar.gz" ?
0  0 
Avatar de walfrat
Membre émérite https://www.developpez.com
Le 19/04/2021 à 15:47
Citation Envoyé par thelvin Voir le message
? Curieuse idée... Il suffit de double-cliquer sur le .bat.

Et de fournir un raccourci avec icône qui se contente de lancer le .bat.
Ben d'après ce qu'on m'a rapporté, si tu interdit l'accès a cmd.exe au poste client, double clicquer sur un bat ne marche pas. Il faut donc livrer un EXE.
0  0 
Avatar de bouye
Rédacteur/Modérateur https://www.developpez.com
Le 21/04/2021 à 0:51
Citation Envoyé par lvr Voir le message
Je suis un peu confus entre les version du JRE et celles du JDK.
Peut-on écrire du code avec le JDK 16 (pour par exemple profiter de fonctionnalités comme les blocs de textes) et l'exécuter avec une JRE 1.8 ?
Le JRE n'existe plus depuis belle lurette, deal with it!

Il devrait etre possible d’écrire du code en JDK 16 pour l'executer sur du JDK/JRE (1.)8 si on se contente d'utiliser des anciennes API, aucun des ajouts apportes par les JDK 9-10-11-12-13-14-15 et 16 et avec le flag qu'il faut pour sortir du bytecode compatible JDK/JRE (1.)8. Qq chose dans le genre javac -source 1.8 -target 1.8 ... ou un truc du genre. Normalement les IDE permettent de configurer ce genre de choses.

Et sinon on vous fourni un outil pour créer des applications avec lanceur natif donc le fichier bat/script de lancement sur la ligne de commande il serait également temps de l'envoyer aux oubliettes. Bon après il va falloir aussi la signer numériquement votre app si vous voulez pas que Windows / votre antivirus envoie des alarmes a l'utilisateur...
0  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 24/04/2021 à 7:03
Citation Envoyé par bouye Voir le message
Il devrait etre possible d’écrire du code en JDK 16 pour l'executer sur du JDK/JRE (1.)8 si on se contente d'utiliser des anciennes API, aucun des ajouts apportes par les JDK 9-10-11-12-13-14-15 et 16 et avec le flag qu'il faut pour sortir du bytecode compatible JDK/JRE (1.)8. Qq chose dans le genre javac -source 1.8 -target 1.8 ... ou un truc du genre. Normalement les IDE permettent de configurer ce genre de choses.
C'est possible, mais je le déconseille fortement. En faisant ça, on peut facilement utiliser sans s'en rendre compte une méthode/classe qui n'existe pas dans la version ciblée. Du coup, on se retrouve, avec un code qui compile et fonctionne bien sur l'environnement de développement, mais qui plantera à l'exécution sur l'environnement final, parfois de manière sournoise.

Il est généralement plus prudent d'utiliser le JDK qui correspond à la version minimale ciblée.
0  0 
Avatar de lvr
Membre extrêmement actif https://www.developpez.com
Le 17/03/2021 à 11:27
Je suis un peu confus entre les version du JRE et celles du JDK.
Peut-on écrire du code avec le JDK 16 (pour par exemple profiter de fonctionnalités comme les blocs de textes) et l'exécuter avec une JRE 1.8 ?
0  1 
Avatar de Jonathan muswil
Membre à l'essai https://www.developpez.com
Le 17/03/2021 à 18:47
Quand je pense a sun vraiment 🤔🤔🤔
1  2 
Avatar de lvr
Membre extrêmement actif https://www.developpez.com
Le 18/03/2021 à 15:41
Comment gérer l'hétérogénéité de la distribution du JRE pour des app grand public ?
Je constate que sous Windows c'est encore souvent la 1.8 (sans toujours une possibilité de mettre à jour (ex des PC corporate)).
Sous ma VM Xubuntu, openJdk 8 et 11 sont présents, ...
Donc j'aurais tendance à tout garder sour Java 8, tant qu'elle est supportée, et quand elle ne l'est plus, alors passer à Java 11.
C'est quoi votre approche ?
0  1