Re: anonymous parameters missing from local variable table in 1.5?

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.