Hi Bil
I'm not really sure about what your using the LocalVariableTable for do
you need to know about all local variables or only those that hold the
parameters to the method? If you only need the parameters then I'd be
extracting these from the signature, but if you need the types of all
LocalVariables I can see why it would get complicated.
I/We have done something like this before though using ControlFlowGraph,
InstructionContexts and some other classes in
org.apache.bcel.verifier.structurals.* these let you perform a
simulation of execution (recursively following different branches)
during which you could inspect the Stack and record the types associated
with various instructions encountered in for instance a HashMap. One
problem I found is that the JustIce verifier found the descriptions
about what was a legal subroutine vague and made it's own
interpretation, therefore it sometimes comes up with errors (Exceptions)
in what you expect to be legal code. The only way I have found to avoid
this is to modify the Subroutines class and remove the throwing of
exceptions, you could catch the exception but this leaves the
Subrountines and ControlFlowGraph structures improperly initialized.
(Still it's not such a nice solution if you know a better one let me
know please)
I hope this helps
Bye Arrin
PS: We were interested in the types being put into multi dimensional
arrays but I imagine you could capture the types going into
LocalVaraibleInstructions in much the same way.
Bil Lewis wrote:
Arrin, et. al.,
I spent a little time hacking around, trying to see if I could finesse
the problem.
It wasn't pretty.
Either I have gobs of little special cases distributed throughout my
code, or I find
a way to make the LVT reflect reality. The former is a disaster. The
latter involves
modifying BCEL.
As other folks have probably run into this, perhaps it's already been
done?
-Bil
=========================
Hi Bil
My understanding is that the Local Variable Table is an optional
inclusion with a method.
A method does not need to have a Local Varible Table, If it does have
a LVT I am not sure whether or not it is required to be correct.
I don't know the specifics of your project but it might be worthwhile
considering the possibility that some code will not have a local
variable table at all or if it is the information in the local
variable table is incorrect.
org.apache.bcel.generic.Type has a couple of static methods which
convert either type signatures to a Type object or a method signature
to an array of Types. (see getType(String) and
getArgumentTypes(String)) these mean you don't have to manually parse
the method signature.
Hope this helps
Bye Arrin
Bil Lewis wrote:
Hi all.
I've just been trying to update my code to run on code compiled
under 1.5.
Almost everything works flawlessly. Just this one thing...
For code like this:
static void startTarget(Class clazz) { // Only called from event
thread.
final Class clazzz = clazz;
new TestInnerClass() {
public void run() {
Class c = clazzz;
}
};
}
where the variable clazzz must be passed to the inner class
TestInnerClass$1, the 1.5
compiler does not include it in the LVT, unlike 1.4. Here's the
constructor in question:
TestInnerClass$1(java.lang.Class);
Signature: (Ljava/lang/Class;)V
Code:
0: aload_0
1: aload_1
2: putfield #11; //Field val$clazzz:Ljava/lang/Class;
5: aload_0
6: invokespecial #14; //Method TestInnerClass."<init>":()V
9: return
LineNumberTable:
line 1: 0
line 10: 5
LocalVariableTable:
Start Length Slot Name Signature
0 10 0 this LTestInnerClass$1;
As is clear, the parameter in register 1 is not in the LVT. As near
as I've been able to make
out, the only way to find out that it even exists is to parse the
string in the signature. This
seems like an exceedingly awkward thing to do.
Ideas?
-Bil
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Conventional wisdom says to know your limits. To know your limits you
need to find them first. Finding you limits generally involves getting
in over your head and hoping you live long enough to benefit from the
experience. That's the fun part.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
