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