Re: ClassFileTransformer and ClassWriter
Remi Forax <[email protected]> Sun, 5 Mar 2017 12:30:30 +0100 (CET)
| Newsgroups | gmane.comp.java.objectweb.asm |
|---|---|
| Message-ID | <[email protected]> |
Hi ! ----- Mail original ----- > De: "offbynull-asm" <[email protected]> > À: [email protected] > Envoyé: Samedi 4 Mars 2017 23:23:26 > Objet: [asm] ClassFileTransformer and ClassWriter > I noticed that if ClassFileTransformer.transform() calls Class.forName() > for a class that hasn't been passed to that transformer yet, that class > will never get passed to that transformer. > > It looks like ClassWriter uses Class.forName() when it computes frames. > How is it that people can use ClassWriter within a ClassFileTransformer > without running in to this problem? Is there special logic somewhere in > ASM that handles this? If you want to write Java 1.6 compatible code, you have to generate stackmap frames, ASM can do that for you but it needs to know how to find the common supertype of two types, this is needed by example when you merge variables that comes from the two branches of an if (if you know the SSA form, you need that everywhere you have a phi). ASM provides a default implementation, ClassWriter.getCommonSuperType() that relies on Class.forName, which as you said is not something you should do if you are inside a ClassFileTransformer (which is not re-entrant). To cope with that issue, you can load the classfile using classloader.getResources(), use ASM to find the supertypes and compute the common super types. But i suppose that you already know all of this, (you are the author of coroutines, right ?) so to answer to your question, no, ASM does not provide any code for dealing with that, you have to write your own. The other solution, which i think in your case is the right solution, is to not ask ASM to generate the stackmap for you, but read the existing stackmap and patch them (in MethodVisitor.vuisitFrame), it's painful, but in your case, it's the only way i see to do your transformations properly. ASM can call visitFrame with two forms: - the compressed form which is how a frame is encoded in the bytecode (the stackframe may be defined as the delta from the last stackframe in the bytecode), this form is not suitable for patching - the expanded form, which get you the types of the local variables + stack which is easier to patch. To get the expanded form, you have to pass EXPAND_FRAMES to the ClassReader. regards, Rémi -- You receive this message as a subscriber of the [email protected] mailing list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help OW2 mailing lists service home page: http://www.ow2.org/wws