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

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++).

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.

A lire pour plus tard.

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 :

1. L'encapsulation.
2. Le polymorphisme.
3. 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...

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.

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

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.

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.

Pour les prochains dojos que je dois préparer avec Bichon en septembre !