Antichesse (o ^ω^ o)
Merci @Animal. J'avais déjà cette option de décochée. Depuis mon problème est que les property access syntaxes s'affichent encore dans l'auto-complétion sauf à faire deux CTRL + ESPACE... Et qu'ils s'affichent à la place des appels normaux.
Mon besoin est donc de les faire disparaître de cette liste. Or, même en activant l'apprentissage des styles d'auto-complétion par machine learning, impossible de les virer. Cela semble être un truc hard-codé dans l'outil que l'accès à une méthode doit d'abord être proposé comme à accès à un attribut.
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
@Animal : l'emplacement du fichier de conf ide.general.xml d'IntelliJ IDEA a changé depuis la dernière version de l'outil (ie. la 2020.1). Pour rappel, ce fichier contient un paramétrage permettant de ne plus ouvrir automatiquement au démarrage le dernier projet sur lequel quelqu'un a travaillé.
Ce fichier se trouve à présent à cet emplacement : ~/.config/JetBrains/IdeaIC2020.1/options/ide.general.xml. Tu noteras que le répertoire de configuration de l'IDE se trouve à présent dans ~/.config ce qui utilise enfin la norme des bureaux Linux à base de GTK (Gnome / Mate / Cinnamon).
Évidemment, il faut toujours lui ajouter la ligne <option name="reopenLastProject" value="false" />, me concernant ça donne ceci :
<application>
<component name="GeneralSettings">
<option name="confirmExit" value="false" />
<option name="reopenLastProject" value="false" />
<option name="showTipsOnStartup" value="false" />
</component>
</application>Voilà
Cela avait le don de me frustrer qu'une feature aussi standard ne soit toujours pas implémentée dans un IDE qui sait le faire dans d'autres langages depuis des années. Et après une courte recherche, il y a une raison plus que pertinente : l'ordre des imports en Kotlin influe sur la façon dont le code sera compilé.
Dit autrement, pour une même classe, ordonnancer ses imports différemment ne produira pas le même bytecode. De ce fait, j'ai désactivé le check dans Ktlint pour éviter tout problème.
P.S : IntelliJ semble importer les éléments "dans le bon ordre par défaut".
Bon, je vais résumer ce qui me fruste au plus au point (avec le contournement qui va bien).
A chaque fois que j'utilise la commande refactor d'IntelliJ ce crétin effectue un search & replace dans tous les fichiers possibles, dans toutes les extensions possibles et me demande de cocher "pas à pas" ce que je souhaite renommer/refactorer.
Or, quand je fais un CTRL + R (oui j'utilise les shortcut mappings de Netbeans sur IntelliJ => RAF) c'est que je suis en train de coder. Du coup si je sélectionne un paramètre d'une méthode, je veux qu'il détecte le foutu scope de mon paramètre et qu'il me renomme automatiquement :
- le paramètre en interne,
- la javadoc associée,
- et c'est tout !
Bref, NetBeans le faisait de base depuis 2010 c'est donc très très très très très moche (je vous ai dit que c'était très moche ?). Je trouve que cette "feature" est une pure et simple counter-feature.
Heureusement, comme je suis bienveillante voici la solution :
- Positionnez-vous sur votre variable à renommer.
- Lancer la commande de refactor (pour moi CTRL+R).
- Commencez à taper un nouveau nom.
- Refaites le shortcut (toujours CTRL+R pour moi).
- Décochez la case "Search in comments and strings"
- Validez votre refacto
Dorénavant tous vos refactos ne vous embêteront plus !
Voici les étapes à suivre :
- Sélectionnez le module Maven dans l'encradé Project.
- Puis dans le menu principale aller dans Run > Edit Configurations...
- Dans la colonne de gauche, choisissez votre framework (dans mon cas c'est Default > TestNG).
- Dans l'encadré à droite, en bas, intitulé : "Before launch, Maven goal, Activate tool window" ajoutez le goal suivant en dessous du build :
org.javalite:activejdbc-instrumentation:2.0:instrument - Appliquer et voilà.
Aparté
Il y a trois choses qui manquent cruellement à NetBeans à mon sens par rapport à IntelliJ :
1) Une meilleure intégration de Kotlin.
Je précise ma pensée :
- La coloration syntaxique custom en Kotlin qui saute après chaque reboot (c'est quand même la loose).
- Le fait que l'IDE ne parvienne pas à importer les classes d'un module Maven Kotlin depuis un module Maven Java (seconde loose).
2) Pas de plugin Infinitest (troisième loose)
3) La smart completion d'IntelliJ
Vu que j'ai besoin de Kotlin en ce moment et d'infinitest, bah IntelliJ du coup !
Faudra que je parle des pours des contres de chacun de ces deux IDE, parce que NetBeans est quand même beaucoup plus rapide qu'IntelliJ, l'intégration Maven est carrément meilleure (mais je veux dire vraiment) et les commandes de refactoring automatiques sont plus efficaces, il est mieux intégré aux plateformes d'intégration continue, sa gestion de Docker et d'Ansible, etc. Bref vous m'avez comprise.