Méthodes d'extension virtuelle dans la prochaine version de Java 8

Question

Quand je vois des extraits de code comme

  interface A {
      void a();
      void b() default { System.out.println("b"); };
      void c() final { System.out.println("c"); };
  }

J'ai une question. N'avons-nous pas déjà eu assez de sh * t en java? Pourquoi pourrait-on en avoir besoin?

Answer 1

Je vous suggère de regarder cette conférence: http://medianetwork.oracle.com/media/show/16999

Cela explique tout. La chose la plus intéressante à faire est de permettre à une interface d'évoluer sans réécrire toute votre base de code. Ceci est la clé pour permettre à une grande base de code d'évoluer et de ne pas devenir de plus en plus paralysée.

Answer 2

Nous en avons besoin car cela rendra les gars de Scala absolument furieux. Ils ont déjà des fonctionnalités assez similaires sous la forme de «traits», alors maintenant ils devront les faire fonctionner avec ceux-ci.

Pisser les gars de Scala est littéralement la priorité la plus élevée du développement de la langue Java.

Answer 3

Il est prévu que Java 8 contiendra une certaine forme de support de lambda et de fermeture, ce qui serait un grand pas dans la modernisation de la langue java. Le problème est que les bibliothèques existantes basées sur les interfaces, comme le cadre de collection, ne pourront pas utiliser directement ces nouvelles fonctionnalités. Il n'est pas possible d'ajouter une méthode à une interface sans casser les implémentations existantes, ils ne se compileraient plus.

Avoir des lambdas, mais ne pas pouvoir les utiliser facilement avec des collections standard, serait une énorme déception pour les développeurs Java. Pour intégrer les lambdas dans les collections standard, des méthodes comme forEach, map, ou filter serait hautement souhaitable.

La solution à ce problème consiste à ajouter une autre fonctionnalité, des méthodes d'extension, qui définissent une implémentation par défaut d'une méthode dans une interface. Les sous-classes existantes utiliseraient la méthode par défaut, mais il est également possible de remplacer la méthode avec une meilleure implémentation spécialisée et possible.

Plus d'informations sur la proposition de la méthode d'extension peuvent être trouvées à Proposition d'amélioration Java 126.

Answer 4

C'est génial car il vous permet, l'écrivain API d'étendre les interfaces post-hoc sans provoquer de nooshmethoderrors. Vous fournissez également des implémentations par défaut pour les méthodes en V2 pour les classes compilées avec V1; Le code fonctionne comme un charme. Cela vous permet également de remplacer l'implémentation par défaut dans les classes compilées avec V2 comme d'habitude, et rend les inter-Afces numérotés redondants. Je le considère également supérieur que les méthodes d'extension du site d'utilisation.

Answer 5

Je crois que le concept "méthodes d'extension" n'est rien de plus que la dernière chance de pirater / réparer des API mal conçues qui ont été exposées au "monde externe". Juste sucre syntaxique.