Tout est dans le titre. Je suis en train de comparer plusieurs choses actuellement :

1. Le surcoût que représente la JRE 17 sur une application Kotlin.

2. Le gain qu'apporte une JRE 17 custom produite à l'aide de l'utilitaire JLink.

3. Les performances de (1) et (2) face à la même application codée en Rust, en termes de consommation mémoire et d'opérations par seconde.

4. Les nouvelles options que la JRE prends en paramètre et leurs effets sur le CPU, la mémoire et le débit.

Le tuning de JRE a toujours été compliqué, mais pour obtenir une JRE de 30 Mo optimisée comme il faut, il y a encore plus de choses à connaître et comprendre qu'avant. Damned !

Alors la situation est un poil plus compliquée que ce qui est dit.

Sur les vieilles versions de Java, Oracle fait effectivement la chasse aux licences. Mais il s'agit d'un modèle privateur donc normal.

Sur les versions 8 à 19 de Java, le modèle est basé sur trois composantes. Une JVM (machine virtuelle Java) avec les dernières features, une JVM avec les derniers correctifs de stabilité ou de sécurité, une JVM gratuite.

Quelle est l'astuce ? Simple, on ne peut pas avoir ces trois composantes simultanément.

C'est-à-dire que soit on veut avoir les dernières features et être stable/securisé et alors on paie.

Soit on ne paie pas mais dans ce cas on a :

• Soit les dernières features sur une JVM instable/non-sécurisée
• Soit on a une JVM avec 3 ans de retard sur les features mais qui est gratuite et stable/sécurisée.

Enfin, rappellons que Java est libre (GPLv2) et que les projets Eclipse Temurin, Apache et OpenJDK ont fusionné pour donner naissance à une JVM 100% libre Adoptium. Donc bye bye Oracle.

Remarque : si vous codez en Kotlin, puisque le compilateur peut cibler la version de la JVM que vous utilisez et vous fournir les dernières features sans que la JVM ne soit a jour, alors autant partir sur la dernière LTS gratuite de Java et être tranquille côté sécurité / stabilité.

Sinon Kotlin se compile très bien en WASM et en natif aussi <3

En un exemple court et simple :

package com.memorynotfound;

import java.lang.management.ManagementFactory;
import java.lang.management.RuntimeMXBean;

public class GetUpTime {

    public static void main(String... args) throws InterruptedException {
        RuntimeMXBean rb = ManagementFactory.getRuntimeMXBean();
        System.out.println("Up time: " + rb.getUptime() + " ms");
    }

}

Voici le résumé :

• all to suppress all warnings
• boxing to suppress warnings relative to boxing/unboxing operations
• cast to suppress warnings relative to cast operations
• dep-ann to suppress warnings relative to deprecated annotation
• deprecation to suppress warnings relative to deprecation
• fallthrough to suppress warnings relative to missing breaks in switch statements
• finally to suppress warnings relative to finally block that don’t return
• hiding to suppress warnings relative to locals that hide variable
• incomplete-switch to suppress warnings relative to missing entries in a switch statement (enum case)
• nls to suppress warnings relative to non-nls string literals
• null to suppress warnings relative to null analysis
• rawtypes to suppress warnings relative to un-specific types when using generics on class params
• restriction to suppress warnings relative to usage of discouraged or forbidden references
• serial to suppress warnings relative to missing serialVersionUID field for a serializable class
• static-access to suppress warnings relative to incorrect static access
• synthetic-access to suppress warnings relative to unoptimized access from inner classes
• unchecked to suppress warnings relative to unchecked operations
• unqualified-field-access to suppress warnings relative to field access unqualified
• unused to suppress warnings relative to unused code
• varargs to suppress warnings about unsafe usages of variable arguments (varargs) methods, in particular, those that contain non-reifiable arguments.

Merci à Riduidel pour le lien.

Houla je confirme !! Feather est ultra rapide et ultra petite (12 Ko).

Grâce à cette lib, j'ai abandonné tous les autres frameworks de DI, allant de Spring jusqu'à Dagger II, en passant par Guice.

Cela doit faire 4-5 ans et elle ne m'a jamais deçue.

Depuis Java 11, certains packages comme javax.xml.bind ne font plus partie du JDK, ce faisant il faut les tirer en tant que dépendances soi-même.

Pour faire simple toutes les dépendances du type javax sont remplacées par des dépendances du type Jakarta, par exemple :

<dependency>
  <groupId>javax.xml.bind</groupId>
  <artifactId>jaxb-api</artifactId>
  <version>2.3.0</version>
</dependency>

devient

<!-- Pour JEE 8 -->
<dependency>
  <groupId>jakarta.xml.bind</groupId>
  <artifactId>jakarta.xml.bind-api</artifactId>
  <version>2.3.3</version>
</dependency>

<!-- Pour JEE 9 -->
<dependency>
  <groupId>jakarta.xml.bind</groupId>
  <artifactId>jakarta.xml.bind-api</artifactId>
  <version>3.0.0</version>
</dependency>

Excellente idée ! Merci à @Philou pour le lien.

Je suis bluffée ! Les filters des Stream sont toujours plus lents que les boucles classiques en Java.

Le seul moment où les boucles classiques ne sont pas les plus rapides, c'est dans le cas de figure où la taille des collections dépasse les 500 K éléments et que les Parallel Stream sont utilisées à la place des Stream (et que nous sommes sur une architecture multi-cœurs évidemment) ; sinon les Stream perdent à chaque fois.

@Riduidel : la réponse à ta question est dans ce post (un peu long à lire désolée).

Un objet Iterable implique que l'on traite les données à partir d'un paradigme de programmation procédurale et impératif, c'est-à-dire ni objet, ni fonctionnel. Or les Optionals sont justement des éléments prévus spécialement pour penser et coder dans un style fonctionnel parmi les plus purs.

Vouloir que la classe Optional implémente Itérable, c'est un marqueur fort permettant d'identifier qu'une personne n'a pas encore appris et compris le paradigme fonctionnel où :

• Les instructions if/else/switch ont été remplacés par du pattern-matching.
• Les boucles for/while/do-while ont été remplacées par des appels récursifs.
• Les références ont été remplacées par des lambdas.

Enfin, le fait que Scala ait implémenté Iterable dans les Optionals est justement ce qui fait de Scala un mauvais langage fonctionnel à mon avis, car si c'est génial d'être multi-paradigme, c'est par contre très mal de mélanger les paradigmes dans les éléments constituants l'API du langage car cela créé un code extrêmement incohérent où il devient difficile de savoir comment s'exprimer ; mais c'est mon côté software craftswomanship qui parle #JavaDuchesses