Antichesse (o ^ω^ o)
Visiblement ça marche, sauf dans les cas tricky où il y a une imbrication de la détection des types au runtime. Je note aussi que pour tout ce qui est découverte du classpath au runtime (typiquement les drivers JDBC), il faut spécifier le nom de la classe du driver si elle est chargée via un Class.forName() (ce qui est toujours le cas en théorie).
Il ne me reste plus que deux questions en suspend avant de pouvoir passer entièrement sous GraalVM :
1) Comment fonctionne le classpath lorsque ce dernier contient un répertoire ? Le contenu est-il intégré à l'exécutable produit par GraalVM ou faut-il faire une bidouille ?
2) Comment fonctionne l'allocation mémoire avec un exécutable natif ? Avant, nous passions les options Xms et Xmx à la JVM mais celles-ci ont-elles encore une sens ?
Sinon les gains au démarrage sont encore plus impressionnant que ceux que j'avais obtenus il y a presque deux ans et l'API NIO est bien plus rapide que celle d'une JVM normale !
Le renouveau de la JVM est bel et bien en train de devenir plus rapide que Go sauf que la plateforme est riche (en termes de features proposées par le langage) et aussi polyglotte puisque GraalVM permet de traiter du Kotlin, du Scala, du R, du JavaScript, du Ruby, etc.
Concept :
- Vous démarrez une
main()vide (enfin qui contient juste le point suivant). - Vous charger un class-loader dynamique qui lui va charger vos JARS ou les répertoires de vos classes directement.
- A chaque mise à jour de ces fichiers, les classes et ressources du classpath seront rechargées à chaud dans l'espace mémoire de la JVM.
Je vais me coder une petite lib qui va se charger de charger l'application à la place de la main() et permettre les démarrages à chaud. #Luv
Quel travail de Netflix pour améliorer leur gestion de JVM ! C'est vraiment une boite de techs !
Une comparaison avancée du mode natif vs jvm de Quarkus. Le benchmark est intéressant.
Un outil en licence MIT permettant de monitorer des JVM.
Je regarderai cela plus tard !
Principe :
- Vous installez le serveur Glowroot quelque part.
- Sur vos serveurs de production, vous ajoutez un agent Java à la ligne de commande de démarrage de vos JVM.
- Vous n'oubliez pas de faire pointer votre agent Java vers vos serveur Glowroot.
=> Vous obtenez automatiquement un système de monitoring. GG
D'autre systèmes :
Merci encore une fois à Philou pour le lien (tu es en train de devenir ma nouvelle source de merveilles techniques).
A curated list of awesome frameworks, libraries and software for the Java programming language.
Une liste gigantesque reprenant un par un les différents frameworks s'exécutant sur JVM.
Une explication datant de 2017 et expliquant quoi utiliser pour le chiffrement sue JVM.
Les différents types de memory leaks et les patterns de memory consumption pour les détecter et les identifier.
MySQL conseil d'utiliser le type DATETIME pour stocker des dates, mais côté JVM quel est le type de données à utiliser ? Je résume ici la réponse :
- java.sql.Date permet de stocker une date mais sans l'heure.
- java.sql.Time permet de stocker l'heure mais sans la date.
- java.sql.Timestamp permet de stocker les deux.
Donc le type qui se rapproche le plus de DATETIME c'est java.sql.Timestamp.
Edit : et côté MySQL, que se passe-t-il ?
MySQL dispose de quatre types pour stocker les données temporelles :
- DATE pour stocker une date mais sans l'heure.
- TIME pour stocker une heure mais sans la date.
- DATETIME pour stocker un timestamp allant de 1000-01-01 00:00:00.000000 à 9999-12-31 23:59:59.999999.
- TIMESTAMP pour stocker un timestamp au format UTC allant de 1970-01-01 00:00:01 UTC à 2038-01-19 03:14:07 UTC.
Donc côté base de données vous êtes dans deux cas de figure qui ont eux-mêmes des sous-cas :
- Soit votre SI est mono-timezone et dans ce cas là, DATETIME vous accorde une plage de données plus large.
- Soit votre SI est multi-timezone (comme chez mon client actuel) et dans ce cas là vous avez deux sous-cas :
- Soit vous gérez la timezone côté serveur (Kotlin / Rust par exemple) => DATETIME.
- Soit vous gérez la timezone côté base et vous lui passez uniquement des timestamp UTC => TIMEZONE.
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.
Et ce lien vers le même site qui parle aussi des changements apportés par Java 8 au niveau de la JVM.
This post is the second in a series. While I have worked for about three years professionally in the realm of security and feel that I now...
Un super tuto expliquant le fonctionnement d'une JVM et toutes les manières de l'optimiser via du tuning :
Pour toi Animal, chose dont nous parlions il y a quelques temps.
Une courte intro sur les "profile" de Java 8. Je suis complètement passé à côté de la techno. A regarder pour améliorer les perfs
Un autre lien peut-être un peu plus clair sur les profiles : vitaflux
Un lien vers une doc NetBeans intégrant les Java 8 Compact profiles : Oracle NetBeans
Un autre lien vers la doc Oracle : Doc Oracle
La page Oracle contenant une bonne partie des options que l'on peut passer à une JVM HotSpot.
Nous en discutions avec Animal dans le train ce matin. Une JVM bien configurée permet de faire jusqu'à un fois10 en termes de performances. Cependant, les entreprises négliges systématiquement ces options.
En lien, la documentation officielle d'Oracle à ce sujet.