You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bcel-dev@jakarta.apache.org by Stephen Kolaroff <xc...@netscape.net> on 2003/02/12 11:12:32 UTC
Coping methods
Hi
I noticed that when a MethodGen is copied from one class (One) to
another (Another), all references to this are left unchanged:
class One {
int field;
void putfield() {
field = 10
}
}
after copy of the putfield() method to Another I get smth like (I am
decompiling by hand):
class Another {
//....
void putfield() {
One one;
one = this;
one.field = 10;
}
}
which makes the JVM verifier nervous.
Is that way of copy feature or a bug. If a bug, will it be fixed soon/
would you receive patch.
Regards
Cheffo
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-dev-help@jakarta.apache.org
Re: Coping methods
Posted by Stephen Kolaroff <xc...@netscape.net>.
Just to finish the discussion:
At last I implemented method copy as I wanted. It turned to be extremly
heavy, dificult and error-prone: local vars fixes, argument fixes. And
is not exactly "copy": it is more like "implantation".
So, now I agree that it is better idea for MethodGen to have copy method
as curently implemented in BCEL.
I hope that mail thread will be useful for the next BCEL user who
wanders how to _plant_ (rather than copy) a method from one class to
another.
Stephen Kolaroff wrote:
> well, there should be some kind of misunderstanding.
> I took a lok at the copy implementation. And mentioned that all
> constants from original CP are copied to the destination CP. Which is
> perfect.
> My question was, isn't it better to take care of references to fields
> and method of the original class (this.field = 100 to be copied as
> this.field=100 in the other class). Moreover, I pointed that the current
> method copy produces incorrect (In JVMspec sense) result when
> transfering such this.smth references. Such incorrectnest, though, is
> perfectly correct as long as you, bcel developers, state that
> MethodGen.copy must behave as behave now.
>
> Meanwhile, I do implement my metod copy (actuall, whole class copy):
> class One {
> int filed;
> void putfield() {field=100;}
> }
>
> class Another {
> }
>
> copy One to Another:
> class Anoter {//after copy
> int field;
> void putfield() {field=100;}
> }
>
> Markus Dahm wrote:
>
>> You probably forgot to copy the ConstantPool as well. Alternatively
>> you have
>> to copy the referenced entries and set the indexes by hand.
>>
>> Cheers
>> Markus
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: bcel-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: bcel-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-dev-help@jakarta.apache.org
Verifier Exception
Posted by Stephen Kolaroff <xc...@netscape.net>.
I got following exception while verifying a class:
java.lang.ArrayIndexOutOfBoundsException
at
org.apache.bcel.verifier.structurals.LocalVariables.set(LocalVariables.java:125)
at
org.apache.bcel.verifier.structurals.Pass3bVerifier.do_verify(Pass3bVerifier.java:328)
at org.apache.bcel.verifier.PassVerifier.verify(PassVerifier.java:108)
at org.apache.bcel.verifier.Verifier.doPass3b(Verifier.java:135)
at org.apache.bcel.verifier.Verifier.main(Verifier.java:263)
at myClass.main(MyClass.java:169)
As one can see, it is thrown during pass 3b. The problem was that the
method being verified had declared less local variables (0) than
actually used (1).
Actually there is no workaround: the verified method was broken, and the
problem must be reported instead of throwing exception.
I am using BCEL 5.0.
Hope this Help
Cheffo
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-dev-help@jakarta.apache.org
Re: Coping methods
Posted by Stephen Kolaroff <xc...@netscape.net>.
well, there should be some kind of misunderstanding.
I took a lok at the copy implementation. And mentioned that all
constants from original CP are copied to the destination CP. Which is
perfect.
My question was, isn't it better to take care of references to fields
and method of the original class (this.field = 100 to be copied as
this.field=100 in the other class). Moreover, I pointed that the current
method copy produces incorrect (In JVMspec sense) result when
transfering such this.smth references. Such incorrectnest, though, is
perfectly correct as long as you, bcel developers, state that
MethodGen.copy must behave as behave now.
Meanwhile, I do implement my metod copy (actuall, whole class copy):
class One {
int filed;
void putfield() {field=100;}
}
class Another {
}
copy One to Another:
class Anoter {//after copy
int field;
void putfield() {field=100;}
}
Markus Dahm wrote:
> You probably forgot to copy the ConstantPool as well. Alternatively you have
> to copy the referenced entries and set the indexes by hand.
>
> Cheers
> Markus
>
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-dev-help@jakarta.apache.org
Re: Coping methods
Posted by Enver Haase <eh...@inf.fu-berlin.de>.
Hi Markus!
Habe gerade Dein "Helloify" in einen ClassLoader gepackt, der on-the-fly
Java-Klassen aus den Mpeg-Strömen des digitalen Fernsehens patcht.
Kommt echt cool!
...werde jetzt mal daran gehen, statt "System.out" lieber Jakarta's
log4j zu nehmen, und dann Entries und exits in/aus sync'd Methoden und
monitorenter/monitorexit zu tracken. Sollte Deadlocks aufspüren.
Macht Spaß.) Und wie geht's Dir?
...falls es so etwas wie oben skizziert schon gibt, sag' mir, wo ich's
klauen kann :)
Grüße!!
Enver
Markus Dahm wrote:
> You probably forgot to copy the ConstantPool as well. Alternatively you have
> to copy the referenced entries and set the indexes by hand.
>
> Cheers
> Markus
>
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-dev-help@jakarta.apache.org
Re: Coping methods
Posted by Markus Dahm <m....@gmx.de>.
You probably forgot to copy the ConstantPool as well. Alternatively you have
to copy the referenced entries and set the indexes by hand.
Cheers
Markus
--
+++ GMX - Mail, Messaging & more http://www.gmx.net +++
Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-dev-help@jakarta.apache.org
Re: Coping methods
Posted by Enver Haase <eh...@inf.fu-berlin.de>.
> > Do you mean a) JustIce or the b) built-in verifier in your JVM?
> JustIce don't think there is anything wrong; I mean built in JVM verifier.
> >>Is that way of copy feature or a bug. If a bug, will it be fixed soon/
> >>would you receive patch.
> >
> >
> > Depends.
> On what?
Don't know how the other developers think of this: but BCEL is 100% pure
Java, so it doesn't seem to make sense patching it because some seldomly
used verifier causes problems.
I don't think it's a bug in BCEL (can't be in a 100% pure Java thing). I
think it's a problem in your JVM / JRE.
Regards,
Enver
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-dev-help@jakarta.apache.org
Re: Coping methods
Posted by Stephen Kolaroff <xc...@netscape.net>.
Enver Haase wrote:
>>which makes the JVM verifier nervous.
>
>
> Do you mean a) JustIce or the b) built-in verifier in your JVM?
JustIce don't think there is anything wrong; I mean built in JVM verifier.
>
> a) what does JustIce do when it's "nervous"?
> b) get a better JRE?
a)jre is good enough
b) i dont have the option to change it
>
>
>>Is that way of copy feature or a bug. If a bug, will it be fixed soon/
>>would you receive patch.
>
>
> Depends.
On what?
>
> Greetings,
> Enver
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: bcel-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: bcel-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-dev-help@jakarta.apache.org
Re: Coping methods
Posted by Enver Haase <eh...@inf.fu-berlin.de>.
> which makes the JVM verifier nervous.
Do you mean a) JustIce or the b) built-in verifier in your JVM?
a) what does JustIce do when it's "nervous"?
b) get a better JRE?
> Is that way of copy feature or a bug. If a bug, will it be fixed soon/
> would you receive patch.
Depends.
Greetings,
Enver
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-dev-help@jakarta.apache.org