Bug 44212 - Type of 'this' on instantiation of MethodGen from existing Method
Summary: Type of 'this' on instantiation of MethodGen from existing Method
Status: ASSIGNED
Alias: None
Product: BCEL - Now in Jira
Classification: Unclassified
Component: Main (show other bugs)
Version: 5.2
Hardware: Other Mac OS X 10.4
: P2 normal
Target Milestone: ---
Assignee: issues@commons.apache.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-01-11 09:27 UTC by Jesper Honig Spring
Modified: 2008-01-11 23:10 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jesper Honig Spring 2008-01-11 09:27:23 UTC
I have an issue when instantiating a MethodGen from an existing (non-static) method instance. I'm 
trying to copy a (non-static) method from one class to another class using BCEL. Specifically, I do:

MethodGen newMethodGen = new MethodGen(originalMethod.getBCELMethod(), 
newClassGen.getClassName(), newClassGen.getConstantPool());

This works nicely except for one issue; the 'this' variable in the local variable table points to the entry in 
the CP representing the type of the originating class, and not the type of the class in which it is inserted 
in. 

I traced a bit in the BCEL code, and found that to start with during the instantiation process of the 
MethodGen class (in the constructor), the 'this' variable in the local variable table indeed points to the 
correct entry in the CP representing the type of the new class .. 

However, it appears that after the initial instantiation, the attributes of the provided originating method 
overrides the local variable table. Specifically, in the constructor (the lines 213-229) the local variable 
table is deleted, and instead the local variable table of the provided original method is copied over.

From the documentation I cannot tell if this is by design, but it does appear to be a bit confusing; 
specifically, one can put a method into one class, but the 'this' variable points to another class. If this is 
by design, I would propose some exception throwing if the provided name of the class differs from 
class used in the local variable table.

Now we're at it .. invoking setClassName() on a MethodGen instance does also not make any changes to 
the local variable table -- again making it possible to have this inconsistency.