Par défaut les logs Java sont affichés sur deux lignes (la 1er contient la date, la 2e le type et le contenu) :
sept. 28, 2020 4:35:04 PM org.apache.karaf.main.Main launch INFOS: All initial bundles installed and set to start
Dans les propriétés globales de la JVM Java (option : -DmaVaraible=maValeur), la variable « java.util.logging.SimpleFormatter.format » permet de configurer le formatage des logs. Pour afficher les logs sur une seule ligne, utilisez le paramétrage suivant :
"%1$tFT%1$tTZ [%4$s] [%2$s] %5$s%6$s%n"
Par exemple pour lancer l’application mon-app.jar:
Si vous voulez un format plus lisible pour la date (avec time zone) utilisez le format suivant « %1$s [%4$s] [%2$s] %5$s%6$s%n« . Ce qui donne pour par exemple :
Il existe plusieurs VM Java pour différent système d’exploitation (voir la liste si dessous).
Dans ma recherche de binaire JVM exploitable en production, sur des systèmes Windows, Mac, Linux, et pouvant être packager dans un kit d’installation j’ai référencé 3 JVM :
Toutes sont basées sur OpenJDK et supportent les versions 8 et 11 de Java.
Dans cette liste, la version Hotspot d’Oracle à deux URLs de téléchargement adoptopenjdk et java.net. Le binaire qui se trouve chez Oracle (java.net) ne permet plus d’être package dans un kit d’installation et sa mise à jour nécessite un accord commercial avec Oracle (payant).
Il reste donc deux sites web ou trouvera un binaire pour Windows, Linux, Mac :
https://adoptopenjdk.net : propose les JVM HotSpot et Open J9 en version 8 et 11 pour de multiples systèmes Linux , x86, x64,Windows , Mac ARM, AIX …
Eclipse permet de formater le code source, menu "Source/Format" ou touche "Ctrl + Shfit + F". Cella permet homogénéiser le code source et aussi de voir s'il ne contient pas d'erreur (le formatage ne se fait pas, ou ne correspond pas à ce que l'on attend).
Mais il peut arriver que vous ne souhaitiez pas de formatage localement dans votre source.
C’est le 21 septembre 2017 qu’est sorti le la version 9 de Java (initialement prévue pour le 27 juillet ).
Beaucoup de nouveauté dans cette version : modularisation, interpréteur Java (JShell), simplification du langage (type générique var, …) optimisation, nouvelle API …
Dans cet article j’ai essayé de faire le tour de tous ces changements.
Jshell permet d’exécuter du code Java en ligne sans devoir créer un fichier ou une classe.
Il supporte l’interprétation temps réel des expressions et des boucles Java.
« Modularisation » de Java (Jigsaw)
Maintenant Java permet de créer des modules à la place des jars et les API Java ont elles-mêmes été modularisées.
Le but est de pouvoir indiquer quelle sont les modules que vous avez besoin, et de diminuer la taille de la JVM en ne packageant que les modules que vous avez besoin.
La JVM reste compatible avec les jars.
Attention créer des modules Java n’est pas si simple, car vous devez indiquer qu’elles sont les modules que vous utilisés, vous pouvez aussi indiquer ceux qui peuvent utiliser votre module. Ce n’est intéressant (a mon avis) que si vous voulez faire des runtimes avec juste les modules dont vous avez besoin.
JEP 282 : Le Linker Java « jlink » pour créer un runtime
Amélioration des performances du moteur JIT grâce au nouveau G9
JEP 250 : amélioration de la gestion des chaines dans la JVM sur environnement 64bits en optimisant l’usage de la mémoire.
JEP 280 : Modification de la génération de bytecode correspondant à la concaténation de chaine générée par javac. Cela afin de permettra de future optimisation sur la concaténation de chaine.
Maintenant elle permet de récupérer le PID du processus sans avoir à passer par du code spécifique lié au système d’exploitation hôtes :
System.out.println(Process.getCurrentPid());
Possibilité de lister les processus système au travers de la classe ProcessHandleméthode :
ProcessHandle.allProcesses();
Possibilité d’obtenir les informations du processus tel que le nom de la commande lancé, ses arguments, l’heure de début et le temps CPU Attention, ses informations sont facultatives et basées sur la disponibilité du système d’exploitation.
Possibilité d’obtenir les informations sur les enfants d’un processus, direct et indirect
Et le mécanisme de sécurité Java peut permettre ou interdire l’accès à « ProcessHandles »
Ajout de deux options à l’annotation @Deprecated : « forRemoval » et « since« .
Exemple : @Deprecated(forRemoval=true)
Vous pouvez utiliser les ’annotations @SuppressWarnings("removal") ou @SuppressWarnings({"deprecation", "removal"}) » pour éviter les messages de compilation correspondante
Dépréciation des applets
Dépréciation de Corba
Dépréciation des Interfaces Observer et Observable. A la place, utiliser les classes de « Java.util.concurrent » telles que les files d’attente (queues) ou les sémaphores (semaphores ) pour transmettre des messages entre threads.
Dépréciation des méthodes suivante :
Boolean(boolean) ,Boolean(String)
Byte(byte), Byte(String)
Character(char), Double(double)
Double(String), Float(float)
Float(double), Float(String)
Integer(int), Integer(String)
Long(long), Long(String)
Short(short), Short(String)
Les remplacer par leur équivalent « .valueOf(..) » ou « parse() » de la classe correspondante (ex Boolean.valueOf(true)
Cette nouvelle méthode « Thread.onSpinWait() » permet d’effectuer des boucles d’attentes en consommant le moins de temps CPU (et d’énergie) dans le cadre ou il est possible d’effectuer des optimisations sur le processeur. Jusqu’à Java 8, nous utilisions un Thread.sleep(0) pour ne pas consommer tous le temps processeur dans cette boucle d’attente infinie (« spin loop« ). Or la méthode sleep() donner la main au processeur, ce qui pouvait générer des attentes (sleep/wait) supérieures à la milliseconde indiquée.
Donc, remplacer touts vos Thread.sleep(0) par Thread.onSpinWait() afin de fluidifier vos boucles attentes sans consommer.
Voici un exemple de code :
void waitMyEvent() {
while (!myEventIsOK) {
Thread.onSpinWait();
}
//Ici mon événement est OK, je sorts ....
}
Variables et méthodes Handle
Ajout de « Variable Handles » JEP 193. Je n’ai pas trop compris l’utilité, je vous convie donc à aller voir la note.
Amélioration des « Method Handles » JEP 274.
Amélioration des méthodes « MethodHandle »et « MethodHandles.Lookup » du paquetage java.lang.invoke afin de faciliter les cas d’utilisation courants et permettre au compilateur d’effectuer des optimisations.
Pratiquement tous les navigateurs modernes ne supporteront plus les applets Java (MS Edge, Chrome, Firefox).
Seules IE et Safarie les supporteront encore pour un certain temps. Et Chrome remplace cette technologie NPAPI par PPAPI (Pepper plugin API).
Oracle indique de remplacer les applets par WebStart.
Les classes correspondantes aux applets seront dépréciées dans le JDK Java 9, elles seront supprimées certainement dans Java 11 (pas Java 10).
Ajout du support des images multi-résolution (JEP 251)au travers de l’interface java.awt.image.MultiResolutionImage et des ses deux méthodes :
//retourne une image correspondant à la meilleure représentation de l'image pour la taille demandée en pixel
Image getResolutionVariant(float destImageWidth, float destImageHeight);
// retourne une liste des différentes variantes de l'image.
public List<Image> getResolutionVariants();
Ajout du support des images aux formats TIFFJEP 262 en standard sans avoir à utiliser une bibliothèque spécifique tel que JAI.
La nouvelle API se trouve dans javax.imageio.plugins.tiff.
Il en est de même pour le support des metada XML du TIFF, avec une classe similaire .
En résumé, Java 9 supporte nativement les formats image suivant PNG, JPEG et TIFF.
Une API pour mieux accéder aux spécifications du bureau du système d’exploitation (icône application,Intégration du Dock, l’écran passe en veille) JEP 272.
Ces nouvelles méthodes sont intégrées dans la classe java.awt.desktop.
Pour plus d’information, aller voir sa documentation : http://download.java.net/java/jdk9/docs/api/java/awt/desktop/package-summary.html
Interface graphique : JavaFX
Préparation de JavaFX (API de contrôle UI et CSS) à la modularisation JEP 253.
Intégration de la nouvelle classe GStream dans le module média de JavaFXJEP 257
Suppression des outils de diagnostic « hprof » JEP 240 et « jhat » JEP 241, car il existe d’autres outils bien plus performants .
Essayer l’outil jVisualVM (BRUNO mettre lien)
Options de la JVM
JEP 214 : Suppression de combinaison précédemment déprecated dans le JDK 8
Mise à jour des environnements Java par Oracle : JDK 8u101, JRE 8u102, JDK et JRE ARM 8u101, JRE 7u111, JRE 6u121.
Ils contiennent essentiellement des correctifs du type ...
Eclipse Neon est sortie il y a quelque jour. L'équipe de développent a fait de sérieux effort pour rattraper son retard par rapport à d'autre IDE (InteliJ) ou éditeur texte (Atom, Sublime) en intégrant les dernières technologies du moment Docker, nodeJS, gulp, npm, JSON ...
Dans cette article vous trouverez la plupart des nouveauté de Eclipse Neon ...
Sur les systèmes de production qu'elle gère, la société Takipi a analysé 1 milliard d'erreurs Java soit 2,7 To de fichiers logs. Il en ressort que 10 types d'erreurs Java représentent 97% des logs d'erreurs !
Les 10 types d'erreurs sont ...
Le nouveau projet « Panama » (Paradis fiscal Java) de l’Open JDK a pour but d’offrir la possibilité d’intégrer du code natif (API) dans votre code Java.
Par code natif, je veux dire assembleur, appelle au API de votre système, ou bibliothèque (library, dll) comme le font les programmeurs C.
Bien sûr, c’est contre nature par rapport à la philosophie Java du « Run every where« , mais c’est son paradis fiscal du code.
Ce projet se base sur le JDK 9 de « Open JDK »
Les grosses fonctionnalités attendues sont :
Appelle aux fonctions native et accès aux données (voir JEP191).
C’est fonctionnalité qui permet d’inclure du code assembleur natif ! voir méthode : jdk.internal.panama.CodeSnippet.make()
possibilité de faire votre propre optimiser
Nouveaux « data layouts »
Des outils pour inclure des bibliothèques natives
Vous trouverez plus d’information sur les liens suivant :