Mailing-List: contact bcel-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "BCEL Users List" <bcel-user@jakarta.apache.org>
Message-ID: <407413C5.1050900@huntwork.net>
Date: Wed, 07 Apr 2004 07:44:21 -0700
From: Andrew Huntwork <ash@huntwork.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031210
MIME-Version: 1.0
To: BCEL Users List <bcel-user@jakarta.apache.org>
Subject: Re: changing types
References: <51891.131.211.84.84.1081339475.squirrel@mail.students.cs.uu.nl>
In-Reply-To: <51891.131.211.84.84.1081339475.squirrel@mail.students.cs.uu.nl>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

i've done things like this a few times, and i've always run into a bunch 
of weird corner cases if i screw around with the constant pool.  the way 
i always end up doing it and getting it right is by replacing the field 
and then looking at every instruction and changing the instructions that 
reference the old field.  BTW, if you use InstructionFactory, you don't 
have to screw around with the constant pool, which i always try to do 
through having been burned in the past.

Of course, I have since forgotten what problems i ran into when 
modifying the constant pool, so feel free to take my advice with a grain 
of salt.  especially since my code will run a lot slower than your 
original idea on large programs.

dweimers@students.cs.uu.nl wrote:
> At the momemnt I am working on some rewritings that contain the
> modifcation of the types of a fields and methods of an existing class. The
> thing is I am rewriting classes in such a way that they use don't use a
> class directly but an interface that I extracted from them.
> 
> E.g.
> 
> class ClassX{
> 
>   private Foo f; // transformation Foo -> IFoo which is the interface
> 
>   public bar() {
>     f = null; //just a use of f to make sure there is a FieldRef in the pool
>   }
> }
> 
> I could do this by creating a new field that has type IFoo and use
> replaceField() method and creating the new field that has the new/correct
> type. However taking this approach BCEL does not change the FieldRef entry
> of f, that is used by field instructions (putfield, getfield etc.).
> 
> In my case, all uses of Foo should be changed to IFoo, so what i _could_
> do, I think is change the Utf8 entry describing the signature, using
> something like :
> 
> cp.setConstant(field_foo.getSignatureIndex(), new ConstantUtf8("LIFoo;"));
> which only changes the signature and now it is not necessary to change the
> FieldRef entries, because they are 'pointing' to this utf8 entry and thus
> the change works on the FieldRef too. This to me feels like a 'safe'
> modification, but I haven't found docs that describe the constantpool well
> enough to defend this.
> 
> I hope that others have done similar things and are able to give some
> feedback. Are there situations where this directly changing the Utf8 entry
> causes troubles? If not, does the same approach apply to method
> signatures?
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: bcel-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: bcel-user-help@jakarta.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-user-help@jakarta.apache.org