Le défi des lambda-fonctions en PHP étant lâché, voyons un peu ce qu’en pensent les développeurs Java …

Jean-François nous donne le fameux code le plus « approchant » en Java :

Les collections apache offrent CollectionUtils et -typage oblige- des interfaces représentant les concepts de traitements.

le code le plus approchant d’une lambda-fonction en Java ressemble à ça :

Collection noms = CollectionUtils.collect(personnes, new Transformer(){
  @Override
  public Object transform(Object p) {
    return ((Personne) p).getNom();
  }
});

Malheureusement ces classes ne sont pas génériques, ce qui est dommage car ça éviterait des transtypages explicites (oui bon, ok on se la pète … des « cast » quoi).

Ce qu’on peut noter :

• - il faut aller chercher des packages complémentaire pour faire ça (ce n’est pas naturel dans le langage)
• - on retrouve ce qui m’énerve le plus dans Java : des méthodes statiques dans des classes utilitaires (c’est à dire du bon vieux procédural)
• - la syntaxe est un peu lourde (classe interne anonyme) mais on peut aussi se coder ses Transformer comme des classes normales et réutilisables
• - autre truc énervant de java : un tableau n’est pas une instance de collection d’où d’autres api éparpillées pour convertir tableau-collection

Guillaume, le plus fervent défenseur de Java chez Oxiane va faire semblant de rendre les armes pour asséner le meilleur argument fort pour Java : les outils de développement.

« J’ai beau prendre la défense de Java systématiquement, c’est objectivement un point faible du langage, il n’y a pas vraiment moyen de lutter. L’absence de lambda est pénible parfois (parfois seulement, hein, il existe des constructions syntaxiques un peu plus lourdes mais qui rendent la fonction).

N’oublions pas que Java est un langage limité à la base, avec deux innovations : le classloader et le mot-clé synchronized. Des choses comme la VM et le GC existaient bien avant. Il n’y a pas de lambdas, pas de mixin, les génériques sont apparus tardivement, etc, etc… C’est une question d’outillage (Eclipse pour ne pas le nommer). Le jour ou un autre langage est mieux outillé que Java, je suis près à changer de langage de prédilection ! (langages libres, hein, Visual Studio .net ne compte pas).

Ce qui me fait dire ceci : on devrait arrêter d’inventer des langages ruby, python, groovy, scala, php5, php6, en jouant à celui qui aura la plus longue liste de features. Je pense que le principal critère de survie d’un langage en entreprise est « l’outillabilité ». Le reste n’a pas une grande importance. »

Mikaël aime bien faire le programmeur de base et va provoquer un peu nos brillants développeurs du siècle dernier :

« Scala c’est basé sur Java, non, et ça tourne sur la JVM ?
Et dites-moi si je me trompe, mais les programmes Groovy sont compilés en bytecode Java.
Donc, en théorie, l’outillage pour Java devrait fonctionner pour ces 2 langages, non ? »

Oui mais -à priori- la réponse n’est pas si simple

Jean-François nous rappelle un truc essentiel vis à vis de Java :

« Java c’est aussi et surtout son bytecode (qui a la particularité d’être sécurisé très spécialement par rapport aux autres technologies similaire).
La force de Java réside dans son orientation « production » (performance, monitoring, sécurisation, etc.).
Le reste (la syntaxe), c’est pour les développeurs et ça a toujours été jugé secondaire.
Du coup, c’est difficile de savoir de quoi on parle quand on dit « Java ».
Pour l’outillage, Guillaume parle surtout de syntaxe, Scala et autres sont basés sur le bytecode donc pas d’outillage pour les développeurs mais les outils des exploitants sont bien effectifs.
CQFD »

Mikaël :
« Donc en gros Java c’est juste un bon assembleur ?

Je viens de voir qu’en Groovy on peut écrire:

["Rod", "Carlos", "Chris"].findAll{it.size() <= 4}.each{println it}

Une syntaxe simple qu’on comprend tout de suite, c’est un bon signe.

Guillaume répond à Jean-François et en remet une couche sur l’environnement de développement surpuissant autour de Java:

« … mais ni l’orientation « production », certes importante, ni le bytecode, ne peuvent justifier l’utilisation de Java comme langage compilé en Javascript dans GWT et vers VM spécifique sur Android. L’approche de Google est bien de considérer Java-la-syntaxe-et-les-librairies comme ubiquitaire, pas la VM. La grande force de GWT c’est Eclipse, son débugger, Maven, PMD et checkstyle ! C’est bien là que se situe l’attrait de Java.

Pour répondre à Mikael, Groovy et Scala génèrent du bytecode pour la JVM, mais mon JDT, ma complétion, mes normes, mon PMD, mon Checkstyle, mes exemples de code sous Google, mes habitudes de codage, tout ça je ne les ai plus ! C’est ce que je reprochais à Groovy dans un emploi antérieur : les gains en lisibilité (sucres syntaxiques principalement) ne compensent pas les pertes en outillage (la liste ci-dessus). Résultat : productivité moins bonne. Ce n’est justement pas qu’une question de syntaxe.

Le jour où Scala (le SDT ?) sera aussi bien que le JDT, et tous les autres outils au niveau, vous ne m’entendrez plus parler de Java. Ou alors en mal seulement, tel un smalltalkeur. »
dont acte ;-)

Histoire qu’il y ait une suite (et conclusion), remercions le troll Mikaël :

« Allez, débat: Y a t-il un langage qui parviendra à combiner les avantages d’un langage haut niveau (Smalltalk, PHP, Ruby, etc.) et les qualités de la JVM ? »

(à suivre) …