Antichesse (o ^ω^ o)
Résumé
IntelliJ instrumente du code juste pour lui lorsqu'il exécute des TU.
Ce faisant, l'annotation @NotNull apposée sur un paramètre produit un NullPointerException lorsque c'est Java ou Maven (via Surefire lors des TU) qui exécute la fonction en lui passant un null mais elle produit un IllegalArgumentException lorsque c'est IntelliJ qui exécute la même fonction avec le même null passé en paramètre.
Solution
Désactiver le paramètre "Add runtime assertions for not-null-annotated methods and parameters" dans le menu Setting > Build > Compiler
Encore une très bonne nouvelle pour Kotlin ! Le fait d'avoir une fondation à part, disposant d'un modèle économique clair et qui assure au langage sa survit et mieux encore son évolution est ce qu'il fallait faire.
Le parfait contre-exemple que je pourrais donner est ce qu'a fait la fondation Apache avec Maven dans le sens où Apache étant "anti-argent", la fondation a toujours refusé que des contributeurs majeurs de Maven mettent en place un modèle économique de financement de leurs contributions. 15 ans plus tard, le projet n'a qu'une mise à jour tous les 18 mois... Heureusement, des forks sont apparus comme Maven Daemon mais cela fragmente le marché.
Bref, je suis très contente pour Kotlin.
Ok je suis convaincue. Je passe sous la police de caractère JetBrains Mono dans la journée.
En test rapide, la lecture est incroyablement plus rapide et agréable.
Un post intéressant sur les annotations JetBrains pour exposer le contrat d'une méthode (cf. programmation par contrat, JML). Si ces annotations peuvent servir à du code Kotlin pour plus facilement recevoir des données provenant d'un code Java, alors je pense que cela peut être une excellente idée de les utiliser afin d'avoir un code Java qui soit Kotlin friendly.
Le lien vers la doc officielle.