You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Philip Aston <ph...@mail.com> on 2014/02/19 13:37:14 UTC

Plastic: access to the method visitor

Hello,

Unless I'm missing something, Plastic prevents an
InstructionBuilderCallback from accessing the underlying ASM method
visitor, and provides no other way to add arbitrary byte code?

Plastic is very useful, and way more pleasant than raw ASM, however I've
found I need to go off the tracks occasionally. E.g.

    new InstructionBuilderCallback() {

        @Override
        public void doBuild(final InstructionBuilder builder) {

            final MethodVisitor mv = getMethodVisitor(builder);

            builder
                .loadConstant("%s -> %s")
                .loadConstant(2);
            mv.visitTypeInsn(Opcodes.ANEWARRAY, "java/lang/Object");
           
    builder.dupe().loadConstant(0).loadThis().getField(delegateField);
            mv.visitInsn(Opcodes.AASTORE);
            builder.dupe().loadConstant(1).loadThis().getField(nextField);
            mv.visitInsn(Opcodes.AASTORE);

            builder
                .invokeStatic(String.class, String.class, "format",
    String.class, Object[].class)
                .returnResult();
        }
    };

where

    // hack hack hack
    private static MethodVisitor getMethodVisitor(InstructionBuilder
    builder) {
            try {
                final Field stateField =
    builder.getClass().getDeclaredField("v");
                stateField.setAccessible(true);
                return (MethodVisitor) stateField.get(builder);
            }
            catch (NoSuchFieldException e) {
                throw new AssertionError(e);
            }
            catch (IllegalAccessException e) {
                throw new AssertionError(e);
            }
    }

Am I missing something? Would you be open to an enhancement request to
provide InstructionBuilder.methodVisitor()?

Thanks,

- Phil


Re: Plastic: access to the method visitor

Posted by Philip Aston <ph...@mail.com>.
Having created a test case, I found what I was doing wrong. I was
expecting PlasticField.createAccessors() to understand covariant return
types, and so "pc.introduceField(Foo.class).createAccessors(..)" would
override "Object getFoo()"; it doesn't.

I now have everything working without the need for raw ASM.

Thanks!

- Phil

On 20/02/14 14:34, Thiago H de Paula Figueiredo wrote:
> I'd also add the Tapestry-IoC classes that create service proxies.
>
> On Thu, 20 Feb 2014 11:03:09 -0300, Lance Java
> <la...@googlemail.com> wrote:
>
>> Possibly the most comprehensive use of plastic is the test cases
>> https://github.com/apache/tapestry-5/tree/master/plastic/src/test/groovy/org/apache/tapestry5/plastic
>>
>>
>> After that, it's worth checking out Taha's blog
>> http://tawus.wordpress.com/category/plastic/
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: Plastic: access to the method visitor

Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
I'd also add the Tapestry-IoC classes that create service proxies.

On Thu, 20 Feb 2014 11:03:09 -0300, Lance Java <la...@googlemail.com>  
wrote:

> Possibly the most comprehensive use of plastic is the test cases
> https://github.com/apache/tapestry-5/tree/master/plastic/src/test/groovy/org/apache/tapestry5/plastic
>
> After that, it's worth checking out Taha's blog
> http://tawus.wordpress.com/category/plastic/


-- 
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: Plastic: access to the method visitor

Posted by Lance Java <la...@googlemail.com>.
Possibly the most comprehensive use of plastic is the test cases
https://github.com/apache/tapestry-5/tree/master/plastic/src/test/groovy/org/apache/tapestry5/plastic

After that, it's worth checking out Taha's blog
http://tawus.wordpress.com/category/plastic/

Re: Plastic: access to the method visitor

Posted by Lance Java <la...@googlemail.com>.
Perhaps give a high level overview of what you're trying to achieve. Can it
be achieved using:

PlasticClass.introduceMethod(...) and
PlasticMethod.addAdvice(MethodAdvice)

Re: Plastic: access to the method visitor

Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Thu, 20 Feb 2014 09:10:45 -0300, Philip Aston <ph...@mail.com> wrote:

> I'll work one up. I couldn't implement existing interface methods either.

Tapestry-IoC does an awful lot of that (creating classes to implement an  
interface) when creating proxies to services defined by an interface.

>> Yeah, I think this conversation fits there.
>>
>
> Will do. Thank you all for your thoughts so far.

;)

-- 
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: Plastic: access to the method visitor

Posted by Philip Aston <ph...@mail.com>.
On 20/02/14 12:08, Thiago H de Paula Figueiredo wrote:
> On Thu, 20 Feb 2014 08:11:35 -0300, Philip Aston <ph...@mail.com>
> wrote:
>
>> Well, the InstructionBuilder API requires you to understand the byte
>> code that's generated. Also, I agree that it is sane to transform
>> existing classes, and I originally tried to do so but found Plastic
>> didn't let me implement abstract methods from my superclass. This is
>> possibly a Plastic bug.
>
> I guess Plastic wasn't built is a general purpose bytecode
> manipulation library, but as a way of simplifying the writing of
> Tapestry-IoC code, hence its limitations.
>
> Any test cases for not being able to implement abstract methods from
> an abstract superclass? Is the bytecode for this different from the
> one used for implementing an abstract method from an interface?

I'll work one up. I couldn't implement existing interface methods either.

>
>> With respect, no Plastic experts have responded. Should I take my
>> request to the dev list?
>
> Yeah, I think this conversation fits there.
>

Will do. Thank you all for your thoughts so far.

- Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: Plastic: access to the method visitor

Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Thu, 20 Feb 2014 08:11:35 -0300, Philip Aston <ph...@mail.com> wrote:

> Well, the InstructionBuilder API requires you to understand the byte
> code that's generated. Also, I agree that it is sane to transform
> existing classes, and I originally tried to do so but found Plastic
> didn't let me implement abstract methods from my superclass. This is
> possibly a Plastic bug.

I guess Plastic wasn't built is a general purpose bytecode manipulation  
library, but as a way of simplifying the writing of Tapestry-IoC code,  
hence its limitations.

Any test cases for not being able to implement abstract methods from an  
abstract superclass? Is the bytecode for this different from the one used  
for implementing an abstract method from an interface?

> With respect, no Plastic experts have responded. Should I take my
> request to the dev list?

Yeah, I think this conversation fits there.

-- 
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: Plastic: access to the method visitor

Posted by Philip Aston <ph...@mail.com>.
On 20/02/14 08:30, Lance Java wrote:
> I think the whole philosophy of Plastic is that you shouldn't ever need to
> use ASM directly. I'm no expert but my understanding is that you can write
> normal java code by implementing interfaces and use Plastic to weave the
> implementations into the byte code.

Well, the InstructionBuilder API requires you to understand the byte
code that's generated. Also, I agree that it is sane to transform
existing classes, and I originally tried to do so but found Plastic
didn't let me implement abstract methods from my superclass. This is
possibly a Plastic bug.

With respect, no Plastic experts have responded. Should I take my
request to the dev list?

- Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: Plastic: access to the method visitor

Posted by Lance Java <la...@googlemail.com>.
I think the whole philosophy of Plastic is that you shouldn't ever need to
use ASM directly. I'm no expert but my understanding is that you can write
normal java code by implementing interfaces and use Plastic to weave the
implementations into the byte code.

Re: Plastic: access to the method visitor

Posted by Philip Aston <ph...@mail.com>.
On 19/02/14 17:13, Thiago H de Paula Figueiredo wrote:
> On Wed, 19 Feb 2014 11:48:10 -0300, Philip Aston <ph...@mail.com>
> wrote:
>
>>> I don't know. My ASM/bytecode experience is almost null. Is Plastic
>>> missing methods  or other stuff so you can use some specific
>>> instructions? As far as I know, Howard created Plastic so he didn't
>>> need to use ASM directly in Tapestry-IoC.
>>
>> Yes - that's exactly the problem. It provides enough for
>> Howard/Tapestry, but getMethodVisitor() would open up direct use of ASM
>> and make Plastic more generally useful.
>
> I'm not sure if direct use of ASM in Plastic would actually work.
>
> What instructions are you missing?I think adding them is a better
> choice than going directly to ASM.


I need ANEWARRAY, and AASTORE. In an earlier factoring of my code, I was
also found the need for IADD. But that's just me. This just scratches
the surface of what someone might want. As a rough estimate, I'd say
InstructionBuilder uses about 25% of the 200 byte code instructions. It
could be extended to add 150 or so methods of the form:

    public InstructionBuilder arrayLength()
    {
        check();
        v.visitInsn(ARRAYLENGTH);
        return this;
    }

But this dilutes the higher level fluent interface that
InstructionBuilder provides.

This is why I prefer getMethodVisitor() be added as an "escape tunnel".

Regards,

- Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: Plastic: access to the method visitor

Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Wed, 19 Feb 2014 11:48:10 -0300, Philip Aston <ph...@mail.com> wrote:

>> I don't know. My ASM/bytecode experience is almost null. Is Plastic
>> missing methods  or other stuff so you can use some specific
>> instructions? As far as I know, Howard created Plastic so he didn't
>> need to use ASM directly in Tapestry-IoC.
>
> Yes - that's exactly the problem. It provides enough for
> Howard/Tapestry, but getMethodVisitor() would open up direct use of ASM
> and make Plastic more generally useful.

I'm not sure if direct use of ASM in Plastic would actually work.

What instructions are you missing? I think adding them is a better choice  
than going directly to ASM.

-- 
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: Plastic: access to the method visitor

Posted by Philip Aston <ph...@mail.com>.
On 19/02/14 14:45, Thiago H de Paula Figueiredo wrote:
> On Wed, 19 Feb 2014 11:13:30 -0300, Philip Aston <ph...@mail.com>
> wrote:
>
>> Maybe I don't?
>>
>> I'm using Plastic standalone, without Tapestry.
>>
>> The "toString" implementation I showed in my previous mail is the place
>> I currently need the method visitor; specifically so I can create an
>> array to pass to String.format().
>
> I don't know. My ASM/bytecode experience is almost null. Is Plastic
> missing methods  or other stuff so you can use some specific
> instructions? As far as I know, Howard created Plastic so he didn't
> need to use ASM directly in Tapestry-IoC.
>

Yes - that's exactly the problem. It provides enough for
Howard/Tapestry, but getMethodVisitor() would open up direct use of ASM
and make Plastic more generally useful.

- Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: Plastic: access to the method visitor

Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Wed, 19 Feb 2014 11:13:30 -0300, Philip Aston <ph...@mail.com> wrote:

> Maybe I don't?
>
> I'm using Plastic standalone, without Tapestry.
>
> The "toString" implementation I showed in my previous mail is the place
> I currently need the method visitor; specifically so I can create an
> array to pass to String.format().

I don't know. My ASM/bytecode experience is almost null. Is Plastic  
missing methods  or other stuff so you can use some specific instructions?  
As far as I know, Howard created Plastic so he didn't need to use ASM  
directly in Tapestry-IoC.

-- 
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: Plastic: access to the method visitor

Posted by Philip Aston <ph...@mail.com>.
On 19/02/14 14:08, Thiago H de Paula Figueiredo wrote:
> On Wed, 19 Feb 2014 09:37:14 -0300, Philip Aston <ph...@mail.com>
> wrote:
>
>> Hello,
>
> Hi!
>
>>
>> Unless I'm missing something, Plastic prevents an
>> InstructionBuilderCallback from accessing the underlying ASM method
>> visitor, and provides no other way to add arbitrary byte code?
>
> Why do you need that? Just curious. :)
>

Maybe I don't?

I'm using Plastic standalone, without Tapestry.

The "toString" implementation I showed in my previous mail is the place
I currently need the method visitor; specifically so I can create an
array to pass to String.format().


- Phil


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: Plastic: access to the method visitor

Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Wed, 19 Feb 2014 09:37:14 -0300, Philip Aston <ph...@mail.com> wrote:

> Hello,

Hi!

>
> Unless I'm missing something, Plastic prevents an
> InstructionBuilderCallback from accessing the underlying ASM method
> visitor, and provides no other way to add arbitrary byte code?

Why do you need that? Just curious. :)

-- 
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org