> Are there convenient ways within BCel to identify points in methods where
> users can safely insert code. My thoughts are that given a method, can I
> identify things like all return statements, exception exits from the method
> and possibly System.exit(). I also realise that in the case of <init> there
> is some code which must be first (the new and the call to super()). There
> may be other examples which I haven't come across.
BCEL presents the bytecode as a stream. In certain fragments of bytecode, it
is not valid to insert code as individual bytecodes in the fragment contribute
to a particular task (e.g., stacking the parameters to a method) and to
interrupt this with other bytecode with make the fragment incorrect.
Therefore, *in the general case*, identifying the points is going to be
difficult.
However, your can identify all return statements easily by looking through the
bytecode list for instances of org.apache.bcel.generic.ReturnInstruction.
For the exception exits you need to look at MethodGen and its
GetExceptionHandlers method call and the CodeExceptionGen object which tells
you about where in the code the exception starts from, (the first statement
inside the try{) where it ends (the } ending the try {) and where its handler
(the catch statement in Java source code) starts.
With my Sun Java compiler, System.exit turns into:
System.exit(2);
// 6 8:iconst_2
// 7 9:invokestatic #4 <Method void System.exit(int)>
so you just need to search for an invoke static with the above signature,
i.e., called on System, the methods called exit and it takes a single integer
and passes back void.
I found out the about by writing System.exit(2) in a program, compiling it and
then running it through jad (kpdus.tripod.com/jad.html) to see what bytecode
was generated. I recommend you use this approach when you need to find out
what something looks like at the bytecode level.
BCEL provides you with ample ways of searching for bytecode as the class
hierarchy it defines reflects the bytecodes very well, e.g., ReturnInstruction
above is the superclass for all return types, such as ARETURN and IRETURN.
> A possible facility could be....
>
> InstructionHandle MethodGen.getEntry();
> InstructionHandle[] MethodGen.getExits();
You could provide these yourself, by subclassing MethodGen and building the
getEntry and getExits methods yourself.
> Are there any other approaches which I could take?
I've just seen Burt's email, if this facility has already been created which I
would find useful, could it be added to the standard distribution?
Huw
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>