headers
m.dahm | 2 Apr 2002 09:54
Picon

Re: Instantiating an abstract class

Hi,

of course you can not instantantiate a class with abstract methods.
You can and should provide a constructor, however.

Cheers
	Markus
> Von: Stephen Colebourne [mailto:scolebourne <at> eurobell.co.uk]
> Gesendet: Freitag, 29. März 2002 19:20
> An: bcel-user <at> jakarta.apache.org
> Betreff: Instantiating an abstract class
> 
> 
> Hi,
> I would like to be able to define a class as abstract so I 
> only have to
> define the method signatures. (BCEL would then be used to generate the
> implementations). However, I would also like to be able to 
> instantiate the
> class using the standard new operator (This must work in a 
> standard IDE,
> like Eclipse). From what I have seen so far its impossible (I 
> will have to
> use a factory), but have I missed something? Any other bright ideas?
> 
> Stephen
> 
> 
> --
> To unsubscribe, e-mail:
(Continue reading)

Permalink | Reply | 501 comments |
headers
Juozas Baliuka | 2 Apr 2002 12:52
Picon

Re: Instantiating an abstract class


Hi,

of course you can not instantantiate a class with abstract methods.
You can and should provide a constructor, however.

Cheers
Markus
> Von: Stephen Colebourne [mailto:scolebourne <at> eurobell.co.uk]
> Gesendet: Freitag, 29. März 2002 19:20
> An: bcel-user <at> jakarta.apache.org
> Betreff: Instantiating an abstract class
>
>
> Hi,
> I would like to be able to define a class as abstract so I
> only have to
> define the method signatures. (BCEL would then be used to generate the
> implementations). However, I would also like to be able to
> instantiate the
> class using the standard new operator (This must work in a
> standard IDE,
> like Eclipse). From what I have seen so far its impossible (I
> will have to
> use a factory), but have I missed something? Any other bright ideas?
Hi,

I think it is nothing bad to use factory, and in the most cases it is
better.
 Factory design pattern very useful for refactoring, in situation like you
(Continue reading)

Permalink | Reply | 502 comments |
headers
Stephen Colebourne | 3 Apr 2002 00:58
Picon

Re: Instantiating an abstract class

> of course you can not instantantiate a class with abstract methods.
> You can and should provide a constructor, however.
>
> Cheers
> Markus

> I think it is nothing bad to use factory, and in the most cases it is
> better.
>  Factory design pattern very useful for refactoring, in situation like you
> have desktop application and need to make it distributed. Change
> factory method and it become distributed or persistent.
> I use factory then possible.
> Juozas

Thanks for the responses.
The question was prompted by an attept to try to create JavaBeans where only
the signatures of the get and set methods had to be written. The answer is
what I expected, so I will be two choices left to create an abstract Person:
1) Use a factory - Person p = Person.create();
2) Use a naming pattern - Person p = new PersonImpl()
The first one would rely on creating a subclass on the fly, an ideal
candidate for Juozas's simplestore Enhancer.
The second one would rely on a classloader creating PersonImpl on the fly,
which I believe BCEL can do as well.

Thanks
Stephen
Permalink | Reply | 1 comment |
headers
Juozas Baliuka | 3 Apr 2002 10:57
Picon

Re: Instantiating an abstract class


----- Original Message -----
From: "Stephen Colebourne" <scolebourne <at> eurobell.co.uk>
To: "BCEL Users List" <bcel-user <at> jakarta.apache.org>
Sent: Wednesday, April 03, 2002 12:58 AM
Subject: Re: Instantiating an abstract class

> > of course you can not instantantiate a class with abstract methods.
> > You can and should provide a constructor, however.
> >
> > Cheers
> > Markus
>
> > I think it is nothing bad to use factory, and in the most cases it is
> > better.
> >  Factory design pattern very useful for refactoring, in situation like
you
> > have desktop application and need to make it distributed. Change
> > factory method and it become distributed or persistent.
> > I use factory then possible.
> > Juozas
>
> Thanks for the responses.
> The question was prompted by an attept to try to create JavaBeans where
only
> the signatures of the get and set methods had to be written. The answer is
> what I expected, so I will be two choices left to create an abstract
Person:
> 1) Use a factory - Person p = Person.create();
> 2) Use a naming pattern - Person p = new PersonImpl()
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason Dillon | 5 Apr 2002 10:04
Gravatar

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)
(Continue reading)

Permalink | Reply | 5 comments |
headers
m.dahm | 5 Apr 2002 10:52
Picon

Re: Poible problem with MethodGen & long/double param types...

Hi,

> 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)

That's not so bad, although it shouldn't happen of course. It merely
states that the
name of the second parameter is unknown. This information is stored in
an optional
attribute, which may be added for debugging purposes.
Thus this should cause no harm in the generated class.

Actually I found the place in toString() that caused it :) I'll fix it.
(Continue reading)

Permalink | Reply | 501 comments |
headers
Jason Dillon | 5 Apr 2002 11:17
Gravatar

Re: Poible problem with MethodGen & long/double param types...

Hi.  Sorry if I was not more clear, but the generated code will not pass the
verifier, with VerifyErrors like this:

java.lang.VerifyError: (class: jatek/server/JaTeKGroupBean$Proxy, method:
ejbSelectGroupMember
signature: (JJ)Ljatek/ser
ver/GroupMember;) Register pair 2/3 contains wrong type

(this is from the JBoss bug report in case you are wondering)

I wrote a testcase which tries many times of method signatures and when
attempting top gen a proxy whcih implements an interface with a long, long
method it will fail.

So it could be that the method code it to blame, but as I took code from a
different method which passes the verifier I am thinking that the method
code is fine.

--jason

On Fri, 5 Apr 2002 m.dahm <at> 4flow.de wrote:

> Hi,
>
> > 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:
(Continue reading)

Permalink | Reply | 501 comments |
headers
Juozas Baliuka | 5 Apr 2002 11:31
Picon

Re: Possible problem with MethodGen & long/double param types...


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)
(Continue reading)

Permalink | Reply | 4 comments |
headers
m.dahm | 5 Apr 2002 11:41
Picon

Re: Possible problem with MethodGen & long/double param types...

Hi,

> Hi.  Sorry if I was not more clear, but the generated code 
> will not pass the
> verifier, with VerifyErrors like this:
> 
> java.lang.VerifyError: (class: 
> jatek/server/JaTeKGroupBean$Proxy, method:
> ejbSelectGroupMember
> signature: (JJ)Ljatek/ser
> ver/GroupMember;) Register pair 2/3 contains wrong type

well the general problem is that long/double take two registers (local
variable slots),
because they are 64 bits wide. I suspect the problem is somewhere in the
code
generation where the wrong index is accessed.
I.e, if you have three variables

int i;
long j;
int k;

the indices are

i:0
j:1
k:3

Index 2 must not be accessed then.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jason Dillon | 5 Apr 2002 22:22
Gravatar

Re: Possible problem with MethodGen & long/double param types...

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.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane