Spoiler de l'article : Kotlin gagne quasiment partout.
Par contre Kotlin n'est pas que pour Android mais aussi pour tout ce qui cible la JVM ou la compilation du byte-code de JVM en natif. Chez nous il est côté serveur depuis plus de deux ans maintenant et a TOTALEMENT REMPLACÉ JAVA !
L'idée n'est pas mal : vous ajoutez des annotations dans votre code Java et un processeur d'annotations piloté par un plugin Maven va générer pour vous la configuration Kubernetes de votre application. Etant donné que je n'aime pas trop m'embêter avec Kubernetes (je n'arrive plus à apprendre toutes les technos de la terre, surtout les technos ops, elles sont en train de me tuer), j'apprécie d'autant plus cette initiative.
Via Riduidel.
Il est très difficile de créer des builds reproductibles en Java via Maven / Gradle & Co. Cette très courte présentation explique bien pourquoi.
Heureusement, il existe un plugin maven permettant de virer les timestamps et les méta-data pour rendre le build reproductible à l'octet près.
Encore une fois, merci à @Philou pour l'info.
Pour les prochains dojos que je dois préparer avec Bichon en septembre !
Un tuto qui introduit plein de manières de créer son parser/lexer en Java à partir d'une quinzaine de frameworks différents.
GraphQL est une alternative très sérieuse à RESTful. Ce qui me pose encore problème pour l'adopter définitivement c'est la carence en frameworks afin de parser/lexer les requêtes reçues via HTTP et d'en assurer le mapping côté base de données.
Ici GraphQL Java apporte une première pierre à cet édifice avec un exemple d'implémentation simple mais concret.
Ceux qui me lisent le savent, je trouve que Rust est un très bon langage mais je lui reproche quand même certaines choses :
- Il n'est pas trivial d'écrire des classes (comme il l'est en Kotlin).
- Le code à écrire est aussi volumineux que celui de Java (Kotlin est 30% à 40% plus concis).
- Il utilise autant d'abréviations stupides que C++.
- Certains éléments de syntaxe sont une immondice à mi chemin entre C++ et O-Caml/Ruby (typiquement le pipe "|" pour les lambas, en dix ans je n'ai jamais pu m'y faire, ou encore l'opérateur "->" pour définir un type de retour d'une fonction).
Mon langage préféré serait à 100% Kotlin si celui-ci disposait :
- D'une cross-compilation native.
- D'un garbage collector injecté au compile-time à l'image de Rust et l'emploi du Ownership.
Oui, c'est ce qu'il faudrait à Kotlin, j'ai vraiment hâte de voir ce que vont donner GraalVM et Kotlin native dans les prochains mois.
Via Riduidel
Je regarderai cela plus tard !
Convertir un flux XML SOAP dans un POJO / Entité.
P#*$.? nous sommes en 2019 et mes clients font encore du SOAP et ça parle Java 7, portlet et Weblogic (T_T)... J'ai vraiment besoin de thunes pour encaisser ça. #MaVieDeFreelance
Un tuto en français sur les modules de Java 9.
L'avenir de Java est au natif et à la compilation AOT. Je surveille GraalVM depuis presque une année et j'ai déjà fait des présentations dessus. Autant vous dire qu'avec ma migration vers Kotlin, j'attends la première release de GraalVM avec impatience.
Un lien vers la page de Quarkus.
Merci à @Lenny pour ton thread sur imgur.
Je n'ai pas tout lu dans le sens où je suis partie sur Kotlin il y a plus de deux ans maintenant #Coroutines. Mais c'est toujours bon de maîtriser les principes sous-jacents de la JVM.
Sooooooooooooooo true ! J'ai ris.
Modernizer permet de détecter l'emploi des éléments obsolètes de l'API Java en fonction de la version de la JVM ciblée.
Typiquement, avec Vector, le plugin pètera une erreur pour Java 1.2 et plus, mais pas pour Java 1.0 et 1.1.
JDK8 AES-GCM code example. GitHub Gist: instantly share code, notes, and snippets.
Java, RSA et AES
Pour Chlouchloutte. Mais la comparaison n'est pas daté...
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
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 !