Attendez, en 2026, il y a encore des gens qui créent des éditeurs ? ok ...
Non, mais, en 2026, il y a encore des gens qui créent des éditeurs EN JAVA ? Alors ça c'est fort !
Parfois, on tombe sur du passé qui ressemble à du futur. Ici, une librairie Java basée sur OSGi pour faire de l'UPnP (donc de la diffusion de media). C'est rudement bien expliqué, et franchement convaincant, mais ça a déja 20 ans.
ArchUnit est très intéressant, mais j'achoppe toujours un peu sur la définition des tests.
Et je trouve, à première vue, que Taikai fournit une ergonomie un peu plus intéressante.
Strictland permet de faire du test façon golden record de messages de n'importe quel type. C'est malin.
Les concepts d'optiques, qui sont très peu compréhensibles, apportent dans le monde Java des outils qui simplifient bien la vie, en particulier pour muter des structures de données à base de records ou de beans.
Un intéressant outil pour détecter les incompatibilités entre différentes versions de librairies.
Picnic propose des extensions à error-prone, qui peuvent être intéressantes
Vu que je fais du Java, et que j'utilise Gnome, ça pourrait me donner des envies ... mais je pense que je le ferai plutôt en Rust)
J'adore l'idée, et elle est facilement applicable en Java.
Il y a plusieurs PUnit, attention !
Celui-ci est une extension à JUnit ajoutant la valdiation statistique de code. C'est évidement dédié aux LLM et autres systèmes non déterministes, mais ça peut être utile dans d'autres cas ...
Un autre TUI pour maven. Il semble qu'il ait été écrit par Claude (et risque donc d'être d'une qualité douteuse). Je connaissais déja mvnsh, et je trouve dommage (mais c'est typique du monde des développeurs "augmentés par LLM" qui préfèrent copier plutôt que contribuer) qu'il n'ait pas été étendu.
De très bons exemples d'amélioration de code (en Java) qui fournissent des gains très notables de performance. Je dois dire que je fais beaucoup trop l'erreur du String.format (parce que c'est quand même bien plus lisible).
JGiven est une proposition de BDD où on n'écrit que du Java. C'est intéressant, ça me donne bien envie de le tester ... Mais je ne suis pas sûr que ce soit compatilbe avec JUnit 5 ...
(merci Julien pour cet article)
Donc Maven 4 semble supporter des modules maven définis uniquement par les modules Java. Ca évite d'écrire des POMs, ce qui peut (ou pas) être cool. En y réfléchissant, je pense que ça ne va pas tant être utilisé que ça, puisqu'on a très souvent besoin de dépendances spécifiques par module maven, ce que ne semble pas permette cette méthode.
Un très bon guide de modernisation de Java, avec tous les patterns récents joliment démontrés.
Bon, j'ai toujours pensé que développer une application de bureau avec un frontend web et un backend dans un langage quelconque était une bêtise. Mais je tolérais cette idée pour le Javascript.
Krema, lui, utilise cette idée avec un backend Java. Et là, c'est bête, parce qu'en Java, il y a quand même tout un tas de façons bien plus intéressantes de développer une application.
En fait, le seul intérêt de ce genre d'approche, c'est de continuer à faire travailler les développeurs front ... Pas fou.
Ce projet ressemble à un outil qui génère correctement les tests depuis les specs ...
Bon, c'est vibe-codé, mais ça n'est pas le gros problème.
Le gros problème, c'est que c'était le but de BDD, il me semble ...
Un moteur de template qui semble intéressant.
Ca me donne envie de refaire du Swing
Oh ben dis donc ! Je discutais récemment avec un collègue du fait que Swing permet des trucs incroyables, pour peu qu'on utilise le bon LnF. Et celui-ci a un look vraiment moderne. Il est même open-source, sous licence Apache