Un framework de test de mutation pour JRE, donc qui marche avec Kotlin et Java.
Très simple :
- Vous installez GraalVM en tant que JAVA_HOME.
- Vous installez native-image dans GraalVM via la commande
gu install native-image
. - Vous installer les GCC + build-essential :
sudo apt install gcc build-essential
- Vous ajoutez le plugin Maven dans votre projet.
Enjoy :D
Parser des fichiers CSV avec la lib OpenCSV en Java et en Kotlin.
Extrait du petit code qui va bien pour une lecture de trèèèès gros fichiers :
try (CSVReader reader = new CSVReader(new FileReader("file.csv"))) {
String[] lineInArray;
while ((lineInArray = reader.readNext()) != null) {
System.out.println(lineInArray[0] + lineInArray[1] + "etc...");
}
}
Cela fait pas mal d'années que je cherche un serveur web à embarquer dans mes applications à destination d'une JRE (Java Runtime Environment) et qui soit :
- Léger, quelques Ko maximum.
- Rapide à démarrer, quelques millisecondes maximum.
- Perfomant, qui encaisse une charge de plusieurs dizaines de milliers de requêtes par secondes sur mon core I5.
- Asynchrone, pour tirer partie du multithread.
- Compilable nativement, via Kotlin Native ou GraalVM.
- Ayant une syntaxe avec et surtout sans annotations, car la réflexion du code rend compliqué la compilation native.
- Libre, gratuit et interropérable.
- Présent dans le répo Maven Central.
- Modulaire, si j'ai besoin du routing alors je ne veux embarquer que les jars dédiés au routing.
Jooby répond à toutes ces conditions. Donc après avoir utilisé Glassfish (outch), Tomcat, Websphere (hur), Jonas (damned), Weblogic (hur again), Jetty, Sparkjava, Undertow, Javalin, Rapidoid et dernièrement Netty, je pense que je vais migrer vers Jooby qui en plus a de meilleures performances que les autres (d'un facteur 2 par rapport à son meilleur challenger, il est même au niveau des serveurs à destination du C++).
Dans la même veine que mon poste précédente et avec les mêmes remarques concernant la sécurité.
Tout est dans le titre.
Attention à l'extraction de fichiers dont le chemin dans l'archive sont des chemins absolus ! Si c'est root qui décompresse, il est alors possible d'écraser le /etc/profile
par exemple, voir modifier des démons gérés par systemctl
et compromettre le système.
Bref, toujours concaténer le répertoire de décompression en début de chemin du fichier.
Une page proposant tous les anciens JDK à télécharger.
Via Kalvn qui poste toujours des trucs qui me sont incroyablement utiles ! Thanks a lot :D
A lire pour plus tard.
Les nouveautés de Java 15 pour @Animal et @Doudou.
Merci à @Philou pour lien.
Pour @Lenny et @Kysofer qui doivent se servir de Netty.
EDIT 5: un cinquière tuto ici.
EDIT 4 : un quatrième tuto ici.
EDIT 3 : un troisième tuto ici.
EDIT 2 : un deuxième tuto ici.
EDIT : je viens de tomber sur ce tuto et quand je lis ce genre de code :
import io.netty.channel.ChannelHandlerContext;
import io.netty.channel.ChannelInboundHandlerAdapter;
import io.netty.handler.codec.http.websocketx.BinaryWebSocketFrame;
import io.netty.handler.codec.http.websocketx.CloseWebSocketFrame;
import io.netty.handler.codec.http.websocketx.PingWebSocketFrame;
import io.netty.handler.codec.http.websocketx.PongWebSocketFrame;
import io.netty.handler.codec.http.websocketx.TextWebSocketFrame;
import io.netty.handler.codec.http.websocketx.WebSocketFrame;
public class WebSocketHandler extends ChannelInboundHandlerAdapter {
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) {
if (msg instanceof WebSocketFrame) {
System.out.println("This is a WebSocket frame");
System.out.println("Client Channel : " + ctx.channel());
if (msg instanceof BinaryWebSocketFrame) {
System.out.println("BinaryWebSocketFrame Received : ");
System.out.println(((BinaryWebSocketFrame) msg).content());
} else if (msg instanceof TextWebSocketFrame) {
System.out.println("TextWebSocketFrame Received : ");
ctx.channel().writeAndFlush(
new TextWebSocketFrame("Message recieved : " + ((TextWebSocketFrame) msg).text()));
System.out.println(((TextWebSocketFrame) msg).text());
} else if (msg instanceof PingWebSocketFrame) {
System.out.println("PingWebSocketFrame Received : ");
System.out.println(((PingWebSocketFrame) msg).content());
} else if (msg instanceof PongWebSocketFrame) {
System.out.println("PongWebSocketFrame Received : ");
System.out.println(((PongWebSocketFrame) msg).content());
} else if (msg instanceof CloseWebSocketFrame) {
System.out.println("CloseWebSocketFrame Received : ");
System.out.println("ReasonText :" + ((CloseWebSocketFrame) msg).reasonText());
System.out.println("StatusCode : " + ((CloseWebSocketFrame) msg).statusCode());
} else {
System.out.println("Unsupported WebSocketFrame");
}
}
}
}
J'ai juste envie de pleurer (et je vais vous expliquer pourquoi). La programmation orientée objets reposent sur trois principes :
- L'encapsulation.
- Le polymorphisme.
- L'héritage (mais il faut l'oublier car c'est un anti-pattern).
Le polymorphisme, c'est le fait qu'une classe fille puisse se faire passer pour sa classe mère. L'idée étant que l'on doit organiser notre code de telle sorte que nous puissions TOUJOURS utiliser les super-types (classe mère abstraite ou interface). Or dès que l'on doit ajouter des conditions du type truc instanceof Class
c'est que l'on passe à côté du principale intérêt du polymorphisme : ne jamais avoir besoin de dépendre des implémentations.
Soyons clair, dans un code orienté objet je n'ai jamais eu besoin d'écrire des instanceof
et de toute ma vie, ce n'a dû m'arriver qu'une ou deux fois et parce que je dépendais d'un code aussi vieux que Java lui-même !
Bref, si vous codez en Java et que vous avez besoin des implémentations, pis encore des instanceof
et des casts, alors c'est que vous pensez en procédural et non en objet. Et pour tout ceux qui souhaitent apprendre à penser en objet, je les renvoie aux formations de Kysofer (car il m'a promis une com' si vous y aller de ma part :D) et il y a la pré-collection automne de Sezane qui me fait grave de l’œil si vous voulez...
Tout est dit ! Et j'adore Kotlin c'est vous dire. Mais je préfère me tirer une balle que de faire du annotation-driven-development avec un java-procedural-spring-singleton-base programming.
Si je disais précédemment que la PF pure était un cancer, alors Spring et ce mode de programmation est un cancer metastasé !
Merci à @Philou qui me comprends et qui m'a offert ce lien.
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 !