Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

150PARTAGES

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 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 _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 
Avatar de nhugodot
Membre régulier https://www.developpez.com
Le 12/12/2017 à 16:32
  • Symfony est d'origine française, pas Django. "NIH"? (syndrome Not Invented Here?)
  • Et personne n'a parlé de chercher du travail avec Django. Entre un poste de CEO et un job de plombier, y'a aussi plus d'offres d'emploi pour plombier...
  • 1er résultat de ma recherche "Symfony vs Django": boum, enfoncé Symfony...


Rapidité? ah ben flûte: http://blog.websitesframeworks.com/w...03/davis11.png
Ah ben vraiment flûte même: perdre 3% de clients et être lent à ce point...: http://static.alrond.com/siege.gif

La messe est dite: quand on fait sa pub sur PHP, on sait à qui on a affaire... (pas un ingénieur... un vrai)
1  0 
Avatar de nhugodot
Membre régulier https://www.developpez.com
Le 12/12/2017 à 17:03
Salut SurferIX et merci pour ton appréciation... je ne suis plus codeur mais me passionne néanmoins pour les belles choses, simples et efficaces, les architectures, et déçu par le "reinvent the wheel" pour la 100000 fois pour faire un bouton ou un bout de chat dans une app, cherche constamment "quel est le plus productif des outils de dev.. désespérant, quand même... on revient à ... Smalltalk. Tout ça pour ça.

Tout est là: https://medium.com/@richardeng , le mossieur est encore plus désillusionné que moi mais encore plus compétent néanmoins. Pharo, bébé d'un directeur de recherche de l'INRIA de Lille, est le futur, le SmallTalk du 21e siècle. Quelques trucs top dedans: tout est dans un seul fichier, même l'état, rechargeable après un reboot donc on retrouve l'endroit ou on était (une app iOS ou Android me fait pleurer: en pause hop elle dégage et en rallumant son phone... faut tout recharger... ). Syntaxe hyper claire, une autre façon de travailler. Etc.

Mais Pharo ne fait pas Android et iOS, Dart/Flutter si et est le futur de Android: FuschiaOS:
et surtout https://hackernoon.com/why-native-ap...r-e97361a1c073
Dart>TS>ES>JS... J'ai pas encore trouvé mieux, je vais sans doute m'y mettre... Comme Pharo, le fait qu'on se passe parfaitement d'outil à la Gulp Grunt et autres acronymes vulgaires veut tout simplement dire que c'est propre, dès le départ. Le bazar JS React etc. c'est du bricolage, de génie mais du bricolage. "AMHA"...

(Ah, Elm, aussi, mais non pas OO mais fonctionnel, est à essayer absolument aussi; idem, pas besoin de pléthore d'outils compliqués, expérience de dev géniale. Clojure aussi avec son IDE interactif "REPL" que les amateurs louent aux nues... Go est un C++ facile aussi. Tout est là, je compile mes lectures ici: https://docs.google.com/document/d/1...h.te2c3nnwu1w7
à toi d'y participer!
1  0