Après investigation, ton problème est dû à la cross-compilation entre deux versions du JDK.

Explications

Tu essaies de compiler des sources Java en syntaxe 8 pour qu'elles soient compilées dans un bytecode dont le format sera à destination d'une JRE 8.

Or, tu opères cette compilation depuis un JDK 10. Que se passe-t-il alors ?

Simplement que le compilateur t'avertie que la JRE 8 a une certaine API et que ton JDK 10 contient l'API 8 + toutes les classes qui ont été ajoutées dans Java 9 et 10. Ce faisant, si tu venais à utiliser une classe n'existant que dans Java 10, alors même si le bytecode que le compilateur produit à partir de tes sources est à destination de Java 8, tu ne pourras pas lancer ton programme et tu auras une ClassNotFoundException.

Le JDK 10 ne pouvant pas savoir quelles classes ne se trouvent que dans Java 10, il te demande un bootstrap classpath, c'est-à-dire un chemin vers le fichier rt.jar d'un JDK 8, afin de ne te permettre de n'utiliser que des classes de l'API de Java 8 dans ton code.

Ainsi, le JDK 10 n'utilisera plus son rt.jar à lui qui est trop récent, mais l'ancien.

Solution

Ajouter dans la configuration du maven-compiler-plugin l'option et lui passer le paramètre -bootclasspath $JRE8_HOME/lib/rt.jar.

Il faut aussi que la variable $JRE8_HOME soit définie dans ton OS.

Et voilà.

N.B : en ce qui concerne les modules de Java 9, c'était une fausse piste, mea maxima culpa !

Les différents types de memory leaks et les patterns de memory consumption pour les détecter et les identifier.

Une appli écrite en 4 fois en :

• Java
• Groovy
• Kotlin
• Scala

La comparaison du readme est très appréciée.

Apparemment, Log4j2 utiliser l'API I/O asynchone de Java8 ce qui le rendrait plus rapide que logback. L'article dresse une comparaison de ces deux frameworks.

Edit : Une fois que la file asynchrone de log4j2 est pleine, ses performances se dégradent bien en dessous de celles de logback.
Du tuning s'impose alors, source Stack Overflow.

Comme vous avez pu le constater, je me documente un peu sur le tuning JVM / MySQL / Linux en ce moment.

L'idée étant de faire simplement des choses simples. Cette page est assez complète et couvre bien les spectres I/O, memory usages, garbage collector, OS.

Exécuter du :

• Maven dependency check
• Findbugs
• PMD
• Checkstyle

Et d'autre en un seul plugin préconfiguré... Doudou ?

J'ai testé ce soir et ce fût un fail. Mais je recommancerai à partir de la première release. Je pense qu'une stack mixée entre Kotlin > bytecode > native peut devenir très intéressant. Et si on se rapproche des tailles d'occupation de la mémoire de Go pour des applications Java-like qui dispose de la même charge CPU, alors autant vous dire que je signe tout de suite !

Edit : j'ai retesté et GraalVM ne supporte pas les accents / espaces dans les chemins de fichiers (y compris celui où elle est installée). Bref ça marche bien et le gain en performance est miraculeux !

À partir de java 1.8u161 la limité est débloquée par défaut => Donc rien à faire.

Pour les versions antérieures et débloquer la limitation cryptographique des nouvelles JVM (à partir du JDK 1.8u151), il faut

Ouvrir le fichier $JRE_HOME/lib/security/java.security et y ajouter / modifier la ligne suivante :

crypto.policy=unlimited