MethodHandle - qu'est-Ce que c'est?

Je suis étudient de nouvelles fonctionnalités de JDK 1.7 et j'ai juste ne peux pas obtenir ce que MethodHandle est conçu pour? Je comprends (direct) invocation de la méthode statique (et l'utilisation de Base de la Réflexion de l'API qui est simple dans ce cas). Je comprends aussi (direct) invocation de la méthode virtuelle (non statique, non-final), et l'utilisation de Base de Réflexion à une API qui nécessite de passer par la Classe de la hiérarchie obj.getClass().getSuperclass()). L'Invocation de la non-méthode virtuelle peuvent être traités comme des cas particuliers de l'ancien.

Oui, j'ai conscience qu'il y a un problème de surcharge. Si vous voulez appeler la méthode que vous avez à fournir l'exacte signature. Vous ne pouvez pas vérifier la méthode surchargée de manière simple.

Mais, qu'est-ce que MethodHandle sujet? La réflexion de l'API vous permet de "voir" l'objet internes, sans aucune pré-prise en charge (comme la mise en œuvre de l'interface). Vous pouvez inspecter l'objet pour un certain but. Mais qu'est-ce que MethodHandle est conçu de trop? Pourquoi et quand dois-je utiliser?

Mise à JOUR: je suis en train de lire ce http://blog.headius.com/2008/09/first-taste-of-invokedynamic.html article. Selon elle, l'objectif principal est de simplifier la vie des langages de script qui s'exécute au sommet de la JVM, et pas pour le Langage Java lui-même.

Mise à JOUR-2: j'ai fini de lire le lien ci-dessus, quelques devis à partir de là:

La JVM va être le meilleur de la VM pour la construction dynamique des langues, car il est déjà un langage dynamique VM. Et InvokeDynamic, par la promotion de la dynamique des langues à la première classe de la JVM des citoyens, va le prouver.

En utilisant la réflexion d'invoquer des méthodes fonctionne très bien...sauf pour quelques problèmes. Méthode objets doivent être récupérées à partir d'un type spécifique, et ne peut pas être créé de manière générale.<...>

...reflète l'invocation est beaucoup plus lent que l'invocation directe. Au fil des ans, la JVM a obtenu très bien reflété l'invocation rapide. Moderne Jvm effectivement générer un tas de code en coulisses pour éviter une grande partie de la surcharge de vieilles machines virtuelles sous traitées. Mais la simple vérité est que reflète l'accès par le biais de n'importe quel nombre de couches toujours plus lent qu'un appel direct, en partie parce que le complètement generified "invoquer" la méthode doit vérifier et re-vérifier le type de récepteur, types d'arguments, de la visibilité, et d'autres détails, mais aussi parce que tous les arguments doivent être des objets (donc des primitives obtenir l'objet en boîte) et doit être fourni comme un tableau à couvrir toutes les arities (ainsi les arguments obtenir tableau encadré).

La différence de performance ne peut pas d'importance pour une bibliothèque à faire quelques reflète les appels, en particulier si ces appels sont pour la plupart à définir de façon dynamique en place une structure statique dans la mémoire à l'encontre de laquelle il peut faire un appel normal. Mais dans un langage dynamique, où chaque appel doit utiliser ces mécanismes, c'est une grave dégradation des performances.

http://blog.headius.com/2008/09/first-taste-of-invokedynamic.html

Donc, pour le programmeur Java c'est essentiellement inutile. Suis-je le droit? De ce point de vue, Il peut être considéré que comme un moyen alternatif de Base de l'API Reflection.

  • Non, absolument pas. Ce poste est de plus de 3 ans. Un grand nombre de cadres développeurs s'intéressent de près aux MH et invokedynamic et des moyens de l'utiliser pour aider les développeurs.
  • Pouvez-vous fournir un exemple d'une telle utilisation? Ce qui est possible de faire avec MethodHandle qui est impossible à faire avec le Noyau de la Réflexion de l'API?
  • Par exemple, l'interaction avec un gestionnaire de sécurité. setAccessible() va vous tuer sous un responsable de la sécurité, tandis que le mécanisme de Recherche est complètement sûr. De recherche vous permet également de créer un MH dans un contexte où vous pouvez le voir, et ensuite passer la référence aux contextes défavorisés.
  • Pratiquement, je n'ai jamais de problèmes avec setAccessible(). En théorie je peux utiliser AccessController.doPrivileged(new PrivilegedAction() idiome.
  • C'est peut-être utile de prendre un coup d'oeil à en.cppreference.com/w/cpp/utility/functional/function
InformationsquelleAutor alexsmail | 2012-01-11