Publié par et

Il y a 8 ans -

Temps de lecture 4 minutes

Devoxx – Ceylon


Après avoir assisté à la session sur Kotlin, nous ne pouvions pas faire l’impasse sur la présentation du langage Ceylon animée par Emmanuel Bernard et Stéphane Epardaud. Cette session était focalisée sur les motivations qui ont poussé à développer ce langage et devait nous montrer les possibilités de ce dernier.

Le projet Ceylon a été initié par Gavin King dont nous connaissons tous la renommée. Emmanuel explique que pour des raisons de frustrations avec le langage Java, Gavin et son équipe ont décidé de monter ce projet. Ils souhaitent développer un langage avec l’esprit Java et étant aussi pratique que ce dernier.

Les buts du développement du langage Ceylon sont les suivants :

  • facile à apprendre,
  • moins verbeux tout en restant lisible,
  • type safety améliorée,
  • avoir un nouveau SDK (plateforme),
  • possibilité de faire du meta-programming.

Emmanuel poursuit par du code, dont voici quelques exemples.

Les points qui changent par rapport à Java ou à d’autres langages de la JVM

La gestion de la visibilité

Toutes les classes, variables et méthodes sont par défaut avec une visibilité private. Seules deux visibilités existent : private (par défaut) et shared (public). Une classe privée n’est visible que par les autres classes du même module. Une méthode shared est visible par toutes les classes qui peuvent accéder à sa propre classe.

Surcharge

Par défaut, toutes les méthodes, attributs et classes ne peuvent pas être surchargés. À la place, Ceylon fournit dans sa syntaxe deux mots-clés permettant de gérer la surcharge de méthodes en plus du qualifieur par défaut.

  • default : peut être surchargée. On définit l’implémentation par défaut.
  • formal : doit être surchargée.
  • actual : indique la surcharge. Plus ou moins équivalent à @Override en java.
abstract class Shape() {
 shared formal Natural area() ;

shared actual default String string {
  return "Abstract area : " area.string " m^2 ;
}

class Square(Natural width) extends Shape() {
  shared actual Natural area() {
    return width * width ;
  }
  shared actual String string = "Square area : " area.string " m^2" ;
}

Dans cet exemple, la méthode string est équivalente à toString en Java. Elle est surchargée dans Shape, elle doit donc être préfixée avec actual.

Overloading

Pas d’overloading que ce soit pour les méthodes standards ou le constructeur. Un seul constructeur est donc possible par classe. Mais il fournit en contrepartie des attributs optionnels. Emmanuel propose, pour le constructeur, d’utiliser un switch sur le type de l’argument.

void workWithRectange(Rectangle rect) { }
void workWithCircle(Circle rect) { }

void workWithFigure2D(Figure2D rect) { }

void supportsSubTyping(Shape fig) {
  switch(fig)
  case(is Rectangle) {
    workWithRectangle(fig) ;
  }
  case(is Circle) {
    workWithCircle(fig) ;
  }
  case(is Figure2D) {
    workWithFigure2D (fig) ;
  }
}

Rectangle, Circle et Figure2D sont ici des sous-classes de Shape.

Gestion du null

De la même manière que Kotlin, Ceylon utilise le caractère ‘?’ pour définir si une variable peut être nulle ou pas.

void typeSafety() {
  Cube? cubeOrNull() { return null; };
  Cube? Cube = cubeOrNull() ;

  print(cube.area.string) ;
}

Cet exemple génère une erreur de compilation. Il convient d’utiliser la forme ci-dessous.

void typeSafety() {
  Cube? cubeOrNull() { return null; };
  Cube? Cube = cubeOrNull() ;

  if (exists cube) {
    print(cube.area.string) ;
  } else {
    print("No cube") ;
  }
}

Union type

class Apple() {
  shared void eat() {}
}

class Snail() {
  shared void throwAway() {}
}

void unions() {
  Sequence<Apple|Snail> plate = {Apple(), Snail()};
  for (Apple|Snail food in plate) {
    print(food.string);
    if (is Apple food) {
      food.eat();
    } else if (is Snail food) {
      feed.throwAway();
    }
  }
}

L’union de types permet d’être sûr d’avoir un objet de type Apple ou Snail. Le mot-clé is permet de vérifier le type.

Autres fonctionnalités

Dans les autres fonctionnalités et syntaxes plus classiques, on retrouve :

  • les closures,
  • les annotations,
  • un système d’interceptor pour la programmation par aspect,
  • un système de modules.

Concernant l’outillage, Stéphane nous montre du code en live avec le plugin Eclipse. Ce dernier est assez avancé et nous retrouvons la coloration syntaxique, le refactoring, le type checking ainsi que le debugger.

Conclusion

Emmanuel termine la présentation en nous annonçant la mise en ligne du site sur Ceylon. N’hésitez pas à le consulter : la documentation est bien fournie (fonctionnement du langage, spécifications, etc…) et les exemples sont nombreux.

Enfin il ajoute que tout le monde est bienvenu sur le projet. Un github est disponible et il est possible de contribuer au projet dès à présent.

La séance s’est terminée par des questions/réponses. Nous avons notamment eu la question suivante : « Où se situe Ceylon par rapport à Kotlin ou à d’autres langages (Scala, Fantom) ? » Emmanuel explique que Ceylon se trouve entre le monde Kotlin et Fantom. Il justifie cela par le fait que le langage Fantom a pris le parti de supprimer certaines notions du langage Java et que dans Kotlin on ne retrouve pas la notion d’Union type.

À travers cette conférence, nous constatons que les nouveaux langages sont à la « mode ». Ceylon tente de se faire un chemin dans la bataille aux « successeurs de Java » avec d’autres challengers comme Kotlin. Il ne nous reste plus qu’à surveiller les évolutions de ces différents langages et de voir lequel proposera les meilleures approches de programmation dans les mois à venir.

Publié par et

Publié par Nicolas Jozwiak

Nicolas est delivery manager disposant de 12 ans d’expérience en conception et développement. Son parcours chez un éditeur avant son entrée chez Xebia lui a notamment permis de développer de solides compétences dans le domaine de la qualité et de l’industrialisation (tests, intégration continue, gestion de configuration, contrôle qualité). Bénéficiant d’une expérience très solide de mise en place des méthodes agiles et d’accompagnement d’équipes sur le terrain, il s’attache à mettre à profit quotidiennement son expérience qui est reconnue pour son approche pragmatique, proactive et pédagogique.

Publié par Julien Buret

Julien est CTO chez Xebia. Il est également formateur au sein de Xebia Training .

Commentaire

4 réponses pour " Devoxx – Ceylon "

  1. Publié par , Il y a 8 ans

    Merci pour ce retour!

    Le grand vainqueur de cette fragmentation risque d’être Java 8 lui même…

  2. Publié par , Il y a 8 ans

    juste une remarque sur l’erreur de traduction habituelle
    Override = redéfinition
    Overload = surcharge

  3. Publié par , Il y a 8 ans

    @Nicolas L.: je ne demande pas mieux (contexte: j’utilise Scala depuis plus de 4 ans maintenant, j’en suis très content, et j’ai même des ‘tit jeunes que j’ai encadré qui le trouve simple, c’est pour dire si je suis une exception).

    Que tout ces langages influencent l’évolution de Java, la JVM en profitera, les notions deviendront plus courrente et donc moins refusés car trop complexe (meilleur formation des développeurs à ces notions), et au final tout le monde en profitera :) Meilleur VM, langages cross-polénisé et en saine compétition, c’est un nouveau soufle dans le plus bel écosystème de programmation.

    C’était mon moment fleures bleues et lapins qui dansent dans les prés (c’est aussi parce que j’ai beaucoup rit en lisant: http://blog.joda.org/2011/11/scala-feels-like-ejb-2-and-other.html , à la fois l’article et les commentaires)

  4. Publié par , Il y a 8 ans

    Au programme de Java 8, on a les closures et un peu d’inférence type associée.

    Donc, sauf erreur, la roadmap de Java 8 n’inclut pas les fonctionnalités suivantes qui constituent le pot commun des nouveaux langages actuels :
    * Une utilisation plus intensive de l’inférence de type,
    * Simplification des accesseurs sur les propriétés,
    * Les Traits.

    Bref, il semble qu’il faille (encore) attendre Java 9 (2014 ? 2015 ?) pour cela.

    Si c’est bien le cas, les développeurs de C# pourront bien continuer à se moquer (gentiment ou pas) des développeurs Java.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.