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
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.
Comme ça faisait un moment que je n'avais pas créé des beans à la main (et utilisé Spring Context aussi), je me le note au cas où ça se reproduirait.
Voici le diagramme résumé
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.
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.
Je viens de découvrir que JPA vous permet d'annoter les méthodes de vos entités (avec des annotations particulières), afin de les exécuter durant le cycle de vie de leur enregistrement :
- @javax.persistence.PrePersist
- @javax.persistence.PreRemove
- @javax.persistence.PreUpdate
- @javax.persistence.PostLoad
- @javax.persistence.PostPersist
- @javax.persistence.PostRemove
- @javax.persistence.PostUpdate
Je trouve que c'est une très bonne idée car cela peut être pratique, mais c'est aussi terrible car cela ajoute de la complexité à quelque chose comme Hibernate qui est trèèèèèèèèès loin d'être un framework simple à la prise en main.
Add a @KnownIssue annotation for TestNg tests that already have a related bug on Jira, and they will be skipped until it is resolved.
La communauté TestNG est prodigieuse. Le principe est le suivant :
- Lorsque vous avez un bug vous créez un ticket et un test reproduisant ce bug.
- Tant que le ticket est ouvert, le test - s'il échoue - ne plantera pas votre build.
- Si le test passe mais que le ticket est encore ouvert, alors le build va planter, vous forçant donc à fermer le ticket.
Cette annontation à ajouter en supplément du @Test vous garantira disposer d'un issues tracker toujours synchro avec l'état réel de votre code base.
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.
Pour Chlouchoutte. Toutes les petites annotations existantes en Kotlin et qui produisent un code Java-friendly. L'autre point intéressant de l'article est qu'il montre le code Java produit à partir du code Kotlin.
Un projet que vient de me montrer Aurélien et qui permet d'ajouter des annotations plus parlantes et dédiées au développeur dans le code du type : @WTF, @BossMadeMeDoIt, @IAmAwesome, @LegacySucks...
Il semble même que l'on puisse générer une JavaDoc à partir de ces annotations histoire de documenter techniquement la qualité interne et ressentie du code.
Autant utile que drôle !