Quelqu'un où je travaille remarqua (dans StackTrace) que lors de la course JVM avec -javaagent: Spring-Instrumentation.jar Mes cours annotés Jaxb ont d'étranges nouvelles méthodes dans lesquelles nous n'avons pas écrit: E.G. CertainesJaxBannoTatedClass $ Jaxbaccessorm_getfields_Setfields_JAVA_UTIL_SET.GET
Cela signifie-t-il que JAXB utilise l'instrumentation byTecode lorsqu'elle est disponible? Où puis-je en savoir plus sur cette fonctionnalité?
merci, YUVAL
4 Réponses :
Dernière vérité, JAXB utilise la réflexion pour générer des classes basées sur le XML que vous fournissez (bien que je ne l'ai pas utilisée depuis quelque temps, ils auraient donc changé de méthodologie).
Je sais que JIBX , d'autre part, utilise BCEL Pour effectuer une instrumentation byTecode. Voici un article sur ce: http://www.ibm.com/ DeveloperWorks / Java / Bibliothèque / J-CWT09065 / .
Je sais que tout sur Jibx l'a utilisé et subi toutes les minutes de devoir courir la compilation post, j'ai été surpris de voir Jaxb faire quelque chose qui ressemblait à une injection de bytecode, mais je suppose que j'avais tort ...
Lorsque le Fait intéressant, vous pouvez désactiver ce comportement en définissant une propriété système non documentée, ce qui améliore le démarrage du contexte, au détriment des performances d'exécution.
EDIT: Je dois souligner que c'est ce que la mise en œuvre de la référence JAXB Sun JaxB sous les couvertures ne fait pas partie de la spécification JAXB. D'autres implémentations sont libres de faire ce qu'ils choisissent. jaxbcontext démarre, il effectue une grande quantité d'opérations de réflexion, de pré-cacher tout ce que cela aura plus tard besoin. Ceci est fait pour des raisons de performance. Je ne suis pas sûr de ce que cela fait exactement, mais je m'attendrais à ce qu'il effectue une sorte de logique de génération de classe d'exécution, car cela sera plus rapide au moment de l'exécution que la réflexion brute.
+1 Pour mentionner qu'il pourrait y avoir des implémentations différentes implémentées différemment!
juste une addition à la poste de Skaffman:
Ce que vous voyez (quelquejaxbannotationClass $ Jaxbaccessor ...) est une classe intérieure, qui est générée de manière dynamique par la mise en œuvre de la référence JAXB. Pour prévenir la surcharge de réflexion au moment de l'exécution, Bytecode pour les implémentations concrètes de la classe Ainsi, la mise en œuvre de la référence JAXB ne constitue pas l'instrumentation de la byTecode en ce sens qu'elle modifie les classes existantes, mais génère de nouvelles classes pour des performances d'exécution optimisées. com.sun.xml.bind.v2.runtime.beflect.accessor est générée et injectée dans le chargeur de classe actuel en invoquant Classloader.defineclass (String, octet [], int, int), après avoir utilisé la réflexion pour contourner le modificateur d'accès protégé de la méthode de définition.
Merci d'avoir fait cela clair, je suppose que j'ai confondu les classes intérieures avec des méthodes ajoutées et imaginaient que l'instrumentation printanière pourrait avoir quelque chose à voir avec cela. Ce que vous décrivez fait beaucoup plus de sens :)
Comme mentionné par Skaffman, vous pouvez désactiver la génération de toutes ces classes internes en définissant la propriété système: com.sun.xml.internal.bind.v2.runtime.jaxbcontextextimpl.fastboot = true
Bien sûr, il n'est pas documenté, mais cela n'a pas changé depuis des années.