Quel sera l'impact des fermetures en Java sur la communauté Java?


11

C'est l'une des fonctionnalités les plus discutées prévues pour Java: les fermetures. Beaucoup d'entre nous les attendaient. Certains d'entre nous (dont moi) sont devenus un peu impatients et se sont tournés vers les langages de script pour combler le vide.

Mais, une fois que les fermetures sont finalement arrivées à Java: comment affecteront-elles la communauté Java? L'avancement des langages de script ciblés par VM ralentira-t-il pour une analyse, restera-t-il le même ou accélérera-t-il? Les gens vont-ils affluer vers la nouvelle syntaxe de fermeture, transformant ainsi les bases de code Java tout autour en implémentations plus structurées? Verrons-nous uniquement des fermetures en Java? Quel sera l'effet sur le support des outils / IDE? Et la performance? Et enfin, qu'est-ce que cela signifie pour l'adoption continue de Java, en tant que langage, par rapport à d'autres langages qui gagnent en popularité?

Pour fournir un exemple de l'une des dernières spécifications de syntaxe Java Closure proposées:

public interface StringOperation {
   String invoke(String s);
}

// ...

(new StringOperation() {
   public invoke(String s) {
       new StringBuilder(s).reverse().toString();    
   }
}).invoke("abcd");    

deviendrait ...

String reversed = { 
    String s => 
    new StringBuilder(s).reverse().toString()
  }.invoke("abcd");

[source: http://tronicek.blogspot.com/2007/12/closures-closure-is-form-of-anonymous_28.html]


L'exemple que vous publiez date d'il y a de nombreuses années - êtes-vous sûr qu'il est représentatif des propositions actuelles?
Daniel Earwicker

Ce n'est peut-être pas le cas: n'hésitez pas à réviser mon exemple

3
J'ai plus ou moins cessé d'utiliser Java récemment. J'attends toujours avec impatience les fermetures.
Anto

@Daniel - ce n'est pas la proposition actuelle, il semble y en avoir une plus actuelle (et très différente) ici: baptiste-wicht.com/2010/05/…
Nicole

est-ce comme l'expression lambda C #?
Louis Rhys

Réponses:


4

Je pense qu'il faudra un certain temps à de nombreux développeurs Java `` ordinaires '' pour se familiariser avec ce concept s'ils ne le connaissent pas déjà, mais progressivement, il facilitera l'utilisation régulière de Java, à notre avantage. Ce serait formidable s'il était adopté aussi rapidement que les génériques lorsque Java 5 est arrivé.

J'imagine que cela n'affectera pas les langages de script ciblés par VM, car ce n'est qu'un avantage de l'utilisation de ceux qui l'ont.


3

Il y a un cycle habituel qui va avec tout nouvel outil brillant:

  • Excitation de masse, avec une vague de nouveaux utilisateurs en abusant. C'est normal et sain, car cela nous aide à comprendre les limites du nouvel outil et comment il peut être utilisé.
  • Des personnes plus réservées vont dire et considérer les premiers adoptants comme des idiots
  • Finalement, l'excitation s'estompe et les premiers adoptants s'installent sur des façons saines d'utiliser le nouvel outil
  • Des personnes plus réservées commenceront à envier la productivité des personnes utilisant le nouvel outil, et commenceront à l'adopter - en utilisant les modèles désormais sains.

Tout cela prend quelques années à parcourir. Cela était vrai pour les annotations et les génériques, et ce sera également le cas pour les fermetures.

Impact sur les gens du langage de script:

  • Pour les langues qui prennent en charge les fermetures, cela aidera les rédacteurs de langage de script à faire leur travail plus efficacement. Puisqu'ils savent déjà utiliser les fermetures, ils ne feront pas nécessairement des choses folles.
  • Pour les langues qui ne prennent pas en charge les fermetures, cela sera largement ignoré.

1

Ceux qui aiment la programmation multithread seront en mesure d'incorporer des structures de données immuables dans Java et de les gérer de manière plus lisp sans avoir besoin de recourir à des non-séquenceurs en raison de l'inadéquation de l'impédance du langage entre Java et Lisp.

Ceux qui n'utilisent (ou ne comprennent) aucun des éléments ci-dessus pourront faire les choses comme ils le faisaient auparavant.


1
Cela n'a aucun sens. Les fermetures n'ont rien à voir avec le filetage ou la mutabilité.
davidk01

Ils font. Des fermetures appropriées nécessitent une immuabilité pour fonctionner sans explosions cérébrales.
permeakra

Non, ils ne le font pas. Une fermeture est un morceau de code qui connaît l'environnement dans lequel elle a été créée.
davidk01

1
@ davidk01 la définition est OK, mais lorsque la fermeture a un lien avec une variable mutable, son résultat change avec la variable modifiée. Habituellement, ce n'est pas ce que l'on veut, mais si le compilateur ne s'y oppose pas, l'erreur est presque indétectable.
permeakra

1
@ davidk01 Non, je ne le fais pas. Mon point est que les fermetures / lambdas fonctionnent bien si elles sont liées avec l'immuabilité des variables capturées. Sinon, vous êtes à la merci de Tzeentch, et seuls les fidèles dévoués ont des chances ici.
permeakra

1

Je soupçonne que les gens qui connaissent les fermetures commenceront à les utiliser dans le code d'application. Ils les éviteront dans les bibliothèques pendant un certain temps pour maintenir la compatibilité descendante avec les anciennes versions de Java.

Les programmeurs qui ne connaissent pas les fermetures d'autres langages seront lents à les adopter en Java.

Les génériques ont été adoptés rapidement lorsqu'ils ont été introduits dans Java, en partie à cause de tous les avertissements qui se sont présentés lors de la mise à niveau et à cause de leur incorporation dans le SDK. Ce ne sera pas vrai avec les fermetures. Il sera plus difficile de trouver des preuves de leur existence, donc seuls ceux qui veulent les utiliser les utiliseront.

Je ne pense pas que le développement d'autres langages de script JVM s'arrêtera. Ces langues ont une dynamique et beaucoup de fonctionnalités en plus des fermetures. Nous pouvons cependant voir moins de nouveaux langages JVM car les fermetures ont été le principal moteur de la création de nouveaux langages JVM.


Vous devriez jeter un œil à mseifed.blogspot.se/2012/09/… Je pense que c'est assez génial!
mmm
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.