Antichesse (o ^ω^ o)
Cela faisait quelques temps que je me demandais quel ORM choisir pour remplacer ActiveJDBC car ce dernier est très bien mais je souhaitais un framework qui accentue d'avantage l'OOP.
D'ailleurs ActiveJDBC avait remplacé depuis bientôt 5 ans maintenant Hibernate & OpenJPA chez moi, car eux-mêmes étaient beaucoup trop orientés procédurale (@Sweet clin d’œil à ce sujet) au point de rendre impossible de respecter le principe d'encapsulation et aussi parce que l'usage intensif de l'API réflexion par Hibernate ne permet pas la compilation en natif via GraalVM.
Bref, j'hésitais entre trois frameworks et je pense que je vais partir du Ktorm qui a une super doc, de bonnes performances et une façon très simple de requêter la base :
J'ai sorti Kuery car il n'est plus maintenu depuis trois ans et qu'il lui manque certaines fonctionnalités et j'ai aussi mis de côté Exposed car trop orienté fonctionnel et donc incitant à violer l'encapsulation à l'image d'Hibernate.
Bref Ktorm est dans le pipe.
Edit : voici un article complémentaire tiré de la documentation du projet OpenJDK sur le class-sharing de la JVM.
Précharger des classes pour démarrer une JVM plus vite. Je viens de faire le test avec Maven et ça a l'air de marcher un petit peu (mais le gain est négligeable lorsque l'on compare les temps de build à Gradle).
Toujours est-il que si cela peut apporter un peu de confort à certains, ou encore réduire les temps de démarrage des conteneurs, alors ça vaut le coup.
Merci à @Philou pour le lien.
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
Je cite :
Tape is a collection of queue-related classes for Android and Java.
QueueFile is a lightning-fast, transactional, file-based FIFO. Addition and removal from an instance is an O(1) operation and is atomic. Writes are synchronous; data will be written to disk before an operation returns. The underlying file is structured to survive process and even system crashes and if an I/O exception is thrown during a mutating change, the change is aborted.
Whaouuu. @Lenny qui poste des liens de ouf dans des tickets mais qui ne les reposte pas sur le cozo ! Bref un très bon article arguant sur les getter et setter en Java.
L'article est d'Allen Holub à ranger à côté de ceux de Yegor Bougayenko.
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.