Devoxx: Les deux nouveaux candidats à la succession au langage Java

Deux nouveaux langages qui commencent fort

Lors de ce Devoxx 2011, une catégorie de sessions était consacrée aux différents langages de la JVM.
Etaient présents Scala, Phantom, Groovy, JRuby, Clojure et les deux petits nouveaux révélés cette année par leur sponsor : Kotlin (JetBrains) et Ceylon (JBoss/Redhat)

Personnellement, ce sont ces deux nouveaux langages qui m’intéressaient le plus : j’adore la concision de Groovy mais le fait qu’il ne soit pas statiquement typée m’empêche de l’utiliser pour un projet avec un minimum d’envergure. Peut-être que l’un de ces deux langages pourra amener le meilleur de ces deux mondes…

Ces deux langages sont tout nouveaux et toujours en cours d’implémentation. Il n’est pas encore question de les utiliser sur de vrais projets mais nous avons pu voir durant les sessions de Devoxx que chacun avait déjà un compilateur fonctionnel et un IDE pouvant faire la démonstration de complétion, refactoring, debugging, … De quoi commencer à jouer avec a priori.

Caractéristiques

Ces deux langages ont une bonne partie de leurs objectifs en commun :

  • langage s’exécutant sur la JVM
  • statiquement typé
  • compilateur permettant de détecter plus d’erreurs
  • avoir une syntaxe plus simple et plus expressive que Java sans être aussi compliqué que Scala
  • complètement interopérable avec Java

Il en ressort un grand nombre de caractéristiques communes, comme par exemple :

  • inférence de type étendue
  • null safety (cf ci-dessous)
  • smart cast ou plus généralement des optimisations de syntaxe locale (cf ci-dessous)
  • constructeur primaire dans la syntaxe

Par contre, durant la présentation de Ceylon la notion de closure n’a pas du tout été évoquée, il n’est pas clair pour moi si elle sera supporté ou non. Kotlin de son côté les supportera très bien, avec en particulier la possibilité de mettre en oeuvre des “higher-order function”.

Je ne peux pas faire de comparaisons précises sur la base de ces deux présentations, mais au dire de Stéphane Epardaud qui nous a présenté Ceylon avec Emmanuel Bernard : Ceylon et Kotlin ont beaucoup en commun en termes de fonctionnalités. Pour lui, Ceylon se distingue par un système de typage plus abouti ( avec en particulier les union type, intersection type, … ).

Syntaxe

Au niveau de la syntaxe, les deux langages restent assez accessibles aux programmeurs Java, mais s’éloignent tout de même de la syntaxe Java.
Pour citer deux exemples :

  • dans Kotlin : le type des paramètres est écrit après son nom, et le type de retour après la définition d’une fonction. Par exemple :
fun main(args : List<String>) : Unit
  • dans Ceylon : de nouveaux keywords sont introduits qui remplacent une partie de ceux utilisés en Java ( abstract => formal, @Overide => actual, public/protected remplacé par “shared”, …), du code peut être associé à des properties (pour implémenter le getter ou le setter associé), …

Documentation

Jetbrains a très rapidement mis en place un wiki pour son langage avec pas mal de documentation et des discussions sur les choix effectués et leurs objectifs : http://confluence.jetbrains.net/display/Kotlin/Welcome

Pour Ceylon, c’était plutôt le brouillard en terme de doc, la plupart des références se trouvaient dans des blogs, des présentations, … rendant difficile la création d’un communauté.

Jusqu’à ce matin en fait, où ils nous ont révélé une “One more thing” à la fin de la présention : le tout nouveau site de ceylon : http://www.ceylon-lang.org/ et le github des développements en cours https://github.com/ceylon

Un petit focus sur deux des caractéristiques communes

Null safety

Dans les deux langages : les références ne peuvent pas être null par défaut.
Un type Integer (par exemple) correspondrait à un objet entier non null.
Un type Integer? correspondrait à un objet entier pouvant être null

Pour accéder à un champ ou une méthode sur une référence pouvant être null, il faut absolument utiliser ?. au lieu de simplement . sans quoi le compilateur génère une erreur. Si l’objet est null : l’opérateur ?. aura pour effet d’ignorer la suite de l’expression et de renvoyer simplement null
Exemple en Kotlin :

Int? x = getAnIntegerOrNull()
print (x?.times(2)) // ici, x peut être null : il est nécessaire d'utiliser ?.
                    // pour appeler la méthode times qui correspond à l'opérateur *
if(x!=null) {
  print(x * 2)    // ici, le compilateur sait que x n'est pas null,
                  // on peut utiliser x * 2 qui est équivalent à x.times(2)
)

Exemple en Ceylon :

Cube? cube = getCubeOrNull()
print cubs?.area()
if(exists cube) {      // permet de tester que la référence n'est pas null
  print cube.area()
} else {
  print "Cube is null"
}

Smart Cast

En Kotlin :

Object object = ...
if(object is String) {
  object.substring(1)  // pas besoin de caster l'objet en String,
                       // le compilateur le déduit de la clause if
}

En Ceylon :

Apple|Snail food = ...  // union type : food référence un objet soit de type Apple soit de type Snail.
if(is Apple food) {    // on s'assure que food est de type Apple
  food.eat()    // la méthode eat() n'existe que sur Apple, et pas sur Snail
                // dans le bloc du if, il n'est pas nécessaire de caster food en Apple pour l'appeler
}

On peut aussi considérer les deux exemples du paragraphe “null safety” comme des smarts cast : où le compilateur change le type de la référence d’un type nullable à un type non nullable.

Conclusion

Plus simple que Scala, ces langages pourraient répondre aux attentes de ceux qui veulent un langage sur la JVM qui soit plus expressif que Java.

Mais attention, Groovy les attend au tournant : la vérification statique du typage est en cours d’implémentation pour la prochaine version du langage : http://docs.codehaus.org/display/GroovyJSR/GEP+8+-+Static+type+checking

Il permettrait d’indiquer au compilateur d’effectuer un contrôle de type strict sur certaines classes : tout compte fait c’est peut-être juste ça que j’attendais moi ! 😉

Tweet about this on TwitterShare on FacebookGoogle+Share on LinkedIn

9 réflexions au sujet de « Devoxx: Les deux nouveaux candidats à la succession au langage Java »

  1. Ca parait risqué d’investir aujourd’hui sur autre chose que du Java pour une app à maintenir pendant plusieurs années (ce n’est pas le cas de toutes les apps bien sur).
    Dans la discussion du panel de vendredi matin, ça parait assez clair que java va rester le language principal pendant pas mal de temps (même s’il est moins bon techniquement). Donc heureusement qu’il va s’améliorer de son coté.

  2. Effectivement, la syntaxe de Scala est relativement complexe. Mais il ne faut pas perdre de vue qu’un sous-ensemble assez simple de Scala permet d’exprimer l’essentiel des constructions de Java. Scala est donc à la portée de tous les programmeurs. Et ces derniers pourront apprendre à maîtriser petit à petit les éléments plus complexes du langage, se retrouvant alors avec un réel bazooka pour attaquer certains problèmes plus complexes, ou simplement pour exprimer de façon fonctionnelle des constructions traditionnellement implantées de façon impérative. Il faut éviter de disqualifier Scala à cause de sa complexité car cette dernière est aussi une très grande richesse.

  3. Scala has many features, but that doesn’t make it complicated. Given the high consistency of it’s syntax, it is in some ways simpler than Java, especially for beginners.

  4. Ceylon, Kotlin et aussi Extend (de la fondation Eclipse) ont un noyau d’innovations quasi-commun:
    * Closure,

    * Inférence de type,

    * Simplification des accesseurs sur les propriétés,

    * Les Traits.

    Vu qu’il y a aussi d’autres langages du même acabit (Fantom, par ex), je vois un risque que les développeurs se “dispersent” dans ces diverses communautés. Et l’émergence d’un langage “tête de gondole” mainstream qui porterait haut l’étendard de ces innovations serait retardé, mais pas impossible.

    Bref, l’idéal serait que le JCP adopte le noyau d’innovations commun pour Java 8. De la sorte, ces langages ne ré-implémenteraient pas chacun dans leur coin ces innovations quasi-communes, ce qui n’empêcherait pas que chacun continue à développer des fonctionnalités innovantes hors ce noyau commun.

    Si la fenêtre de Java 8 est loupée, pour avoir un langage “tête de gondole” mainstream avec ces innovations, on risque d’être réduit à attendre (dans de nombreux cas business) la sortie de Java 9 ; autrement dit, une éternité par rapport au fait que C# dispose déjà de la plupart de ces innovations (sic).

      1. Ce n’est pas tout à fait ce que j’ai dis !

        1) ce qui est primordial ici, c’est qu’une majorité de langages dérivés de Java adoptent un ensemble de pot commun de fonctionnalités. Je crois qu’il est temps d’introduire ces fonctionnalités dans la prochaine version de Java, plutôt que ces designers de langage continuent à faire des choses quasi-identiques dans leur coin.

        2) il se trouve que certaines de ces fonctionnalités sont déjà dans C#.
        a) ce n’est pas une bonne idée de se priver de ces fonctionnalités en Java pour la “bonne” raison que C# les propose déjà !
        b) puisque je pense que ce sont des bonnes fonctionnalités à adopter au sein de Java, je continue à penser, légitimement, je crois, que les développeurs de C# auraient raison de se moquer de nous si on ne les adopte pas, non pas parce que ce sont des fonctionnalités de C#, mais parce que ce sont des fonctionnalités intéressantes, et IMHO, utiles.

Laisser un commentaire

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


*