Kohsuke Kawaguchi wrote:
Actually your above example should be quite simple, especially if
we can assume that we know local variable types (e.g. debug
information is available):
Well, sure, if you can use debug information, but I don't think we can
assume that in javaflow, can we.
It depends. But in general you probably right. :-)
Though more complicated case would be the case when restoring stack
not directly used by the currently restoring method. Probably
something similar to what happening for NEW opcodes. And for this we
will have to always search for common super class or interface.
OK, sounds like we are in agreement that we sometimes do need to compute
the base class.
Right. BTW, SimpleVerifier is actually doing this already using
Class methods.
Though there is some tricky scenario that would be difficult to
handle. This is in case when two classes would have more then one
common interface (e.g. both implements Comparable and Externalizable)
and don't have common super class. Eric left a comment in
SimpleVerifier code about this scenario and I am not sure how this can
be resolved.
It shouldn't be too difficult; BCEL does that. As I wrote in the
commit message, all we need is a resolver that can get you the byte
code image of those referenced classes (like ClassX and ClassY.)
We have code for this within ASM test cases. It is in
MUSTANG_SUPPORT branch in org.objectweb.asm.ClassWriterTest3 class. If
you like I can try to put this code into SimpleVerifier subclass
already used in javaflow.
That would be great.
Will do that and then depends from the results of your testing I
can look at implementing algorithm based on dataflow only.
regards,
Eugene
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
