Visiblement ça marche, sauf dans les cas tricky où il y a une imbrication de la détection des types au runtime. Je note aussi que pour tout ce qui est découverte du classpath au runtime (typiquement les drivers JDBC), il faut spécifier le nom de la classe du driver si elle est chargée via un Class.forName() (ce qui est toujours le cas en théorie).

Il ne me reste plus que deux questions en suspend avant de pouvoir passer entièrement sous GraalVM :

1) Comment fonctionne le classpath lorsque ce dernier contient un répertoire ? Le contenu est-il intégré à l'exécutable produit par GraalVM ou faut-il faire une bidouille ?

2) Comment fonctionne l'allocation mémoire avec un exécutable natif ? Avant, nous passions les options Xms et Xmx à la JVM mais celles-ci ont-elles encore une sens ?

Sinon les gains au démarrage sont encore plus impressionnant que ceux que j'avais obtenus il y a presque deux ans et l'API NIO est bien plus rapide que celle d'une JVM normale !

Le renouveau de la JVM est bel et bien en train de devenir plus rapide que Go sauf que la plateforme est riche (en termes de features proposées par le langage) et aussi polyglotte puisque GraalVM permet de traiter du Kotlin, du Scala, du R, du JavaScript, du Ruby, etc.

Si votre variable JAVA_HOME est égale à GRAALVM_HOME alors cette configuration Maven suffit :

<plugin>
    <groupId>com.oracle.substratevm</groupId>
    <artifactId>native-image-maven-plugin</artifactId>
    <version>1.0.0-rc14</version>
    <executions>
        <execution>
            <goals>
                <goal>native-image</goal>
            </goals>
            <phase>package</phase>
        </execution>
    </executions>
</plugin>

Le tuto est clair est simple :

• Installer un JDK 8 dans le path => easy
• Récupérer et installer kotlin-native dans le path => easy
• Lancer la commande kotlin-native -o my_exec my_files.kt

Et voilà