Faut il migrer de Java vers Kotlin ?

C'est le côté "changer pour changer" qui m'embête... et encore... si un client voulait une application en ADA, je l'apprendrais volontiers

Je précise déjà que je ne t'attaquais pas personnellement, je précisais juste que je doute qu'un programmeur soit par nature fainéant et que ce soit ça qui motive son désir de changer ou non de langage: Surtout quand on voit à quelle vitesse l'informatique change, moi j'ai commencé en 1980. Sinon on peut trouver l'excuse de la paresse pour n'importe quel point de vue, c'est ce que j'ai voulu montrer.

Changer pour changer, c'est logique que ça t'embête, mais le fait est que Kotlin apporte un grand plus au niveau rigueur de programmation (notamment avec les nullables), du moins pour les versions antérieures de Java, qui sont celles utilisées dans Android (j'ai répondu au sondage posté dans le forum "Android"). En outre c'est un langage très agréable à utiliser (c'est un C# en mieux). Sa syntaxe est plus "moderne" que Java et moins permissive. Les infix permettent d'étendre le langage à sa convenance (comme linq de C# mais en plus puissant et en paramétrable) et apportent des mécanismes très utiles dans Android, comme les déclarations tardives (mais c'est évidemment un avantage spécifique à la façon dont Android travaille).

Moi, je préfère "perdre mon temps" à approfondir mes connaissances sur des technologies éprouvées (comme JEE)

C'est un choix qui en vaut un autre, mais, personnellement, j'ai peu développé en Java (je ne fais pas de web) car je travaille beaucoup en bas niveau sur microcontrôleurs et en C# sous Windows, mon domaine étant principalement la communication entre des logiciels embarqués et des PC. Je n'utilise Java que pour Android et là j'ai vu de suite l'intérêt de Kotlin et le gain de confort. Le tout sans rien perdre puisque Kotlin produit au final du byte-code Java et donc les librairies Java restent fonctionnelles, sachant qu'on peut même mélanger du code java avec du code Kotlin dans la même application. Il y a même un copié/collé dans Android Studio qui permet de copier un code Java et de le coller en Kotlin, avec conversion automatique.

En outre, Kotlin n'est pas "un langage" parmi d'autre, c'est un des deux langages officiels reconnus par Google pour Android: Il est intégré nativement à Android Studio. Et donc, pour Android c'est un maître choix parfaitement justifié. Sans compter que (j'ignore si c'est déjà opérationnel) Kotlin est prévu pour générer du code compatible i-pad et même du code natif en direct.

Bref, pour Android, je pense que la migration est le bon choix, à partir du moment où on n'est pas contraint de conserver Java (boulot etc).
Pour du développement autre qu'Android, je n'ai pas d'avis, mais, comme je le précisais, ce sondage a été publié dans la section "Android", j'ai donc répondu sur cette base.

En quoi Kotlin permet de détecter plus d'erreurs que Java à la compilation ?

Pour ne prendre que trois exemples simples:
- La gestion des nullables: Si tu acceptes la valeur "null" pour une variable, alors tu ne peux pas accéder à ses propriétés sans tester "null". Il y a des syntaxes explicites pour t'éviter de le faire MAIS qui n'entraînent pas un plantage de l'application, et en outre tu peux chaîner les syntaxes. Par exemple si tu as un nom "name" qui peut être null, alors il t'est interdit de demander "name.lenght" par exemple: C'est refusé à la compilation et donc tu n'auras pas une erreur "pointeur null" à l'exécution. Mieux, si tu as un pointeur pouvant être null qui pointe sur une fonction pouvant renvoyer null, elle-même utilisant la valeur de retour pour une troisième fonction, tu peux tout écrire sans jamais tester les "null" explicitement (pas de if null à perte de vue) tout en conservant l'impossibilité de plantage en cas de valeur null. Et, évidemment, il t'est impossible de compiler le code si tu n'as pas utilisé cette syntaxe sécuritaire ou que tu n'as pas testé "null" à chaque étape. En Java le moindre oubli et c'est plantage à l'exécution.

- La gestion des lazy et autres méthodes de déclarations tardives. Si tu déclares des variables globales, par exemple, et que tu ignores leur valeur définitive plus loin dans le code (exemple simple: tu définis une variable "monBouton" qui devra pointer sur un contrôle "button"). Alors en Java tu dois initialiser monBouton à "null" et ensuite soit devoir faire des tests partout pour vérifier que c'est non nul, soit prendre le risque d'utiliser sans tester (risque de pointeur nullable). En Kotlin tu peux déclarer ta valeur globale en lui disant soit que tu l'initialiseras plus tard (auquel cas le compilateur vérifie que tu l'as bien initialisée) soit en lui précisant comment il devra l'initialiser lorsque tu l'utiliseras la première fois (tu renseignes la méthode d'initialisation mais vu que tu n'as pas encore le contexte ça n'initialise pas). Dans ton code, une fois que tu utilises "monbouton" pour la première fois, la méthode d'initialisation renseignée est exécutée à ce moment là. Du coup tu as une variable qui est déclarée et non initialisée mais qu'il t'est impossible d'utiliser sans qu'elle ne soit initialisée. En Java, si tu oublies d'initialiser l'erreur sera à l'exécution.

- La gestion des variables read-only: En Kotlin tu as le type "val" et le type "var", la distinction te permet des actions différentes en fonction du type et le compilateur vérifie que tu n'utilises pas des méthodes interdite, comme de changer l'affectation de "monbouton" vers un autre "Button" en cours de route, par exemple.

Et je passe sur les listes modifiables ou pas etc.

Bref, objectivement ce langage est plus sécuritaire et détecte plus de choses à la compilation et donc moins de plantages à l'exécution.

car un bon IDE permet de ne pas écrire une partie du code verbeux

Kotlin ne se base pas sur l'IDE, et du reste l'IDE ne permet pas de tout éviter.
Si tu prends "linq" sous C#, par exemple, c'est un plus du langage, pas de l'IDE. Et bien tu as l'équivalent en mieux sous Kotlin. Trier les éléments d'un tableau en faire le tri selon deux critères spécifiques et renvoyer les 3 premiers éléments, ça se fait en une ligne sous Kotlin, sans boucle et sans code inutile. En outre, sous Kotlin ton "linq" devient paramétrable puisque tu peux lui ajouter de nouvelles fonctionnalités.

Ce qui semble intéressant pour l'écriture de code asynchrone: les coroutines

C'est encore une souplesse supplémentaire.

Je pense que pour pouvoir comprendre les avantages de Kotlin, il faut au moins vérifier une fois ses spécificités, sinon on en reste à se demander "quel intérêt?".

Une petite (c'est relatif) présentation en Français sur Youtube permet déjà de dégrossir ce langage:

@ClaudeBg
Je conçois que tu trouves beaucoup d'avantages à Kotlin; me concernant et du peu d'expérience que j'ai avec ce langage, je ne le trouve pas si révolutionnaire, qu'il me ferait quitter Java.
Je suis en train de développer une application Android, donc je m'y suis mis. J'ai récupéré du code Java que j'ai converti en Kotlin, bien aidé par mon IDE.
Je ne pense pas qu'il sera plus ou moins buggé, ni plus ou moins facile à lire ou à tester.
Autant, j'ai pris un réel plaisir à passer d'Objective C à Swift, autant là, rien de bien excitant. Je précise que je compare à Java 8, sinon il y a évidemment un gros fossé avec les anciennes versions de Java, qui n'avait pas les Optional, les lambdas, etc...

J'ai fait un rapide tour sur Wikipedia, il y a des choses sympa, j'aime en particulier le "fonction1()?.fonction2()?.fonction3()", le val (imutable) et var (mutable)

Oui, ce sont deux des points dont j'ai parlé.
En utilisant on en découvre d'autres (infix, lazy...).

Je conçois que tu trouves beaucoup d'avantages à Kotlin; me concernant et du peu d'expérience que j'ai avec ce langage, je ne le trouve pas si révolutionnaire, qu'il me ferait quitter Java.

On sait passer de Java en Kotlin en une journée, tellement c'est intuitif.
En ce qui me concerne, rien qu'augmenter le nombre de problèmes détectés à la compilation c'est déjà un argument qui vaut la peine: le risque de bugs diminue de façon objective.

pas tellement à cause de Java proprement dit mais de la richesse des bibliothèques EE.

Heuu, Kotlin est full compatible avec Java: N'importe quelle librairie Java peut être utilisée avec Kotlin et Kotlin repose sur les librairies Java.
On ne perd rien!

Je ne pense pas qu'il sera plus ou moins buggé, ni plus ou moins facile à lire ou à tester.

Ben oui, mais en même temps si tu demandes à un outil automatique de te convertir du code java en Kotlin, il va te faire "une traduction littérale" et donc tu ne profites pas de Kotlin.
Ça fonctionne, ça permet de traduire "des exemples" qu'on trouve en Java, mais on ne code pas en Kotlin de cette façon, les mécanismes qu'on utilise sont différents.

Je ne pense pas qu'il sera plus ou moins buggé, ni plus ou moins facile à lire ou à tester.

Disons qu'en Kotlin tu as des détections de bugs qui se font à la compilation et que le compilateur Java ne peut pas voir.
Donc je ne prétends pas que ton code sera moins buggé mais je dis qu'une partie des bugs potentiels seront trouvés au niveau de la compilation, dont tout ce qui concerne les pointeurs null, qui sont un bug courant.
Quant au fait d'être plus lisible, ça dépend également évidemment de la façon dont chacun code. Mais moi je trouve la syntaxe plus claire et plus dépouillée.

Je précise que je compare à Java 8

Ben, jusqu'à présent, Java 8 sous Android....
Sinon, tout ce qu'a Java 8 se trouve dans Kotlin mais la réciproque n'est pas vraie.
Et vu le temps minime d'apprentissage pour migrer, aucune raison de m'en passer.
Sinon en ce qui me concerne la découverte de Kotlin m'a procuré la même sensation que la découverte de C#: Un langage encore plus évolué.

Maintenant, chacun fait évidemment comme il l'entend, mais en ce qui me concerne repasser à Java en venant de Kotlin serait un retour dans le passé de l'informatique. En outre c'est un langage open-source et je pense que le ciel à l'horizon est plus clair pour les utilisateurs de Kotlin que pour ceux qui resteront sur Java. D'autant plus que Google en a fait un langage officiel (va-t-il en conserver deux?)

Mon avis est qu'on peut se faire une idée des fonctionnalités du langage avec une bonne présentation, mais que pour le rejeter objectivement il faut l'avoir essayé "en vrai" (un vrai code d'une vraie application écrit nativement en Kotlin)

Je note également que personne ne donne des arguments "contre" Kotlin, c'est plus un sentiment d'inertie genre "pourquoi changer?" que des arguments genre "Dans Java je préfère ceci ou cela".
Mais bon, je peux concevoir que chacun a ses habitudes et n'aime pas forcément changer s'il n'en voit pas un intérêt démontré.

Mon point de vue est le suivant.
Je dois développer un nouveau produit sur Android, alors je choisis Kotlin, qui est le langage mis en avant par Google. C'est que j'ai fait sur mon projet actuel.
Ce ne sont pas les qualités du langage qui me font le choisir.
Et si je dois développer ailleurs que sur Android, la question ne se pose même pas, je reste sur Java, les avantages ne me semblent pas suffisamment nombreux pour changer, surtout pour rester sur la machine virtuelle.
Quitte a apprendre un nouveau langage, autant qu'il y ait une vrai rupture de concepts, pas juste quelques petites retouches superficielles.

Je vous ramène a ce lien :
https://www.developpez.com/actu/1653...lise-fin-2018/

Et de plus, si les dev de chez Google eux même pensent que c'est un langage intéressant, c'est qu'il y a des raisons...

Je vais pas reprendre les points mis en avant dans le lien mais Kotlin est globalement beaucoup plus pratique et rapide (en terme de dev) que Java.

Pour le manque de doc, une grande partie de la doc Google est dans les deux langage (si ce n'est pas toute la doc?) donc bon, tu as déjà un bon socle :O
De plus, de mon point de vue, Java est un langage qui a une syntaxe lourde... ce que Kotlin efface en grande partie.
Et pour les alternative web, n'avoir qu'un couple NodeJs/Vues.Js fait très bien l'affaire...

Le seul avantage de Java est sa robustesse je trouve mais il y a bien d'autre langage aussi fiable

Pour ceux qui hésitent encore, essayez Kotlin sur un projet et vous verrez