You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bcel-user@jakarta.apache.org by Jason Dillon <ja...@planet57.com> on 2002/04/05 10:04:11 UTC
Possible problem with MethodGen & long/double param types...
Hey, I am working to fix a bug in side of JBoss, which relates to our
dymanic proxy generation. This was recently switched over to using
BCEL, but it seems like there is a problem.
Before I get into the details, let me say that I am not a VM expert or a
byte code whiz... I generally like to deal with higher level
abstractions, but this bug looked important and well all this BCEL stuff
looks really interesting. That said, this could simply be a problem
with our usage, but based on my investigation today I don't think so...
but who knows.
I did try to look for some bug reports on this already, but either it is
getting too late and I need to go home, or I simply will never
understand how to use Bugzilla...
* * *
We use BCEL to generate proxies to interfaces and abstract classes. But
for simplicily I will keep things to interfaces, as this shows the problem.
Take the given interface:
public interface MyInterface
{
void test(long a, long b);
}
The MethodGen.toString() ends up with:
public void test(long arg0, long)
Where it should be:
public void test(long arg0, long arg1)
It turns out (only did some brief testing) that when using all long or
double types that every other parameter will get corrupted like this.
If you use any other type there are no problems.
* * *
We have a class (called ProxyImplementationFactory... for whatever
reason) which contains helper methods to generate Method objects for
parts of the target proxy. To make sure that none of the BCEL code
inside was messing with this (as I don't really know that much about it
... yet), I took the contents of a method which generates a String
toString() method and used it inside of the method which exhibits this
problem... which it still does/did with this change.
Based on this I am thinking that the problem is with the byte code
generation done under the covers inside of MethodGen and friends. I
spent very little time looking through this code to see if I could find
anything obvious... but no.
I am thinking that the code which deals with generation of the byte code
for the method might not be giving enough space for the long/double...
but that is just a guess, I don't really know how method defs work.
Can someone give me a hand to get this fixed... either help me to get my
code proper or track down a bug in BCEL... or evern better informing me
that this is already fixed.
Many thanks,
--jason
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Possible problem with MethodGen & long/double param types...
Posted by Jason Dillon <ja...@planet57.com>.
We are using 5.0rc1. I will try CVS and see if that has the same problem.
--jason
Juozas Baliuka wrote:
>Hi,
>We use BCEL for Proxy generation and it is no problems if MethodGen is
>constructed this way :
>
> private static MethodGen toMethodGen(
> java.lang.reflect.Method mtd,
> String className,
> InstructionList il,
> ConstantPoolGen cp) {
>
> return new MethodGen(
> ACC_PUBLIC,
> toType(mtd.getReturnType()),
> toType(mtd.getParameterTypes()),
> null,
> mtd.getName(),
> className,
> il,
> cp);
> }
>
>May this problem exists in some version ?
>I tried to build it from CVS a few weeks ago and from binary distribution,
>but I don't see any problem.
>Can you tell us version of BCEL distribution you use ?
>
>
>It is output from DEBUG :
>
>public void testLong(long arg1, long arg2)
>Code(max_stack = 8, max_locals = 10, code_length = 112)
>0: iconst_2
>1: anewarray <java.lang.Object> (16)
>4: dup
>5: iconst_0
>6: new <java.lang.Long> (45)
>9: dup
>10: lload_1
>11: invokespecial java.lang.Long.<init> (J)V (48)
>14: aastore
>15: dup
>16: iconst_1
>17: new <java.lang.Long> (45)
>20: dup
>21: lload_3
>22: invokespecial java.lang.Long.<init> (J)V (48)
>25: aastore
>26: astore %5
>28: aload_0
>29: getfield
>org.apache.commons.simplestore.TestPersistentClassType$$EnhancedBySimplestor
>e$$.h Lorg/apache/commons/simplestore/tools/MethodInterceptor; (14)
>32: aload_0
>33: getstatic
>org.apache.commons.simplestore.TestPersistentClassType$$EnhancedBySimplestor
>e$$.METHOD_0 Ljava/lang/reflect/Method; (50)
>36: aload %5
>38: invokeinterface
>org.apache.commons.simplestore.tools.MethodInterceptor.beforeInvoke
>(Ljava/lang/Object;Ljava/lang/reflect/Method;[Ljava/lang/Object;)Ljava/lang/
>Object; (33) 4 0
>43: astore %6
>45: aconst_null
>46: astore %7
>48: iconst_0
>49: istore %8
>51: aconst_null
>52: astore %9
>54: aload_0
>55: getfield
>org.apache.commons.simplestore.TestPersistentClassType$$EnhancedBySimplestor
>e$$.h Lorg/apache/commons/simplestore/tools/MethodInterceptor; (14)
>58: aload_0
>59: getstatic
>org.apache.commons.simplestore.TestPersistentClassType$$EnhancedBySimplestor
>e$$.METHOD_0 Ljava/lang/reflect/Method; (50)
>62: aload %5
>64: aload %6
>66: invokeinterface
>org.apache.commons.simplestore.tools.MethodInterceptor.invokeSuper
>(Ljava/lang/Object;Ljava/lang/reflect/Method;[Ljava/lang/Object;Ljava/lang/O
>bject;)Z (41) 5 0
>71: ifeq #88
>74: iconst_1
>75: istore %8
>77: aload_0
>78: lload_1
>79: lload_3
>80: invokespecial
>org.apache.commons.simplestore.TestPersistentClassType.testLong (JJ)V (54)
>83: goto #88
>86: astore %9
>88: aload_0
>89: getfield
>org.apache.commons.simplestore.TestPersistentClassType$$EnhancedBySimplestor
>e$$.h Lorg/apache/commons/simplestore/tools/MethodInterceptor; (14)
>92: aload_0
>93: getstatic
>org.apache.commons.simplestore.TestPersistentClassType$$EnhancedBySimplestor
>e$$.METHOD_0 Ljava/lang/reflect/Method; (50)
>96: aload %5
>98: aload %6
>100: iload %8
>102: aload %7
>104: aload %9
>106: invokeinterface
>org.apache.commons.simplestore.tools.MethodInterceptor.afterReturn
>(Ljava/lang/Object;Ljava/lang/reflect/Method;[Ljava/lang/Object;Ljava/lang/O
>bject;ZLjava/lang/Object;Ljava/lang/Throwable;)Ljava/lang/Object; (37) 8
>0
>111: return
>Exception handler(s) =
>>>From To Handler Type
>75 86 86 java.lang.Throwable(56)
>
>
>Class used for test looks like this :
>
>public abstract class TestPersistentClassType implements TestPersistent,
> org.apache.commons.simplestore.tools.Constants{
>
> /** Creates a new instance of TestPersistentClassType */
> public TestPersistentClassType() {
> }
> /***********************************/
>public void testLong(long p1,long p2){
> System.out.println("" + p1 + " " + p2);
> }
> /***********************************/
>
> public void doSomething(String arg){
> if( DEBUG ){
> this.setStrVal("done Something " + arg);
> System.out.println(getStrVal());
> }
> }
>
> public void setNuls(){
> setDateVal( null ) ;
> setStrVal1( null );
> setStrVal ( null );
> setParent ( null );
> }
>
> public abstract TestPersistentClassType getParent();
>
> public abstract void setDateVal(java.util.Date val) ;
>
> public abstract void setBoolVal(boolean val) ;
>
> public abstract java.util.Date getDateVal() ;
>
> public abstract void setIntVal(int val);
>
> public abstract void setFloatVal(float val) ;
>
> public abstract float getFloatVal() ;
>
> public abstract void setStrVal1(String strVal1);
>
> public abstract void setStrVal(String strVal1);
>
>
> public abstract String getStrVal();
>
> public abstract java.util.Collection getChildren();
>
> public abstract String getStrVal1();
>
> public abstract void setParent(TestPersistentClassType tp);
>
> public abstract int getIntVal();
>
> public abstract boolean getBoolVal();
>}
>
> ----- Original Message -----
>From: "Jason Dillon" <ja...@planet57.com>
>To: <bc...@jakarta.apache.org>
>Sent: Friday, April 05, 2002 10:04 AM
>Subject: Possible problem with MethodGen & long/double param types...
>
>
>>Hey, I am working to fix a bug in side of JBoss, which relates to our
>>dymanic proxy generation. This was recently switched over to using
>>BCEL, but it seems like there is a problem.
>>
>>Before I get into the details, let me say that I am not a VM expert or a
>>byte code whiz... I generally like to deal with higher level
>>abstractions, but this bug looked important and well all this BCEL stuff
>>looks really interesting. That said, this could simply be a problem
>>with our usage, but based on my investigation today I don't think so...
>>but who knows.
>>
>>I did try to look for some bug reports on this already, but either it is
>>getting too late and I need to go home, or I simply will never
>>understand how to use Bugzilla...
>>
>>* * *
>>
>>We use BCEL to generate proxies to interfaces and abstract classes. But
>>for simplicily I will keep things to interfaces, as this shows the
>>
>problem.
>
>>Take the given interface:
>>
>>public interface MyInterface
>>{
>> void test(long a, long b);
>>}
>>
>>The MethodGen.toString() ends up with:
>>
>>public void test(long arg0, long)
>>
>>Where it should be:
>>
>>public void test(long arg0, long arg1)
>>
>>It turns out (only did some brief testing) that when using all long or
>>double types that every other parameter will get corrupted like this.
>> If you use any other type there are no problems.
>>
>>* * *
>>
>>We have a class (called ProxyImplementationFactory... for whatever
>>reason) which contains helper methods to generate Method objects for
>>parts of the target proxy. To make sure that none of the BCEL code
>>inside was messing with this (as I don't really know that much about it
>>... yet), I took the contents of a method which generates a String
>>toString() method and used it inside of the method which exhibits this
>>problem... which it still does/did with this change.
>>
>>Based on this I am thinking that the problem is with the byte code
>>generation done under the covers inside of MethodGen and friends. I
>>spent very little time looking through this code to see if I could find
>>anything obvious... but no.
>>
>>I am thinking that the code which deals with generation of the byte code
>>for the method might not be giving enough space for the long/double...
>>but that is just a guess, I don't really know how method defs work.
>>
>>Can someone give me a hand to get this fixed... either help me to get my
>>code proper or track down a bug in BCEL... or evern better informing me
>>that this is already fixed.
>>
>>Many thanks,
>>
>>--jason
>>
>>
>>--
>>To unsubscribe, e-mail:
>>
><ma...@jakarta.apache.org>
>
>>For additional commands, e-mail:
>>
><ma...@jakarta.apache.org>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Possible problem with MethodGen & long/double param types...
Posted by Jason Dillon <ja...@planet57.com>.
Ok... =) Looks like this is a problem with the generated method byte
code. I still have not tracked down exactly how to fix it... but I am
closer now. Thanks for your insight... and the dump or your method...
that is what helped me find the problem.
--jason
Juozas Baliuka wrote:
>Hi,
>We use BCEL for Proxy generation and it is no problems if MethodGen is
>constructed this way :
>
> private static MethodGen toMethodGen(
> java.lang.reflect.Method mtd,
> String className,
> InstructionList il,
> ConstantPoolGen cp) {
>
> return new MethodGen(
> ACC_PUBLIC,
> toType(mtd.getReturnType()),
> toType(mtd.getParameterTypes()),
> null,
> mtd.getName(),
> className,
> il,
> cp);
> }
>
>May this problem exists in some version ?
>I tried to build it from CVS a few weeks ago and from binary distribution,
>but I don't see any problem.
>Can you tell us version of BCEL distribution you use ?
>
>
>It is output from DEBUG :
>
>public void testLong(long arg1, long arg2)
>Code(max_stack = 8, max_locals = 10, code_length = 112)
>0: iconst_2
>1: anewarray <java.lang.Object> (16)
>4: dup
>5: iconst_0
>6: new <java.lang.Long> (45)
>9: dup
>10: lload_1
>11: invokespecial java.lang.Long.<init> (J)V (48)
>14: aastore
>15: dup
>16: iconst_1
>17: new <java.lang.Long> (45)
>20: dup
>21: lload_3
>22: invokespecial java.lang.Long.<init> (J)V (48)
>25: aastore
>26: astore %5
>28: aload_0
>29: getfield
>org.apache.commons.simplestore.TestPersistentClassType$$EnhancedBySimplestor
>e$$.h Lorg/apache/commons/simplestore/tools/MethodInterceptor; (14)
>32: aload_0
>33: getstatic
>org.apache.commons.simplestore.TestPersistentClassType$$EnhancedBySimplestor
>e$$.METHOD_0 Ljava/lang/reflect/Method; (50)
>36: aload %5
>38: invokeinterface
>org.apache.commons.simplestore.tools.MethodInterceptor.beforeInvoke
>(Ljava/lang/Object;Ljava/lang/reflect/Method;[Ljava/lang/Object;)Ljava/lang/
>Object; (33) 4 0
>43: astore %6
>45: aconst_null
>46: astore %7
>48: iconst_0
>49: istore %8
>51: aconst_null
>52: astore %9
>54: aload_0
>55: getfield
>org.apache.commons.simplestore.TestPersistentClassType$$EnhancedBySimplestor
>e$$.h Lorg/apache/commons/simplestore/tools/MethodInterceptor; (14)
>58: aload_0
>59: getstatic
>org.apache.commons.simplestore.TestPersistentClassType$$EnhancedBySimplestor
>e$$.METHOD_0 Ljava/lang/reflect/Method; (50)
>62: aload %5
>64: aload %6
>66: invokeinterface
>org.apache.commons.simplestore.tools.MethodInterceptor.invokeSuper
>(Ljava/lang/Object;Ljava/lang/reflect/Method;[Ljava/lang/Object;Ljava/lang/O
>bject;)Z (41) 5 0
>71: ifeq #88
>74: iconst_1
>75: istore %8
>77: aload_0
>78: lload_1
>79: lload_3
>80: invokespecial
>org.apache.commons.simplestore.TestPersistentClassType.testLong (JJ)V (54)
>83: goto #88
>86: astore %9
>88: aload_0
>89: getfield
>org.apache.commons.simplestore.TestPersistentClassType$$EnhancedBySimplestor
>e$$.h Lorg/apache/commons/simplestore/tools/MethodInterceptor; (14)
>92: aload_0
>93: getstatic
>org.apache.commons.simplestore.TestPersistentClassType$$EnhancedBySimplestor
>e$$.METHOD_0 Ljava/lang/reflect/Method; (50)
>96: aload %5
>98: aload %6
>100: iload %8
>102: aload %7
>104: aload %9
>106: invokeinterface
>org.apache.commons.simplestore.tools.MethodInterceptor.afterReturn
>(Ljava/lang/Object;Ljava/lang/reflect/Method;[Ljava/lang/Object;Ljava/lang/O
>bject;ZLjava/lang/Object;Ljava/lang/Throwable;)Ljava/lang/Object; (37) 8
>0
>111: return
>Exception handler(s) =
>>>From To Handler Type
>75 86 86 java.lang.Throwable(56)
>
>
>Class used for test looks like this :
>
>public abstract class TestPersistentClassType implements TestPersistent,
> org.apache.commons.simplestore.tools.Constants{
>
> /** Creates a new instance of TestPersistentClassType */
> public TestPersistentClassType() {
> }
> /***********************************/
>public void testLong(long p1,long p2){
> System.out.println("" + p1 + " " + p2);
> }
> /***********************************/
>
> public void doSomething(String arg){
> if( DEBUG ){
> this.setStrVal("done Something " + arg);
> System.out.println(getStrVal());
> }
> }
>
> public void setNuls(){
> setDateVal( null ) ;
> setStrVal1( null );
> setStrVal ( null );
> setParent ( null );
> }
>
> public abstract TestPersistentClassType getParent();
>
> public abstract void setDateVal(java.util.Date val) ;
>
> public abstract void setBoolVal(boolean val) ;
>
> public abstract java.util.Date getDateVal() ;
>
> public abstract void setIntVal(int val);
>
> public abstract void setFloatVal(float val) ;
>
> public abstract float getFloatVal() ;
>
> public abstract void setStrVal1(String strVal1);
>
> public abstract void setStrVal(String strVal1);
>
>
> public abstract String getStrVal();
>
> public abstract java.util.Collection getChildren();
>
> public abstract String getStrVal1();
>
> public abstract void setParent(TestPersistentClassType tp);
>
> public abstract int getIntVal();
>
> public abstract boolean getBoolVal();
>}
>
> ----- Original Message -----
>From: "Jason Dillon" <ja...@planet57.com>
>To: <bc...@jakarta.apache.org>
>Sent: Friday, April 05, 2002 10:04 AM
>Subject: Possible problem with MethodGen & long/double param types...
>
>
>>Hey, I am working to fix a bug in side of JBoss, which relates to our
>>dymanic proxy generation. This was recently switched over to using
>>BCEL, but it seems like there is a problem.
>>
>>Before I get into the details, let me say that I am not a VM expert or a
>>byte code whiz... I generally like to deal with higher level
>>abstractions, but this bug looked important and well all this BCEL stuff
>>looks really interesting. That said, this could simply be a problem
>>with our usage, but based on my investigation today I don't think so...
>>but who knows.
>>
>>I did try to look for some bug reports on this already, but either it is
>>getting too late and I need to go home, or I simply will never
>>understand how to use Bugzilla...
>>
>>* * *
>>
>>We use BCEL to generate proxies to interfaces and abstract classes. But
>>for simplicily I will keep things to interfaces, as this shows the
>>
>problem.
>
>>Take the given interface:
>>
>>public interface MyInterface
>>{
>> void test(long a, long b);
>>}
>>
>>The MethodGen.toString() ends up with:
>>
>>public void test(long arg0, long)
>>
>>Where it should be:
>>
>>public void test(long arg0, long arg1)
>>
>>It turns out (only did some brief testing) that when using all long or
>>double types that every other parameter will get corrupted like this.
>> If you use any other type there are no problems.
>>
>>* * *
>>
>>We have a class (called ProxyImplementationFactory... for whatever
>>reason) which contains helper methods to generate Method objects for
>>parts of the target proxy. To make sure that none of the BCEL code
>>inside was messing with this (as I don't really know that much about it
>>... yet), I took the contents of a method which generates a String
>>toString() method and used it inside of the method which exhibits this
>>problem... which it still does/did with this change.
>>
>>Based on this I am thinking that the problem is with the byte code
>>generation done under the covers inside of MethodGen and friends. I
>>spent very little time looking through this code to see if I could find
>>anything obvious... but no.
>>
>>I am thinking that the code which deals with generation of the byte code
>>for the method might not be giving enough space for the long/double...
>>but that is just a guess, I don't really know how method defs work.
>>
>>Can someone give me a hand to get this fixed... either help me to get my
>>code proper or track down a bug in BCEL... or evern better informing me
>>that this is already fixed.
>>
>>Many thanks,
>>
>>--jason
>>
>>
>>--
>>To unsubscribe, e-mail:
>>
><ma...@jakarta.apache.org>
>
>>For additional commands, e-mail:
>>
><ma...@jakarta.apache.org>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Possible problem with MethodGen & long/double param types...
Posted by Juozas Baliuka <ba...@mwm.lt>.
Hi,
We use BCEL for Proxy generation and it is no problems if MethodGen is
constructed this way :
private static MethodGen toMethodGen(
java.lang.reflect.Method mtd,
String className,
InstructionList il,
ConstantPoolGen cp) {
return new MethodGen(
ACC_PUBLIC,
toType(mtd.getReturnType()),
toType(mtd.getParameterTypes()),
null,
mtd.getName(),
className,
il,
cp);
}
May this problem exists in some version ?
I tried to build it from CVS a few weeks ago and from binary distribution,
but I don't see any problem.
Can you tell us version of BCEL distribution you use ?
It is output from DEBUG :
public void testLong(long arg1, long arg2)
Code(max_stack = 8, max_locals = 10, code_length = 112)
0: iconst_2
1: anewarray <java.lang.Object> (16)
4: dup
5: iconst_0
6: new <java.lang.Long> (45)
9: dup
10: lload_1
11: invokespecial java.lang.Long.<init> (J)V (48)
14: aastore
15: dup
16: iconst_1
17: new <java.lang.Long> (45)
20: dup
21: lload_3
22: invokespecial java.lang.Long.<init> (J)V (48)
25: aastore
26: astore %5
28: aload_0
29: getfield
org.apache.commons.simplestore.TestPersistentClassType$$EnhancedBySimplestor
e$$.h Lorg/apache/commons/simplestore/tools/MethodInterceptor; (14)
32: aload_0
33: getstatic
org.apache.commons.simplestore.TestPersistentClassType$$EnhancedBySimplestor
e$$.METHOD_0 Ljava/lang/reflect/Method; (50)
36: aload %5
38: invokeinterface
org.apache.commons.simplestore.tools.MethodInterceptor.beforeInvoke
(Ljava/lang/Object;Ljava/lang/reflect/Method;[Ljava/lang/Object;)Ljava/lang/
Object; (33) 4 0
43: astore %6
45: aconst_null
46: astore %7
48: iconst_0
49: istore %8
51: aconst_null
52: astore %9
54: aload_0
55: getfield
org.apache.commons.simplestore.TestPersistentClassType$$EnhancedBySimplestor
e$$.h Lorg/apache/commons/simplestore/tools/MethodInterceptor; (14)
58: aload_0
59: getstatic
org.apache.commons.simplestore.TestPersistentClassType$$EnhancedBySimplestor
e$$.METHOD_0 Ljava/lang/reflect/Method; (50)
62: aload %5
64: aload %6
66: invokeinterface
org.apache.commons.simplestore.tools.MethodInterceptor.invokeSuper
(Ljava/lang/Object;Ljava/lang/reflect/Method;[Ljava/lang/Object;Ljava/lang/O
bject;)Z (41) 5 0
71: ifeq #88
74: iconst_1
75: istore %8
77: aload_0
78: lload_1
79: lload_3
80: invokespecial
org.apache.commons.simplestore.TestPersistentClassType.testLong (JJ)V (54)
83: goto #88
86: astore %9
88: aload_0
89: getfield
org.apache.commons.simplestore.TestPersistentClassType$$EnhancedBySimplestor
e$$.h Lorg/apache/commons/simplestore/tools/MethodInterceptor; (14)
92: aload_0
93: getstatic
org.apache.commons.simplestore.TestPersistentClassType$$EnhancedBySimplestor
e$$.METHOD_0 Ljava/lang/reflect/Method; (50)
96: aload %5
98: aload %6
100: iload %8
102: aload %7
104: aload %9
106: invokeinterface
org.apache.commons.simplestore.tools.MethodInterceptor.afterReturn
(Ljava/lang/Object;Ljava/lang/reflect/Method;[Ljava/lang/Object;Ljava/lang/O
bject;ZLjava/lang/Object;Ljava/lang/Throwable;)Ljava/lang/Object; (37) 8
0
111: return
Exception handler(s) =
>From To Handler Type
75 86 86 java.lang.Throwable(56)
Class used for test looks like this :
public abstract class TestPersistentClassType implements TestPersistent,
org.apache.commons.simplestore.tools.Constants{
/** Creates a new instance of TestPersistentClassType */
public TestPersistentClassType() {
}
/***********************************/
public void testLong(long p1,long p2){
System.out.println("" + p1 + " " + p2);
}
/***********************************/
public void doSomething(String arg){
if( DEBUG ){
this.setStrVal("done Something " + arg);
System.out.println(getStrVal());
}
}
public void setNuls(){
setDateVal( null ) ;
setStrVal1( null );
setStrVal ( null );
setParent ( null );
}
public abstract TestPersistentClassType getParent();
public abstract void setDateVal(java.util.Date val) ;
public abstract void setBoolVal(boolean val) ;
public abstract java.util.Date getDateVal() ;
public abstract void setIntVal(int val);
public abstract void setFloatVal(float val) ;
public abstract float getFloatVal() ;
public abstract void setStrVal1(String strVal1);
public abstract void setStrVal(String strVal1);
public abstract String getStrVal();
public abstract java.util.Collection getChildren();
public abstract String getStrVal1();
public abstract void setParent(TestPersistentClassType tp);
public abstract int getIntVal();
public abstract boolean getBoolVal();
}
----- Original Message -----
From: "Jason Dillon" <ja...@planet57.com>
To: <bc...@jakarta.apache.org>
Sent: Friday, April 05, 2002 10:04 AM
Subject: Possible problem with MethodGen & long/double param types...
> Hey, I am working to fix a bug in side of JBoss, which relates to our
> dymanic proxy generation. This was recently switched over to using
> BCEL, but it seems like there is a problem.
>
> Before I get into the details, let me say that I am not a VM expert or a
> byte code whiz... I generally like to deal with higher level
> abstractions, but this bug looked important and well all this BCEL stuff
> looks really interesting. That said, this could simply be a problem
> with our usage, but based on my investigation today I don't think so...
> but who knows.
>
> I did try to look for some bug reports on this already, but either it is
> getting too late and I need to go home, or I simply will never
> understand how to use Bugzilla...
>
> * * *
>
> We use BCEL to generate proxies to interfaces and abstract classes. But
> for simplicily I will keep things to interfaces, as this shows the
problem.
>
> Take the given interface:
>
> public interface MyInterface
> {
> void test(long a, long b);
> }
>
> The MethodGen.toString() ends up with:
>
> public void test(long arg0, long)
>
> Where it should be:
>
> public void test(long arg0, long arg1)
>
> It turns out (only did some brief testing) that when using all long or
> double types that every other parameter will get corrupted like this.
> If you use any other type there are no problems.
>
> * * *
>
> We have a class (called ProxyImplementationFactory... for whatever
> reason) which contains helper methods to generate Method objects for
> parts of the target proxy. To make sure that none of the BCEL code
> inside was messing with this (as I don't really know that much about it
> ... yet), I took the contents of a method which generates a String
> toString() method and used it inside of the method which exhibits this
> problem... which it still does/did with this change.
>
> Based on this I am thinking that the problem is with the byte code
> generation done under the covers inside of MethodGen and friends. I
> spent very little time looking through this code to see if I could find
> anything obvious... but no.
>
> I am thinking that the code which deals with generation of the byte code
> for the method might not be giving enough space for the long/double...
> but that is just a guess, I don't really know how method defs work.
>
> Can someone give me a hand to get this fixed... either help me to get my
> code proper or track down a bug in BCEL... or evern better informing me
> that this is already fixed.
>
> Many thanks,
>
> --jason
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>