Kotlin 1.0 est disponible en version finale
Le langage de programmation pour JVM et Android mise sur la compatibilité avec plusieurs outils existants

Le , par Olivier Famien

126PARTAGES

2  0 
Depuis plus de 5 ans, Jetbrains et les contributeurs de la plateforme GitHub se sont lancés dans la mise en œuvre de Kotlin, le langage de programmation open source statiquement typé. Selon ses concepteurs, Kotlin se veut clair, sûr et suffisamment outillé pour répondre aux besoins des utilisateurs.


Un des points saillants mis en avant par l’équipe de développement, outre ceux cités, est son caractère interopérable avec le langage de programmation Java et sa compatibilité avec les architectures déjà existantes. Selon les dires d’Andrey Breslav, le concepteur en chef de ce langage, « n’importe quelle bibliothèque Java peut être utilisée dans Kotlin et vice versa ».

Aussi, ajoute-t-il, les développeurs embrassant ce langage n’auront pas besoin de tout « réapprendre, réinventer, refaire à partir de zéro », car les outils tels qu’Ant, Gradle et Maven peuvent être utilisés pour la compilation, IntelliJ IDEA ou Eclipse peuvent être utilisés comme environnement de développement et un outil en ligne permet de coder et effectuer des tests directement dans le navigateur. C’est ce qui incite Andrey et son équipe à décrire Kotlin comme un langage « pragmatique ».

Au début de ce mois, l’équipe de Jetbrains avait annoncé la disponibilité de la version Release Candidate (RC) de Kotlin 1.0. Avec cette version RC, les développeurs devaient recompiler leur code pour s’assurer qu’il fonctionne avec la nouvelle mouture.

Par ailleurs, la release candidate marquant une étape importante vers la sortie de première version stable, il était évident que la version finale de ce langage ne tarderait pas à voir le jour. Et depuis quelques heures, c’est désormais le cas. L’équipe de Jetbrains vient d’annoncer la disponibilité de la version finale de Kotlin 1.0.

À partir de cette phase, affirme Andrey Breslav, « nous nous engageons à assurer à long terme la compatibilité descendante du langage et de sa bibliothèque standard (Kotlin-stdlib) ». Pour parvenir à cela, Andrey explique dans la feuille de route « qu’un nouveau compilateur fonctionnera avec des binaires plus anciens (mais les compilateurs plus anciens ne pourront pas comprendre la composition des binaires plus récents, comme javac 1.6 n’est pas capable de lire les classes compilées par javac 1.8) ».

De même, plusieurs travaux tels que l’amélioration des performances de la chaine d’outils de Kotlin sont prévus, ainsi qu’un support de JavaScript et un support générant du bytecode Java 8 avec des expressions lambda optimisées.

Mais pour l’heure, l’on note dans cette version finale quelques changements au niveau de la bibliothèque et du compilateur. On peut citer par exemple le fait que :

  • l’annotation kotlin.Metadata doit être utilisée au lieu de KotlinClass ;
  • les anciennes annotations des métadonnées ont été supprimées du package kotlin.jvm.internal ;
  • l’usage de HALF_EVEN comme mode d’arrondi par défaut est préconisé pour l’opérateur de division BigDecimal ;
  • la taille de la mémoire tampon pour les opérations IO est maintenant de 8 k comme celle par défaut dans la classe Java BufferedReader ;
  • les éléments de la bibliothèque dépréciés dans la version RC ont été abandonnés ;
  • le problème d’incompatibilité avec RoboVM a été résolu ;
  • une mauvaise inférence du type du résultat obtenu avec la structure conditionnelle if/else a été réglée ;
  • un problème de visibilité interne des projets Gradle dans IntelliJ IDEA 16 a été corrigé ;
  • le compilateur déclenche l’exception UninferredParameterTypeConstructor dans un bloc de code où tous les types sont conditionnés par la condition When. Ce problème a été également réglé.

Pour ceux qui souhaitent utiliser Kotlin, nous rappelons qu’il est possible de s’en servir pour développer des applications côté serveur, des applications mobiles Android et des applications de bureau.

Kotlin sur GitHub

Source : Blog Jetbrains

Et vous ?

Que pensez-vous de cette version finale ? Les arguments présentés sont-ils suffisants pour vous faire migrer vers ce langage ?

Utilisez-vous déjà Kotlin ? Comment le trouvez-vous vis-à-vis des autres langages ?

Voir aussi

Forum Autres langages pour la JVM

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de _skip
Expert éminent https://www.developpez.com
Le 20/02/2016 à 11:10
Un des premiers points positifs de Kotlin, qui était un blocker pour moi avec Ceylon, c'est l'absence de compromis sur les types standards de java.
Je comprends que pour certaines personnes, les tableaux sans boxing ainsi que les nombres de moins de 64 bits (byte, short, float, int) ne soient pas nécessaires. Malheureusement c'est pas valable dans mon cas, avoir des listes de 1000000 int primitifs ou 1000000 longs boxés, ça revient pas au même. J'ai l'impression que c'est un compromis imposé au backend JVM pour le bénéfice de l'interop javascript, en réalité je suis pas sûr des vraies raisons.

Les points les plus intéressants à mon sens dans Ceylon et qui me manquent en java, soit

  • les properties (un remplacement de getter/setter sans méthodes détournées comme Lombok)
  • la distinction entre référence nullable ou non
  • Les variables immuable (final) ou non
  • l'inférence de type


Je les retrouve aussi dans Kotlin. En revanche, un point sympa dans ceylon qui n'est pas dans Kotlin, ce sont les intersections et les unions de type.

J'ai utilisé kotlin dans un projet non stratégique ces derniers jours (conversion de données) et je voulais tester en même temps l'interaction avec du java standard. J'ai utilisé l'une des choses les plus moches de java, soit du JAXB dont j'ai recouvert mes classes kotlin d'annotations. Je m'attendais à ce que ça foire à cause de la réflection et de différences subtiles sur la nature des types, Je n'ai eu aucun effort spécifique à faire pour sérializer mes objets en XML dans un sens et l'autre, j'ai juste du mettre des valeurs par défaut aux arguments de mon constructeur principal pour être compatible javaBean. Ajouté une librairie java pour parser du HTML, aucun souci là non plus, je me sers directe de la lib sans ciment.

J'ai adoré me servir des extensions de la lib standard pour la classe File (ForeachLine, Writer)
https://kotlinlang.org/api/latest/jv...java.io.-file/

Je me sers peu des lambdas dans java8 sur les collections et les map, en quelques minutes de Kotlin j'en suis devenu accroc. Etant utilisateur d'Intellij ultimate, j'avais droit à un support IDE de pointe, la syntaxe sort naturellement, y'a ce petit "it" pour faire référence à l'objet concerné qu'on peut renommer si le souhaite en cas de nesting, tout cela coule tout seul, concis et lisible. Normalement je suis pas emballé par les déclarations "nomVariable : Type" mais ça pose en fait rarement problème tant j'use et abuse de l'inférence de type.

Bref, après ce premier contact, sentiment très positif. J'ai l'impression de faire du python avec le typage poussé (càd avec l'IDE qui comprend ce que vous retourne vos constructions et l'autocomplétion en conséquence) tout en pouvant profiter pleinement de l'écosystème de java. Pour moi c'était l'un des possibles juste milieu pour la JVM, un java amélioré avec 80% de ce que Scala offre de vraiment utile mais sans l'effort d'apprentissage.

Je ne saurais pas pondre une comparaison ceylon et kotlin, mais je trouve qu'ils vont tous les deux dans le bon sens et surtout les deux se relisent très très bien. Je n'aurai aucun souci à les utiliser pour un développement en équipe avec des développeurs de niveau inégal (alors que Scala je serais prudent à ce que je risque de devoir lire). C'est cependant dommage qu'effectivement, autant pour l'un que pour l'autre, il manque le super framework qui donne envie, comme play! pour Scala.
4  0 
Avatar de ilapasle25
Inactif https://www.developpez.com
Le 29/11/2017 à 21:19
Je connais pas Kotline mais j'ai pas envie connaitre. Java marche et marchera toujours bien, pourquoi changer ?
2  5 
Avatar de nhugodot
Membre régulier https://www.developpez.com
Le 08/12/2017 à 15:40
Citation Envoyé par SurferIX Voir le message
Merci beaucoup pour toutes ces informations, très utiles. Cela confirme que rester dans des langages bétons comme C / C++ est plutôt pérenne...
En plus C# est vraiment un langage excellent.
Côté Web, même chose pour la rentabilité : rien n'arrive à la cheville de Django / Python.
De rien!

C#, oui, si on aime l'héritage C, la syntaxe, etc. (j'aime pas... rien à faire...), mais chapeau à MS. Et ils font le même coup avec TypeScript: reprendre un langage vieux (voire pourri) et en faire un truc nettoyé, propre, puissant, agréable, ... (ils avaient déjà fait ça avec DOS... devenu Windows 95, puis NT, ils savent faire...)
Je préfère la lignée Lisp et Smalltalk: resp. Elixir (voire Clojure) et Pharo.

Python/Django, vraiment le plus productif?
J'ai essayé l'an dernier...
Et puis devant faire des apps mobiles, rien à faire, on doit se taper swift/java, ou ES (React Native, ou NativeScript, ou Ionic 3 que je vais tester... Au moins c'est sur Angular donc TypeScript... dommage, Google utilise ce dernier en Dart que j'aurais préféré, ils disent avoir eu +20% de productivité, alors pourquoi passer à TypeScript? Parce qu'encore une fois les dev corporate venant de C, C++, Java, C# veulent un truc qui les dépayse pas, normal... Donc va pour TS... Google ne s'embarrasse pas de cet héritage, lui qui avait démarré en Python ainsi que Youtube d'ailleurs, ils ont remplacé C++ par Go et JS par Dart...). Bref, on s'est tapé React Native, pas pour les enfants... (le bazar React vs la cathédrale Angular).
A priori, le plus productif est Pharo, pas Python, Seaside, pas Django, et en plus y'a un smalltalk client JS: Amber, plus avancé que le Python transpilé en JS, Transcript par exemple (y'en a 3 au moins...):
https://medium.com/smalltalk-talk/a-...9ab#.pfbyjfuq5
https://medium.com/@richardeng/i-gue...t-2e166eff88bf
Elm et Clojure ont aussi un expérience de dev "wow"...

Mais je suis tout ouïe pour découvrir enfin du vrai dev productif! (fatigué de réinventer des roues... ), web et apps (webapps mobiles ou natives stp)? Grand merci!
ps: je cherche un CTO pour ma start-up, projet excitant, un bon, si intéressé... https://fr.linkedin.com/in/nicolashugodot/fr !
2  0 
Avatar de _skip
Expert éminent https://www.developpez.com
Le 13/12/2017 à 9:59
Euh, ça parle plus beaucoup de Kotlin là

Citation Envoyé par nhugodot Voir le message

A part des bricolos qui ne sont pas des vrais hackers niveau ingénieurs, y'a plus personne de sérieux qui fasse du PHP... En France c'est Java, aux USA c'était Ruby, JS/ES/TS maintenant, et on passe aux langages fonctionnels svp, merci...!
C'est bien trop réducteur...

Je voulais pas trop intervenir dans le débat mais tu oublies que PHP est très présent dans le eCommerce, et c'est un secteur en très grande expansion où il a de l'argent et beaucoup à faire. En 10 ans que je suis dans une PME qui édite justement des solutions de pilotage de merchandising, on a vu défiler énormément de PHP, et sinon du .Net et du Java (ces 2 derniers sont souvent pour les gros comptes) mais par exemple dans ce secteur : quasi jamais de Python.

Et je dirai que les développeurs PHP de qualité, ça ne court pas les rues, peut être parce que c'est une techno très accessible, donc il y a largement la place pour sortir du lot, faire du travail sérieux et bien gagner sa vie. Pour les indices TIOBE et tout ça, tout a déjà été dit sur les topics dédiés à ces classements, on peut quasiment rien en tirer. Pour ça je suis d'accord avec dukoid que les offres d'emplois c'est "presque" un meilleur indicateur, resterait bien sûr à savoir maintenant si c'est des emplois d'esclaves sous payés qui doivent modifier un plugin wordpress ou des vrais postes où il y a de la valeur, mais c'est indéniablement un plus grand nombre d'opportunités.

Pour finir, si SurferIX juge qu'il est plus productif avec django qu'avec symfony parce que les templates se débuggent plus facilement, ben il a raison d'utiliser ça. Ca veut dire moins de travail pour lui et plus de satisfaction client, et c'est juste la seule chose qui compte. Je dirai la même chose d'un type qui pense l'inverse. A côté de ça, les graphiques de performance, le fait que ça fasse ou pas du mobile, du big data, ou du shell scripting, c'est complètement hors sujet.

Avant que quelqu'un se la ramène pour me dire que je défends PHP alors que c'est un langage de merde (et là dessus il y a beaucoup à redire), sachez que je n'ai jamais eu le loisir de choisir un langage selon mes propres critères d'appréciation, ça a toujours été selon l'écosystème, les libs/API disponibles ou les cibles de déploiement. Si vous pouvez vous permettre de vous limiter à un langage que vous adorez par dessus tout en fonction de vos seules opinions, je vous envie.
2  0 
Avatar de IsiTech
Membre actif https://www.developpez.com
Le 15/02/2016 à 23:18
Je test Kotlin pour du développement Android depuis peu et j'aime beaucoup. La syntaxe est particulièrement agréable, toutes les bibliothèques que j'utilise sur mes projets Android fonctionnent avec Kotlin et le langage est bien intégré à Android Studio.

Je pense que Kotlin a toutes les chances de se faire une place dans le développement Android, il reste à espérer que Jetbrains continue à supporter le langage et que Google s'y intéresse.
1  0 
Avatar de Logan Mauzaize
Rédacteur/Modérateur https://www.developpez.com
Le 19/02/2016 à 22:16
Ayant étudié de prêt Ceylon, je suis curieux de regarder ce langage de plus prêt. Le problème c'est que ce n'est pas le seul sur la pile sans compter les frameworks, les bases de données, les sérialisations, les middlewares, etc. difficile de tout regarder dans le détail.

En parlant de Ceylon, il va plus loin dans la sûreté en l'appliquant également dans la conversion (cast), ainsi il n'y a pas de ClassCastException non plus. Est-ce que Kotlin fait de même ?

Autre point, y a-t-il un projet porteur pour ce langage comme Play!/Akka pour Scala, Gradle/Grails pour Groovy ? Je pense que c'est ce qui fait cruellement défaut à Ceylon pour réellement décollé. Même si un gros travail a été fait pour proposer une API Vert.x pour Ceylon.
1  0 
Avatar de UnFroMage
Futur Membre du Club https://www.developpez.com
Le 25/02/2016 à 11:29
Citation Envoyé par _skip Voir le message
Un des premiers points positifs de Kotlin, qui était un blocker pour moi avec Ceylon, c'est l'absence de compromis sur les types standards de java.
Je comprends que pour certaines personnes, les tableaux sans boxing ainsi que les nombres de moins de 64 bits (byte, short, float, int) ne soient pas nécessaires. Malheureusement c'est pas valable dans mon cas, avoir des listes de 1000000 int primitifs ou 1000000 longs boxés, ça revient pas au même.
Je ne veux pas faire de la promo pour Ceylon dans une discussion sur Kotlin, ça serait mal venu. Par contre je voulais juste répondre à ça pour dire que en Ceylon si vous compilez pour la JVM, vous pouvez utiliser les tableaux de la JVM (`int[]` -> `java.lang.IntArray` en Ceylon par exemple) qui ne feront donc pas de boxing.
1  0 
Avatar de SurferIX
Membre chevronné https://www.developpez.com
Le 12/12/2017 à 12:39
Je te remercie pour ce commentaire très constructif (et surtout très à la pointe ), et je te laisse dans ton cercle Php, tant mieux, reste-y !
T'es super bien en France on dirait, car ici on est un ratio extrêmement opposé, mais c'est vrai que la Silicon Valley n'est remplie que de crétins ! Au fait tu viens quand avec moi en amphi ? Je t'attends toujours pour ta présentation et tes réponses Symfony
Au moins je serai comme tous les développeurs Django en France : mieux payé que ceux en Php (donc que toi (67K€ contre 51K€)) .
(Ecris aussi à geekpress pour l'insulter, c'est encore un de ceux que tu dois considérer comme extrémiste )

Oh j'oubliais ! Stackoverflow aussi n'est rempli que d'extrémistes, regarde ici il y a 3 mois, contacte les et insulte les s'il te plaît, car regarde où ils voient Python et où ils voient Php fin 2018 :



Pour le reste, relis ce que tu écris, car les fautes d'orthographes sont comme Php : on n'a que des warnings, ça brûle les yeux, mais on continue quand même

Il n'empêche que j'attends une réponse de @nhugodot car, (lui), il paraît ouvert, et a amené des choses vraiment constructives... des propositions très intéressantes.
1  1 
Avatar de _skip
Expert éminent https://www.developpez.com
Le 12/12/2017 à 14:54
Citation Envoyé par nhugodot Voir le message
Au moins c'est sur Angular donc TypeScript... dommage, Google utilise ce dernier en Dart que j'aurais préféré, ils disent avoir eu +20% de productivité, alors pourquoi passer à TypeScript? Parce qu'encore une fois les dev corporate venant de C, C++, Java, C# veulent un truc qui les dépayse pas, normal... Donc va pour TS... Google ne s'embarrasse pas de cet héritage, lui qui avait démarré en Python ainsi que Youtube d'ailleurs, ils ont remplacé C++ par Go et JS par Dart...). Bref, on s'est tapé React Native, pas pour les enfants... (le bazar React vs la cathédrale Angular).
Ce n'est pas qu'une question d'habitude ou de dépaysement. Le succès (si on peut dire) de typescript vient aussi de son interopérabilité avec javascript qui est complète. Si tu choisis de coder en TS tu ne te prives aucunement de l'écosystème javascript. Tu ne fais que rendre ton code plus typé, et plus facile à maintenir. Dans un monde où on se sert beaucoup de libs existantes, ça compte énormément de pas passer par des couches interops foireuses et de finir le derrière entre deux chaises.

C'est aussi ce qui, je pense pourrait faire fonctionner kotlin. C'est un meilleur java avec une très bonne interop.
1  0 
Avatar de nhugodot
Membre régulier https://www.developpez.com
Le 12/12/2017 à 15:51
Citation Envoyé par _skip Voir le message
Ce n'est pas qu'une question d'habitude ou de dépaysement. Le succès (si on peut dire) de typescript vient aussi de son interopérabilité avec javascript qui est complète. Si tu choisis de coder en TS tu ne te prives aucunement de l'écosystème javascript. Tu ne fais que rendre ton code plus typé, et plus facile à maintenir. Dans un monde où on se sert beaucoup de libs existantes, ça compte énormément de pas passer par des couches interops foireuses et de finir le derrière entre deux chaises.

C'est aussi ce qui, je pense pourrait faire fonctionner kotlin. C'est un meilleur java avec une très bonne interop.
Merci Skip, commentaire autrement plus intéressant que l'humanoïde dissocié et son PHP...

Oui, TS est génial car garde toute la compatibilité avec l'existant: codes JS, codeurs JS et C++/Java/C#... , .. Google a été très pragmatique sur ce coup là, en faisant une évolution et pas une révolution. Et on peut utiliser TS avec Angular (donc Ionic et NativeScript) mais AUSSI avec React et VueJS etc.

Kotlin tournant sur VM JS et Java, je me demande quelle killer stratégie on peut bien y trouver pour faire quelque chose de génial que Java ou JS ne saurait pas faire... : tourner sur backend java et sur front end (JS, forcément... tant que WebAssembly n'est pas partout), profiter des deux écosystèmes et richesses de librairies?
1  0 
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web