Annonces Google

Python Avancé

Télécharger le cours complet


  1. Les modules en Python
  2. Le module OS
  3. Gestion des fichiers en Python
  4. Fichier de configuration .ini
  5. Python et bases de données SQLite
  6. Python et bases de données MySql
  7. DB Browser for SQLite
  8. Interface Graphique avec Tkinter
  9. La bibliothèque d'images PILLOW
  10. Le module de style tkinter.ttk
  11. Projet: Création d'un éditeur de texte
  12. Interface graphique avec wxPython
  13. Le framework Django

Télécharger le cours complet

Utilisateurs en ligne

Users: 3 Guests, 2 Bots

Tutoriels Informatiques

TICE & Multimédias

Math-pour-Informatiques

Anglais pour débutants

Nous somme sur Facebook

  


En ce début d’année 2019, examinons certaines des choses à surveiller dans le Nouvel An en Java et les technologies associées, et amusons-nous en essayant de prévoir ce qui pourrait arriver.

1 – Java 11 commence à être adopté de manière modeste mais significative

Cela pourrait être la prédiction la moins controversée de cette liste. Java 9 et 10 n’ont pratiquement pas été déployés en production. De nombreuses équipes semblent attendre la sortie d’une version LTS post-8, et maintenant qu’elle est là, une adoption modeste mais constante de Java 11 va commencer à apparaître.
Les microservices et les applications conteneurisées sont des moteurs importants de cette adoption. Ils sont tous deux beaucoup plus simples avec Java 11 que Java 8. Le déploiement d’applications inédites de Greenfield constituera l’endroit évident pour que les équipes commencent à adopter Java 11.
Prédiction: Java 11 représente environ 10% de l’ensemble des installations de production Java signalées à la fin de 2019.

2 – Pas de portage à grande échelle d’applications existantes de 8 à 11

Jusqu’à présent, le chemin de mise à niveau Java pour les applications était relativement propre. Passer de 6 à 7 ou de 7 à 8 a été, dans presque tous les cas, totalement indolore. On ne peut pas en dire autant de la mise à niveau de la version 8 à 11: un travail important est généralement nécessaire pour déplacer une application non triviale sur la nouvelle version.
Très peu de groupes d’applications ont les ressources pour entreprendre un port, un site de recherche et un test complet de leurs applications, simplement pour rester sur la version actuelle de Java. Par conséquent, je ne prévois pas un portage généralisé des applications Java 8 vers Java 11, sans autre raison externe impérieuse de le faire.
Prédiction: Aucune prédiction quantifiable spécifique.

3 – Pas d’analogue  pour Java en vertu de la de la division Python 2 / Python 3

On a beaucoup parlé de la possibilité qu’avec l’avènement de la Java modulaire, l’écosystème se fragmente sur le modèle de la division de Python 2 / Python 3 expérimentée par cette communauté.
Je ne m’attends pas à ce que cela se produise pour plusieurs raisons, mais la principale est que Java 11 n’est pas un langage fondamentalement différent, que ce soit au niveau syntaxique ou sémantique. La syntaxe Python et la signification des types de données clés (chaînes Unicode ou longues, par exemple) changent d’une version à l’autre. Les auteurs de bibliothèques et d’applications doivent donc choisir consciemment la version linguistique ciblée. Ce choix imprègne l’écosystème tout entier.
En revanche, dans le cas de Java, le propriétaire de l’application doit choisir la modularité ou non; et le choix du développeur de la bibliothèque quant à l’opportunité de déployer en tant que modules et, le cas échéant, les solutions de repli à offrir aux applications Java 8. De nos jours, le programmeur Java continue de fonctionner comme avant et programme dans le même langage, que le projet sur lequel ils travaillent soit ciblé sur Java 8 ou 11.
Prédiction: Aucune prédiction quantifiable spécifique.

4 – Poursuite de l’adoption progressive du Graal

Pour les projets ayant migré vers Java 11, le projet Graal suscitera probablement un intérêt croissant. Cela inclut le compilateur JIT de nouvelle génération, qui peut atteindre (voire même surpasser) le compilateur C2 (ou serveur) pour Java 11 en 2019.
Que Graal-JIT dépasse tôt ou tard C2 semble évident – la conception de Graal (en particulier le fait qu’elle est implémentée en Java) signifie qu’il est relativement facile pour l’équipe Graal d’implémenter toute nouvelle optimisation pouvant être implémentée dans C2.
Le terme générique « Graal » inclut également le projet GraalVM semi-ouvert d’Oracle pour des exécutions polyglottes. Cependant, il est important de noter que Graal-JIT est uniquement disponible pour Java 11 et versions ultérieures, alors que GraalVM ne couvre que Java 8.
Par conséquent, la communauté des utilisateurs de Graal pourrait bien former deux groupes disjoints: l’un axé sur les performances des applications Java 11 et l’autre sur les applications polyglottes exploitant l’écosystème Java 8.
Prédictions:
30 à 40% des applications Java 11 utilisent Graal-JIT dans leurs déploiements de production Java 11
Faire de Graal le compilateur JIT par défaut est sérieusement discuté pour Java 13 mais finalement pas implémenté
Les déploiements de production GraalVM restent rares, mais sont de plus en plus expérimentés par les équipes d’application.

5 – OpenJDK devient le leader du marché des runtimes Java

Oracle est en train de mettre fin au projet OpenJDK 8 et Red Hat a proposé de le remplacer. Il en va peut-être de même pour le projet OpenJDK 11, car ce projet sera abandonné par Oracle lors de la sortie de Java 12.
De nombreux développeurs oublient le fait que les offres LTS d’Oracle ne concernent que les clients payants. Ainsi, à l’avenir, les seules offres de support gratuites pour Java 8 (et 11, une fois que Java 12 sera disponible) proviendront d’organisations non-Oracle. , tels que Red Hat, Amazon, Azul Systems et le projet AdoptOpenJDK piloté par la communauté, qui regroupe plusieurs fournisseurs.
Aucune autre mise à jour gratuite d’OracleJDK n’étant mise à la disposition de la communauté, je m’attends donc à une transition rapide vers OpenJDK en tant que plate-forme de production de choix pour les applications Java.
La bonne nouvelle est que, pour les applications côté serveur (et de plus en plus pour les applications Java de bureau), OpenJDK est un remplacement instantané du JDK d’Oracle.
Prédiction: à la fin de 2019, plus de 50% des programmes d’exécution de production Java 8 et Java 11 utilisaient OpenJDK plutôt que le JDK Oracle.

6 – Sortie de Java 12

Java 12 est gelé avec des fonctionnalités et devrait sortir en mars 2019. Sauf incident majeur, il est difficile de prévoir que cela ne sera pas livré à temps.
Il ne s’agit pas d’une version de support à long terme et il est peu probable qu’elle soit adoptée à grande échelle (de même que Java 9 et 10 n’ont pas été largement adoptés).
Prédiction: Java 12 est disponible dans les temps et les déploiements de production d’erreur d’arrondi fin 2019.

7 – Sortie de Java 13

Java 13 devrait sortir en septembre 2019. Aucun détail n’est disponible sur les fonctionnalités actuellement visées par cette version.
Comme pour Java 12, il s’agit d’une version fonctionnelle, et non d’une version LTS. En conséquence, il n’ya aucune raison pour le moment de supposer qu’il ne sera pas expédié à temps. De même, il est peu probable que la solution soit adoptée à grande échelle, les équipes se concentrant plutôt sur le passage de Java 11 à la production.
Prédiction: Java 13 est disponible à temps et les déploiements en production d’erreurs d’arrondi fin 2019.

8 – Les  values type  ne sont pas livrés comme aperçu en Java 13

Les  values types  consistent à apporter un troisième type de valeur fondamentale à la JVM, à côté des types primitifs et des références d’objet. Le concept peut être considéré comme assouplissant certaines des règles du système de type Java, permettant des structures de données composites plus similaires aux structures C, sans bagage, tout en conservant une sécurité totale du type Java.
Brian Goetz, l’architecte du langage Java, utilise l’expression: « les codes comme une classe fonctionne comme un int » pour décrire comment il envisage qu’un développeur typique utilise la fonctionnalité des types de valeur une fois qu’elle a été livrée.
Il y a eu des progrès soutenus et continus vers les types de valeur, mais à la fin de 2018, seuls des prototypes alpha expérimentaux à accès très précoce et réservés aux experts avaient déjà été produits.
Cela n’est pas surprenant: les types de valeur constituent l’un des changements les plus fondamentaux et les plus profonds jamais apportés à la plate-forme Java.
La complexité et l’ambition de cette fonctionnalité, ainsi que l’ampleur des travaux d’ingénierie nécessaires, rendent très improbable sa réalisation, même sous une forme initiale en 2019.
Prédiction: Aucune forme de type de valeur n’est incluse, même en tant que fonctionnalité de prévisualisation dans Java 13.

9 – La version initiale des expressions de correspondance est fournie avec aperçu en Java 13

Les expressions de commutation sont une condition préalable pour les expressions de correspondance. Sans une forme d’expression présente dans la syntaxe, il est impossible de déployer des expressions de correspondance dans le langage Java. En effet, sans expressions de correspondance, il est très inutile d’introduire des expressions de commutation.
En conséquence, je m’attends à ce que les expressions de commutateur normalisées soient suivies rapidement par des formes simples d’expressions de correspondance. La fonctionnalité sera probablement limitée aux correspondances de type uniquement initialement, sans aucune déstructuration ni autre fonctionnalité avancée.
Prédiction: Une forme initiale limitée de Match Expressions est incluse en tant que fonctionnalité de prévisualisation dans Java 13.

10 – Croissance modeste de Kotlin

Le langage Kotlin de JetBrains a suscité un intérêt croissant des développeurs ces dernières années. En particulier dans l’espace Android, il y a eu une explosion et une domination de Kotlin pour les nouveaux projets sur Android.
Cependant, aucune explosion comparable ne s’est produite dans Java côté serveur, le cœur traditionnel des langages JVM. En 2019, je constate une adoption progressive de Kotlin, mais pas une multitude de projets / d’équipes s’y rendant. Plusieurs projets de grande envergure utiliseront publiquement Kotlin.
Prédiction: Kotlin continuera de gagner des fans dans la communauté Java, mais ne percera pas et restera plus petit que l’écosystème Scala.
Ce qui précède met en évidence certains des changements aux limites de Java. Cependant, dans le reste du monde Java, ce sera une autre année  identique. Les IDE de Java, les bibliothèques et le reste de l’écosystème continueront essentiellement sur la même trajectoire.
La position solide et le dynamisme de Java au sein du secteur continueront à le faire évoluer sans bouleversement majeur.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Time limit is exhausted. Please reload the CAPTCHA.

Nous sommes sur Facebook