You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bcel-user@jakarta.apache.org by Nick Hynes <Ni...@peace.com> on 2003/05/20 02:02:39 UTC
Intra-method dependencies...
Hi all,
I need to build a dependency analyser that is able to work at the method level. Most dependency tracers work at the package and class level, and are targeted at build tools. I need to identify which methods call other methods within our product (for smoke testing purposes).
On first sight it appears like a not-too-hard problem to solve. I anticipate simply using the static constraints part of the package (using the JavaClass, Method and Code objects, and probably the ConstantsPool). The Code would need to be split into instructions, and then you would need to search for the invokestatic, invokevirtual, invokespecial and invokeinterface opcodes.
Does this seem like a reasonable implementation?
Am I re-inventing the wheel (has this been done elsewhere/before)?
Would Code.accept( Vistor ) be of use here?
- Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-user-help@jakarta.apache.org
Re: Intra-method dependencies...
Posted by Laurent Martelli <la...@bearteam.org>.
>>>>> "Nick" == Nick Hynes <Ni...@peace.com> writes:
Nick> Hi all,
Nick> I need to build a dependency analyser that is able to work at
Nick> the method level. Most dependency tracers work at the package
Nick> and class level, and are targeted at build tools. I need to
Nick> identify which methods call other methods within our product
Nick> (for smoke testing purposes).
Nick> On first sight it appears like a not-too-hard problem to
Nick> solve. I anticipate simply using the static constraints part
Nick> of the package (using the JavaClass, Method and Code objects,
Nick> and probably the ConstantsPool). The Code would need to be
Nick> split into instructions, and then you would need to search for
Nick> the invokestatic, invokevirtual, invokespecial and
Nick> invokeinterface opcodes.
Nick> Does this seem like a reasonable implementation?
To me, it does.
Nick> Am I re-inventing the wheel (has this been done
Nick> elsewhere/before)?
I recently added this feature to the JAC (http://jac.aopsys.com/)
bytecode analysis component. It's not really usable outside of JAC for
the moment, but you can still have a look at the code (it's under
LGPL) in cvs:
http://jac.aopsys.com/cgi-bin/viewcvs.cgi/jac/src/jac/core/translators/WrappeeTranslator_BCEL.java
(see the fillRTTI() method)
--
Laurent Martelli http://jac.aopsys.com/
laurent@bearteam.org http://www.bearteam.org/~laurent/
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-user-help@jakarta.apache.org