Tutoriel sur une introduction à Ceylon, un Java moderne et sans legacy

J'ai récemment eu l'occasion d'assister à la conférence « Ceylon Tour Paris 2014  ».

Je me suis intéressé à ce langage pour certains de ses objectifs.

• Être tellement simple à lire qu'un développeur connaissant l'orienté objet peut le comprendre sans apprendre le langage.
• Disposer d'un typage statique implicite.

Il présente d'autres caractéristiques intéressantes que j'ai découvertes à la conférence « Ceylon Tour Paris 2014  » (et qui sont présentées sur la page d'accueil de leur site). Par exemple, il doit :

• tourner sur la JVM et dans un moteur JavaScript ;
• être un modèle de composant (du modulaire qui montre les contrats et cache les implémentations).

Je me suis inscrit à cette conférence parce que Ceylon mérite que l'on s'y essaye et pour être honnête parce qu'elle était gratuite.

Ceylon ressemble à ce que serait Java s'il était à nouveau écrit aujourd'hui. Ils ont les mêmes cibles d'usage : être un langage objet « généraliste », plutôt facile d'accès. Ceylon a quelques ambitions supplémentaires : il peut tourner sur la JVM, mais aussi dans un moteur JavaScript comme nos chers clients web.

II-A. Modèle de données▲

/* Attention, ce n'est pas un DSL, c'est du code Ceylon typé et compilé en bytecode java ou javascript */
Html {
  doctype = html5;
  Head {
    title = "Ceylon: home page";
    Link {
      rel = stylesheet;
      type = css;
      href = "/styles/screen.css";
      id = "stylesheet";
    };
  };
  Body {
    H2 ( "Welcome to Ceylon ``language.version``!" ),
    P ( "Now get your code on !" );
  };
};

II-B. Modèle de flux d'exécution (threads et concurrence)▲

value rndValue = Math.random(); // rndValue est immutable.
variable value rndIteration = Math.random(); // rndIteration peut être assignée avec une nouvelle valeur.

value adults = [ for(p in people) if (p.age>=18) p ]

Bref, Ceylon est une version moderne de Java depuis ses fondations !

Voilà pour ce qu'est Ceylon. Revenons un peu sur le typage statique et implicite.

Les attributs (variables immutables) sont définis avec le mot-clé value ou avec un type. On peut écrire tout un algorithme en n'utilisant que des values et le compilateur fait un maximum d'inférences de type. Notre code perd alors toutes ces déclarations de types qui alourdissent le code tout en gardant les erreurs de compilation lorsque l'on se trompe. C'est un typage implicite.

Ensuite, les API retournent des types que l'on ne verra pas dans le code, mais qui apparaissent en infobulle lorsque l'on survole chaque mot-clé « value ». Ainsi, le compilateur vérifie tous les types même implicites. C'est donc un typage statique.

Enfin, ils ont poussé la logique du statique et implicite assez loin et c'est fort de café.

Ainsi, lorsqu'une liste est initialisée avec des constantes en chaîne de caractères et en nombre entiers, le type de la liste est l'union des types : « String|Integer ». Une « value » ayant un type uni est une instance d'un seul de ces types. On ne peut alors utiliser que les méthodes communes à tous les types de l'union. L'autre option est d'itérer sur cette liste composée de plusieurs types et/ou de faire un « switch case » sur ces unions de types :

void printDouble(String|Integer|Float val) {
  String|Integer|Float double;
  switch (val)
    case (is String) { double = val+val; }
    case (is Integer) { double = 2*val; }
    case (is Float) { double = 2.0*val; }
    print("double ``val`` is ``double``");
}

Le principe inverse existe avec des intersections de types où chaque instance est à la fois d'un type et d'un autre. On peut alors utiliser les méthodes des deux types. Je n'ai pas vu comment se passe cet héritage multiple dans le détail.

J'ai eu une surprise en voyant que Object est un type père de tous, mais fils de Anything et que ce dernier est père de Object et de Null. Null n'ayant qu'une seule instance en mémoire (null). Ainsi, les méthodes pouvant retourner une valeur nulle retournent leur type de valeur naturel ou Null. Cela s'écrit évidemment « String|Null » ou en raccourci String? :

String? name = process.arguments[0];
if (exists name) {
  String notNullable = name;
  print("hello " + notNullable);
}

Cela signifie qu'une valeur pouvant être nulle (String?) et une valeur ne pouvant pas être nulle (String) n'ont pas strictement le même type.

J'ai eu deux dernières bonnes surprises. D'une part, les listes vides ont aussi leur type comme les valeurs nulles, les itérateurs finissent leurs itérations avec le type « Finished »…

{String*} noStrings = {}; // {String*} est un iterable pouvant être vide et retourner Finsihed tout de suite
{String+} twoStrings = {"hello", "world"}; // two Strings ne peut pas être un itérable vide

D'autre part, des assertions permettent de faire le ménage. Comme le compilateur ne peut pas toujours être sûr de tous les types, il prend les assertions et autres casts comme des preuves. Par exemple, dans le cas précédent, le « name » est déclaré avec un point d'interrogation et cela signifie qu'il peut être nul. L'instruction « exists » qui suit teste que « name » n'est pas nul. Le système de typage de Ceylon est alors sûr que « name » ne peut pas être « null » et la déclaration de « notNullable » sans le point d'interrogation est valide.

Je me servirai de ce langage pour écrire rapidement des outils évolués, mais internes à notre équipe comme des outils de reporting qui remontent quelques info provenant des logs mis sous ElasticSearch, des états des derniers build Jenkins, le bon déroulement de batchs de déploiement, etc. bref, ce que l'on appelle parfois les outils ou les « toy projects » professionnels.

Le site annonce une version 1.0.0 qui est prête pour de la production. Autant ces gens sont sérieux et crédibles, autant je ne conseille à personne de lancer un projet « sensible » sur une technologie avec laquelle il n'a pas suffisamment d'expérience. C'est d'ailleurs l'intérêt des projets d'outillage. Ils ont non seulement une taille et un coût raisonnable, mais, en plus, ils partent en production…

Enfin, pour ce qui est de la conférence/formation, elle nous a fait faire un vaste tour de ce qu'est Ceylon, de son écosystème et de l'état d'avancement de chaque fonctionnalité.

En effet, le langage est en version 1.0 « No More Mr Nice Guy », mais pas son environnement. Les plugins de l'IDE Eclipse sont au point, mais écrits en Java. Le système de build concurrent du Maven de Java et du Gradle de Groovy est en pleine réécriture. Cayla est un framework web prometteur côté serveur ET client qui manque de templates, de widgets (une taglib, du jsf, etc.).

En conclusion, je vois dans Ceylon, un phare pouvant indiquer une direction aux développeurs de Java. J'y vois aussi un langage plus expressif et potentiellement plus facile à écrire pour les développeurs d'applications métiers.

Le langage est enfin là, il faut maintenant qu'il trouve son public, qu'on trouve des patterns et des bonnes pratiques (comme l'usage de méthodes lazy dans les opérations sur les collections). J'espère voir fleurir des ateliers orientés sur l'usage du langage, que ce soit sous forme de Kata, ou d'application démo comme le fameux « Pet Shop » de « JEE ».

L'avenir fera ses choix en temps et en heure, mais si jamais Oracle voulait se concentrer sur la JVM et ses outils de contrôle (JMC, JProfiler, etc.) et abandonner Java, cela ne m'inquiéterait plus, la relève est déjà là !

Cet article a été publié avec l'aimable autorisation de la société Arolla et l'article d'origine (Ceylon : un java moderne et sans legacy) peut être vu sur le blog/site de Arolla.

Nous tenons à remercier jacques_jean pour sa relecture orthographique attentive de cet article et Mickael Baron pour la mise au gabarit.