Quel est l'objectif principal de Java? Pourquoi faut-il autant de temps pour obtenir de nouvelles fonctionnalités?


11

J'ai exploré les nouvelles fonctionnalités du JDK8, comme les expressions lambda, les méthodes d'extension et la nouvelle API de flux.

Évidemment, aucune de ces fonctionnalités n'est nouvelle dans le monde de la programmation et cela a amené à se demander pourquoi toutes ces choses sont en Java jusqu'à présent.

Nous avions des expressions lambda dans Lisp (1958), SML (1973), Haskell (1990), Python (1991), JavaScript (1994), Ruby (1995), Scala (2003), C # (2007) et 55 ans après Lisp et pratiquement tout le monde, dans Java (2013).

Et j'avais lu sur les streams dans SIC (1996).

Je me demandais pourquoi maintenant? Les preuves suggèrent que la concurrence avec d'autres langues n'est pas la motivation.

Il semblerait que toutes les nouvelles fonctionnalités intéressantes de cette version de Java ne soient qu'un sous-produit de l'implémentation du parallélisme. Nous avons des lambdas parce qu'ils simplifient l'écriture d'algorithmes parallèles, et nous avons des méthodes d'extension parce que nous en avions besoin pour prendre en charge les changements requis par les expressions lambda, etc., etc.

Donc, ma question est: pouvons-nous affirmer en toute sécurité que le sujet principal de cette prochaine version de Java est en fait le parallélisme? Ou peut-on justifier d'autres raisons de l'apparition des plus anciennes astuces du livre jusqu'à présent en Java?


4
Tout cela peut se transformer en une guerre des flammes à propos de l'arrière-plan de Java.
Michael K

5
The evidence suggests- veuillez partager vos recherches.

2
Aucune des fonctionnalités de Java, de la JVM ou du JRE n'était jamais nouvelle. Et même la combinaison de fonctionnalités n'est pas nouvelle, Eiffel en avait toutes en 1985 (GC, OO, sécurité de type, même des génériques que Java n'a pas obtenus jusqu'en 2003). En fait, l'objectif des concepteurs Java a été de ne rien introduire de nouveau.
Jörg W Mittag

2
@MichaelK - Je suis d'accord que cela pourrait se transformer en une guerre des flammes. Cela pourrait également se transformer en une réponse valable concernant l'histoire difficile de Sun; L'acquisition par Oracle de Sun et Java; et comment les mainteneurs actuels de Java tentent de piloter le langage. J'espère que les réponses se concentreront sur les aspects constructifs de cette question.

@MichaelT: J'espère que cela ne se transformera pas en une guerre des flammes et que des idées intéressantes pourraient émerger. Par exemple, nous supposons souvent qu'une langue qui n'évolue pas constamment est en retard. IMO ce n'est pas vrai car cela suppose que l'évolution du langage est linéaire (que toutes les nouvelles fonctionnalités qui deviennent populaires sont bonnes et devraient être adoptées par toutes les langues modernes). Mais les responsables d'une langue pourraient décider qu'une nouvelle fonctionnalité ne correspond pas au reste de la langue. Considérez également qu'il existe des langages standardisés et stables qui ne sont définitivement pas en retard (par exemple Common Lisp).
Giorgio

Réponses:


12

Lorsque Java a été conçu pour la première fois, il a été jugé approprié de supprimer les fonctions anonymes. Je peux penser à deux raisons (mais elles peuvent être différentes des raisons officielles):

  1. Java a été conçu comme un langage orienté objet sans fonctions, il n'était donc pas très naturel d'avoir des fonctions anonymes dans un langage sans fonctions. Ou du moins, cela aurait beaucoup influencé la conception de la langue.
  2. Les fonctions anonymes n'étaient pas populaires dans les communautés de programmeurs que Java était censé attirer (C, C ++, Pascal?). Même maintenant, de nombreux programmeurs Java semblent considérer ces fonctionnalités comme assez exotiques (mais cela changera probablement très rapidement avec Java 8).

Au cours des années suivantes, comme l'a expliqué Robert Harvey, la politique de Sun a toujours été de maintenir Java rétrocompatible et très stable.

D'autre part, d'autres langages concurrents sont apparus (le plus important étant C #, qui est né comme un clone Java et a ensuite pris sa propre direction de développement).

Les langages concurrents ont mis Java sous pression pour deux raisons:

Puissance expressive

De nouvelles fonctionnalités peuvent rendre certains idiomes de programmation plus faciles à écrire, rendant le langage plus attrayant pour les programmeurs. Normalement, l'ensemble des fonctionnalités fournies par un langage est un compromis entre puissance expressive, complexité du langage, cohérence de conception: l'ajout de fonctionnalités rend un langage plus expressif mais aussi plus complexe et difficile à maîtriser.

Quoi qu'il en soit, au cours des dernières années, les concurrents de Java ont ajouté de nombreuses nouvelles fonctionnalités que Java n'avait pas, et cela peut être considéré comme un avantage.

Engouement

Oui, malheureusement, c'est un facteur de choix technologique, du moins d'après ce que je peux voir dans mon expérience quotidienne en tant que programmeur: un outil doit avoir une certaine fonctionnalité, même si la plupart des membres de l'équipe ne savent pas comment l'utiliser et ceux qui pourraient l'utiliser n'en ont pas besoin la plupart du temps.

Le battage médiatique peut être encore plus important pour les personnes non techniques comme les gestionnaires, qui peuvent être ceux qui décident de la plate-forme pour un certain projet. Les gestionnaires ne se souviennent parfois que de certains mots clés comme lambda, parallélisme, multicœur, programmation fonctionnelle, cloud computing, ... Si notre technologie de choix a une marque verte sur chaque élément de la liste, alors nous sommes à jour.

Donc, l'OMI depuis un certain temps, Java a été pris entre

  • la politique originale de stabilité du langage et de simplicité de conception, une énorme base de code et une communauté de développeurs d'une part, et
  • la pression des langages concurrents qui pourraient attirer les programmeurs Java, C # au début, puis Scala, Clojure, F # (je nomme ceux que je connais, il peut y en avoir d'autres).

Finalement, Oracle a décidé de mettre à niveau Java pour le rendre plus compétitif. À mon avis, les nouvelles fonctionnalités s'adressent en particulier aux programmeurs Java qui pourraient être tentés de passer en C # et qui voient d'autres langages comme Scala et Clojure comme trop différents de Java. D'un autre côté, les développeurs qui ont une certaine expérience de la programmation fonctionnelle et qui souhaitent toujours utiliser la JVM sont probablement déjà passés à Scala, Clojure ou à un autre langage.

Ainsi, les nouvelles fonctionnalités de Java 8 rendront Java plus puissant en tant que langage et l'objectif déclaré est la programmation simultanée et parallèle, mais la mise à niveau semble également aborder les aspects marketing (Mark Reinhold, architecte en chef de Java chez Oracle, a déclaré: "Certains dire que l'ajout d'expressions Lambda est juste pour suivre les enfants cool, et il y a du vrai là-dedans, mais la vraie raison est les processeurs multicœurs; la meilleure façon de les gérer est avec Lambda ", voir cet article ).

Donc, oui, de nombreuses (toutes) fonctionnalités Java 8 étaient déjà bien connues, mais pourquoi et quand une fonctionnalité est ajoutée à un langage dépend de nombreux facteurs: public cible, communauté existante, base de code existante, concurrents, marketing, etc.

ÉDITER

Une brève note concernant "... j'avais lu des informations sur les flux dans SIC (1996).": Voulez-vous dire que vous avez besoin de lambdas Java 8 pour implémenter des flux? En fait, vous pouvez les implémenter en utilisant des classes internes anonymes.


+1 Et j'aimerais pouvoir vous donner plus de points car c'est la meilleure réponse à ce jour à la question.
edalorzo

Sur la base de votre réponse, j'ai enquêté davantage sur ce que Mark Reinhold avait dit avoir trouvé un article intéressant. Je vais le poster ici avec votre réponse pour référence future: Fermetures pour Java par Mark Reinhold .
edalorzo

Et cet article fait référence à celui-ci un autre Closures for Java .
edalorzo

1
À partir du lien que vous avez envoyé, j'ai trouvé cet ibm.com/developerworks/java/library/j-jtp03048/index.html#4.0 , disant que Java peut utiliser des classes internes anonymes, mais celles-ci sont trop verbeuses. Pourtant, la fermeture de Java 8 n'est pas seulement du sucre syntaxique pour les classes internes anonymes. Alors maintenant, Java aura DEUX (sémantiquement) différents types de fermetures: classes internes anonymes et expressions lambda.
Giorgio

11

Java a changé d'orientation avec le temps. Au début, il a été conçu comme un langage simple et puissant, en réaction à un C ++ «complexe puissant». Certaines fonctionnalités qui étaient en C ++ ont été intentionnellement omises, comme la surcharge des opérateurs, les modèles, les énumérations, qui ont été jugés trop compliqués ou des reliques de l'ère C, et la POO étant au sommet de sa popularité, tout a été transformé en objet en un seul. paradigme vision du monde. Les lambdas à cette époque étaient simplement considérés comme "non nécessaires" depuis l'introduction des classes anonymes / internes dans Java 1.1. Le fait que la syntaxe était beaucoup plus verbeuse était presque considéré comme une caractéristique .

Java ayant trouvé son public, il n'y avait aucune incitation à changer jusqu'à l'introduction par Microsoft de C #, qui a tiré les leçons des erreurs de conception Java et a lancé une série de nouvelles fonctionnalités de langage. Ils n'étaient pas contraints par une compatibilité ascendante. Je pense que les concepteurs Java ont réalisé le danger de la concurrence C # et libèrent Java 5 avec des génériques, des énumérations, etc.

L'inclusion de lambdas dans Java est discutée depuis ce temps et elle n'a été exacerbée que par la tendance actuelle à la programmation fonctionnelle. Mais des choses comme celle-ci sont lentes à s'arranger et il faut que ce soit bien la première fois. À mon avis, les génériques Java bâclés avec effacement de type parce que la compatibilité descendante était considérée comme une raison de l'implémenter comme rien de plus que du sucre syntaxique. Les fermetures ont été pensées de manière plus approfondie, semble-t-il, et ce sera plus que du sucre syntaxique.

En conclusion, quel est le sujet principal de Java 8? Je ne pense pas qu'une version linguistique ait un sujet. En tant que C ++ 11, la raison d'être de Java 8 est de suivre la concurrence en introduisant dans le langage les choses que de plus en plus de programmeurs tiennent pour acquis maintenant. Lisp a peut-être lambda depuis 1958, sa popularité a atteint un plateau depuis des décennies maintenant et ce n'est que récemment que la programmation fonctionnelle a été sérieusement envisagée pour la programmation «grand public» (faute d'un meilleur mot).


"Lisp peut avoir lambda depuis 1958, sa popularité a atteint un plateau depuis des décennies maintenant et ce n'est que récemment que la programmation fonctionnelle a été considérée sérieusement pour la programmation" grand public "": la popularité d'un langage ne semble pas être un bon indicateur de son efficacité. La programmation fonctionnelle est préconisée depuis de nombreuses années, mais la plupart des gens de l'industrie considèrent que c'est le genre de choses sur lesquelles les chercheurs aiment jouer pour rédiger leur thèse. Maintenant, tout d'un coup, l'industrie se réveille et lui donne une chance, peut-être parce que maintenant que la POO est grand public, ils sont à la recherche de la prochaine grande chose.
Giorgio

1
La raison pour laquelle les fermetures n'étaient pas initialement incluses dans Java selon: Comprendre le débat sur les fermetures . Là, James Gossling a déclaré: "Les fermetures ont été laissées hors de Java au départ plus à cause des contraintes de temps que toute autre chose. Au début de Java, le manque de fermetures était assez douloureux, et donc des classes internes étaient nées: un compromis inconfortable qui tentait d'éviter un certain nombre de problèmes difficiles. Mais comme c'est normal dans de nombreux problèmes de conception, les simplifications n'ont pas vraiment résolu les problèmes, elles les ont simplement déplacés. "
edalorzo

"L'inclusion de lambdas dans Java est discutée depuis ce temps et n'a été exacerbée que par la tendance actuelle de la programmation fonctionnelle.": Je trouve intéressant que dans certaines communautés (C ++, Java, ...) "utiliser des lambdas" signifie souvent " faire de la programmation fonctionnelle ".
Giorgio

8

Évidemment, aucune de ces fonctionnalités n'est nouvelle dans le monde de la programmation et cela a amené à se demander pourquoi toutes ces choses sont en Java jusqu'à présent.

Parce que Java doit passer par un processus d'approbation qui implique plusieurs parties prenantes à haute visibilité dans un processus semblable à la «conception par comité», et ce processus prend du temps, c'est tout.

Comparez cela avec d'autres langues et vous trouverez soit un dictateur bienveillant, soit un petit comité de concepteurs linguistiques qui travaillent en étroite collaboration et ne sont pas liés aux intérêts de l'entreprise.

Combinez cela avec une base de code établie de millions de lignes de code Java qui doit rester rétrocompatible, et vous avez tous les ingrédients du changement à un rythme glacial.


1
OTOH, vous avez également les ingrédients de normes vraiment fortes et largement acceptées. Comparez, par exemple, JPA à la situation de PHP, où chaque framework web a son propre ORM à demi-cul.
Michael Borgwardt

Je me trompe peut-être, mais d'après ce que je comprends, Haskell est également un langage de «conception par comité», et c'est un langage de pointe. Alors peut-être que ce n'est pas ce qui empêche Java?
Andres F.

@AndresF. Oui, mais j'imagine que vous n'avez pas de grandes sociétés monolithiques siégeant au comité Haskell. Voir également la conversation dans les commentaires ici .
Robert Harvey

1

Je dirais que l'objectif le plus important d'un langage de programmation est d'être utilisé; actuellement C et Java n'ont pas d'expressions lambda et ce sont les langages les plus utilisés (selon TIOBE par exemple).

Et pour répondre à la question, je crois que Java s'adresse à l'entreprise; dans ce domaine, les choses doivent être très stables et fiables; par exemple, Java 7 est apparu depuis près de 2 ans, mais je ne connais pas directement de projet en Java 7. Une autre chose importante est la compatibilité descendante qui est très importante pour l'entreprise.


Je suis d'accord avec vous (+1): j'apprécie beaucoup Java (en tant que langage et pour son immense écosystème) mais j'aurais trouvé plus approprié de geler le langage à Java 6. Je ne vais pas faire d'effort dans l'apprentissage Java 7 ou 8, sauf si je suis obligé de le faire (un projet très intéressant dans lequel Java 7 ou 8 est un must), je préfère passer mon temps à apprendre Scala et Clojure.
Giorgio
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.