You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwebbeans.apache.org by David Blevins <da...@gmail.com> on 2012/08/09 06:27:33 UTC
javassist removal
Hey All,
Heads up that I'd like to investigate removing javassist and replacing it with some simple ASM code to create subclass based proxies. The proxy code is the small part, the bigger part is refactoring out the MethodHandler classes and replacing them with java.lang.reflect.InvocationHandler implementations.
As usual I'll probably look for an intermediary step in refactoring it out, maybe some way to keep the MethodHandlers and get all the code working with a different proxy impl, then refactor the handlers.
Any thoughts or comments welcome.
-David
Re: javassist removal
Posted by Romain Manni-Bucau <rm...@gmail.com>.
+1 indeed
- Romain
2012/8/9 Gerhard Petracek <ge...@gmail.com>
> +1
>
> regards,
> gerhard
>
>
>
> 2012/8/9 Mark Struberg <st...@yahoo.de>
>
> > +1 for ASM, we only use direct byte code manipulation anyway.
> >
> > LieGrue,
> > strub
> >
> >
> >
> > ----- Original Message -----
> > > From: Charles Moulliard <ch...@gmail.com>
> > > To: dev@openwebbeans.apache.org
> > > Cc:
> > > Sent: Thursday, August 9, 2012 8:36 AM
> > > Subject: Re: javassist removal
> > >
> > > Hi David,
> > >
> > > Is it for performance reasons that you prefer to switch from Javassist
> to
> > > ASM (http://swapnil84.wordpress.com/2009/09/01/asm-vs-javassist/) ?
> What
> > > could be the impact for existing projects (or side effect) when they
> will
> > > upgrade to a "refactored" version of OpenWebbeans using ASM and not
> > > longer
> > > javassist ?
> > >
> > > Regards,
> > >
> > > Charles
> > >
> > > On Thu, Aug 9, 2012 at 6:27 AM, David Blevins
> > > <da...@gmail.com>wrote:
> > >
> > >> Hey All,
> > >>
> > >> Heads up that I'd like to investigate removing javassist and
> replacing
> > > it
> > >> with some simple ASM code to create subclass based proxies. The
> proxy
> > code
> > >> is the small part, the bigger part is refactoring out the
> MethodHandler
> > >> classes and replacing them with java.lang.reflect.InvocationHandler
> > >> implementations.
> > >>
> > >> As usual I'll probably look for an intermediary step in refactoring
> it
> > >> out, maybe some way to keep the MethodHandlers and get all the code
> > working
> > >> with a different proxy impl, then refactor the handlers.
> > >>
> > >> Any thoughts or comments welcome.
> > >>
> > >>
> > >> -David
> > >>
> > >>
> > >
> > >
> > > --
> > > Charles Moulliard
> > > Apache Committer / Sr. Pr. Consultant at FuseSource.com
> > > Twitter : @cmoulliard
> > > Blog : http://cmoulliard.blogspot.com
> > >
> >
>
Re: javassist removal
Posted by Gerhard Petracek <ge...@gmail.com>.
+1
regards,
gerhard
2012/8/9 Mark Struberg <st...@yahoo.de>
> +1 for ASM, we only use direct byte code manipulation anyway.
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
> > From: Charles Moulliard <ch...@gmail.com>
> > To: dev@openwebbeans.apache.org
> > Cc:
> > Sent: Thursday, August 9, 2012 8:36 AM
> > Subject: Re: javassist removal
> >
> > Hi David,
> >
> > Is it for performance reasons that you prefer to switch from Javassist to
> > ASM (http://swapnil84.wordpress.com/2009/09/01/asm-vs-javassist/) ? What
> > could be the impact for existing projects (or side effect) when they will
> > upgrade to a "refactored" version of OpenWebbeans using ASM and not
> > longer
> > javassist ?
> >
> > Regards,
> >
> > Charles
> >
> > On Thu, Aug 9, 2012 at 6:27 AM, David Blevins
> > <da...@gmail.com>wrote:
> >
> >> Hey All,
> >>
> >> Heads up that I'd like to investigate removing javassist and replacing
> > it
> >> with some simple ASM code to create subclass based proxies. The proxy
> code
> >> is the small part, the bigger part is refactoring out the MethodHandler
> >> classes and replacing them with java.lang.reflect.InvocationHandler
> >> implementations.
> >>
> >> As usual I'll probably look for an intermediary step in refactoring it
> >> out, maybe some way to keep the MethodHandlers and get all the code
> working
> >> with a different proxy impl, then refactor the handlers.
> >>
> >> Any thoughts or comments welcome.
> >>
> >>
> >> -David
> >>
> >>
> >
> >
> > --
> > Charles Moulliard
> > Apache Committer / Sr. Pr. Consultant at FuseSource.com
> > Twitter : @cmoulliard
> > Blog : http://cmoulliard.blogspot.com
> >
>
Re: javassist removal
Posted by Mark Struberg <st...@yahoo.de>.
+1 for ASM, we only use direct byte code manipulation anyway.
LieGrue,
strub
----- Original Message -----
> From: Charles Moulliard <ch...@gmail.com>
> To: dev@openwebbeans.apache.org
> Cc:
> Sent: Thursday, August 9, 2012 8:36 AM
> Subject: Re: javassist removal
>
> Hi David,
>
> Is it for performance reasons that you prefer to switch from Javassist to
> ASM (http://swapnil84.wordpress.com/2009/09/01/asm-vs-javassist/) ? What
> could be the impact for existing projects (or side effect) when they will
> upgrade to a "refactored" version of OpenWebbeans using ASM and not
> longer
> javassist ?
>
> Regards,
>
> Charles
>
> On Thu, Aug 9, 2012 at 6:27 AM, David Blevins
> <da...@gmail.com>wrote:
>
>> Hey All,
>>
>> Heads up that I'd like to investigate removing javassist and replacing
> it
>> with some simple ASM code to create subclass based proxies. The proxy code
>> is the small part, the bigger part is refactoring out the MethodHandler
>> classes and replacing them with java.lang.reflect.InvocationHandler
>> implementations.
>>
>> As usual I'll probably look for an intermediary step in refactoring it
>> out, maybe some way to keep the MethodHandlers and get all the code working
>> with a different proxy impl, then refactor the handlers.
>>
>> Any thoughts or comments welcome.
>>
>>
>> -David
>>
>>
>
>
> --
> Charles Moulliard
> Apache Committer / Sr. Pr. Consultant at FuseSource.com
> Twitter : @cmoulliard
> Blog : http://cmoulliard.blogspot.com
>
Re: javassist removal
Posted by David Blevins <da...@gmail.com>.
On Aug 8, 2012, at 11:36 PM, Charles Moulliard wrote:
> Hi David,
>
> Is it for performance reasons that you prefer to switch from Javassist to
> ASM (http://swapnil84.wordpress.com/2009/09/01/asm-vs-javassist/) ?
Pretty much. Slower, consumes more memory and generally overkill. The code to create a subclass with ASM is basically one class -- two or three if you want to get fancy.
> What
> could be the impact for existing projects (or side effect) when they will
> upgrade to a "refactored" version of OpenWebbeans using ASM and not longer
> javassist ?
Certainly no impact to user code. If someone has some very deep OWB integration code that digs right down into the proxy layer, they're welcome to speak up. We can easily hold the show and discuss.
-David
> On Thu, Aug 9, 2012 at 6:27 AM, David Blevins <da...@gmail.com>wrote:
>
>> Hey All,
>>
>> Heads up that I'd like to investigate removing javassist and replacing it
>> with some simple ASM code to create subclass based proxies. The proxy code
>> is the small part, the bigger part is refactoring out the MethodHandler
>> classes and replacing them with java.lang.reflect.InvocationHandler
>> implementations.
>>
>> As usual I'll probably look for an intermediary step in refactoring it
>> out, maybe some way to keep the MethodHandlers and get all the code working
>> with a different proxy impl, then refactor the handlers.
>>
>> Any thoughts or comments welcome.
>>
>>
>> -David
>>
>>
>
>
> --
> Charles Moulliard
> Apache Committer / Sr. Pr. Consultant at FuseSource.com
> Twitter : @cmoulliard
> Blog : http://cmoulliard.blogspot.com
Re: javassist removal
Posted by Charles Moulliard <ch...@gmail.com>.
Hi David,
Is it for performance reasons that you prefer to switch from Javassist to
ASM (http://swapnil84.wordpress.com/2009/09/01/asm-vs-javassist/) ? What
could be the impact for existing projects (or side effect) when they will
upgrade to a "refactored" version of OpenWebbeans using ASM and not longer
javassist ?
Regards,
Charles
On Thu, Aug 9, 2012 at 6:27 AM, David Blevins <da...@gmail.com>wrote:
> Hey All,
>
> Heads up that I'd like to investigate removing javassist and replacing it
> with some simple ASM code to create subclass based proxies. The proxy code
> is the small part, the bigger part is refactoring out the MethodHandler
> classes and replacing them with java.lang.reflect.InvocationHandler
> implementations.
>
> As usual I'll probably look for an intermediary step in refactoring it
> out, maybe some way to keep the MethodHandlers and get all the code working
> with a different proxy impl, then refactor the handlers.
>
> Any thoughts or comments welcome.
>
>
> -David
>
>
--
Charles Moulliard
Apache Committer / Sr. Pr. Consultant at FuseSource.com
Twitter : @cmoulliard
Blog : http://cmoulliard.blogspot.com
Re: javassist removal
Posted by Matt Benson <gu...@gmail.com>.
Speaking from the Commons side of the fence, if you are already
bridging APIs in OpenEJB resulting from use of the InvocationHandler
interface, and particularly if you are considering abandoning this in
favor of some other abstraction, Commons [proxy]'s
Interceptor|Invoker|ObjectProvider (for delegating proxies) interfaces
are arguably as good as any, perhaps more so by virtue of their being
complete.
$0.02,
Matt
On Thu, Aug 9, 2012 at 1:33 PM, David Blevins <da...@gmail.com> wrote:
>
> On Aug 9, 2012, at 1:25 AM, Sven Linstaedt wrote:
>
>> Hi, sounds like you have something similar to commons-proxy [1] in
>> mind, when creating an abstraction of the proxy class generation
>> library. Have you already considered using it?
>
> Just became aware of it yesterday.
>
> ASM does the real work, and then it's about one class to do the actual generation and proxy creation. So it's not a lot of code. We use a version of it in OpenEJB to do @LocalBean proxy generation. On that side of the fence we do tons of ASM bytecode generation and manipulation. So we just banged this out maybe 4 years ago without giving it much though.
>
> I love commons and am happy for the code to live anywhere.
>
>
> -David
>
>> 2012/8/9 David Blevins <da...@gmail.com>:
>>> Hey All,
>>>
>>> Heads up that I'd like to investigate removing javassist and replacing it with some simple ASM code to create subclass based proxies. The proxy code is the small part, the bigger part is refactoring out the MethodHandler classes and replacing them with java.lang.reflect.InvocationHandler implementations.
>>>
>>> As usual I'll probably look for an intermediary step in refactoring it out, maybe some way to keep the MethodHandlers and get all the code working with a different proxy impl, then refactor the handlers.
>>>
>>> Any thoughts or comments welcome.
>>>
>>>
>>> -David
>>>
>>
>
Re: javassist removal
Posted by David Blevins <da...@gmail.com>.
On Aug 9, 2012, at 1:25 AM, Sven Linstaedt wrote:
> Hi, sounds like you have something similar to commons-proxy [1] in
> mind, when creating an abstraction of the proxy class generation
> library. Have you already considered using it?
Just became aware of it yesterday.
ASM does the real work, and then it's about one class to do the actual generation and proxy creation. So it's not a lot of code. We use a version of it in OpenEJB to do @LocalBean proxy generation. On that side of the fence we do tons of ASM bytecode generation and manipulation. So we just banged this out maybe 4 years ago without giving it much though.
I love commons and am happy for the code to live anywhere.
-David
> 2012/8/9 David Blevins <da...@gmail.com>:
>> Hey All,
>>
>> Heads up that I'd like to investigate removing javassist and replacing it with some simple ASM code to create subclass based proxies. The proxy code is the small part, the bigger part is refactoring out the MethodHandler classes and replacing them with java.lang.reflect.InvocationHandler implementations.
>>
>> As usual I'll probably look for an intermediary step in refactoring it out, maybe some way to keep the MethodHandlers and get all the code working with a different proxy impl, then refactor the handlers.
>>
>> Any thoughts or comments welcome.
>>
>>
>> -David
>>
>
Re: javassist removal
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi,
yes [proxy] was in the discussion, the choice will be done depending on
benchmarks
- Romain
2012/8/9 Sven Linstaedt <sv...@googlemail.com>
> Hi, sounds like you have something similar to commons-proxy [1] in
> mind, when creating an abstraction of the proxy class generation
> library. Have you already considered using it?
>
> br, Sven
>
>
> [1] https://commons.apache.org/proxy/
>
>
> 2012/8/9 David Blevins <da...@gmail.com>:
> > Hey All,
> >
> > Heads up that I'd like to investigate removing javassist and replacing
> it with some simple ASM code to create subclass based proxies. The proxy
> code is the small part, the bigger part is refactoring out the
> MethodHandler classes and replacing them with
> java.lang.reflect.InvocationHandler implementations.
> >
> > As usual I'll probably look for an intermediary step in refactoring it
> out, maybe some way to keep the MethodHandlers and get all the code working
> with a different proxy impl, then refactor the handlers.
> >
> > Any thoughts or comments welcome.
> >
> >
> > -David
> >
>
Re: javassist removal
Posted by Sven Linstaedt <sv...@googlemail.com>.
Hi, sounds like you have something similar to commons-proxy [1] in
mind, when creating an abstraction of the proxy class generation
library. Have you already considered using it?
br, Sven
[1] https://commons.apache.org/proxy/
2012/8/9 David Blevins <da...@gmail.com>:
> Hey All,
>
> Heads up that I'd like to investigate removing javassist and replacing it with some simple ASM code to create subclass based proxies. The proxy code is the small part, the bigger part is refactoring out the MethodHandler classes and replacing them with java.lang.reflect.InvocationHandler implementations.
>
> As usual I'll probably look for an intermediary step in refactoring it out, maybe some way to keep the MethodHandlers and get all the code working with a different proxy impl, then refactor the handlers.
>
> Any thoughts or comments welcome.
>
>
> -David
>
Re: Yan: javassist removal
Posted by Mark Struberg <st...@yahoo.de>.
gnnn...
s/no movin/not moving/ :)
----- Original Message -----
> From: Mark Struberg <st...@yahoo.de>
> To: "dev@openwebbeans.apache.org" <de...@openwebbeans.apache.org>
> Cc:
> Sent: Thursday, August 9, 2012 9:31 PM
> Subject: Re: Yan: javassist removal
>
> I fear this is not easy to do.
>
> Either we use commons-proxy (which is exactly such an abstraction SPI layer) or
> we just do it ourselfs. The real work is no movin the proxy generation to ASM
> but to migrate our MethodHandlers to InvocationHandlers. It's not a huge
> effort, but it is certainly quite some homework.
>
> An SPI only makes sense if it abstracts away something. In that case it is
> already there. I already looked at Davids code he uses for OpenEJB. It uses he
> java.lang.reflect.Proxy interfaces but contrary to the jdk proxy stuff he
> additionally creates subclasses as class-proxies. Thus I see no need for another
> SPI as we already use the standard Java interfaces for it.
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
>> From: Gurkan Erdogdu <gu...@yahoo.com>
>> To: "dev@openwebbeans.apache.org"
> <de...@openwebbeans.apache.org>
>> Cc:
>> Sent: Thursday, August 9, 2012 8:51 PM
>> Subject: Yan: javassist removal
>>
>> Hello David
>>
>> I favor that we can implement a common SPI like other integrations and
> refactor
>> code to use SPI (Pluggable way of using javassist or ASM).
>>
>>
>> Thanks.
>>
>>
>> Gurkan
>>
>>
>>
>> ________________________________
>> Kimden: David Blevins <da...@gmail.com>
>> Kime: dev@openwebbeans.apache.org
>> Gönderildiği Tarih: 9 Ağustos 2012 7:27 Perşembe
>> Konu: javassist removal
>>
>> Hey All,
>>
>> Heads up that I'd like to investigate removing javassist and replacing
> it
>> with some simple ASM code to create subclass based proxies. The proxy code
> is
>> the small part, the bigger part is refactoring out the MethodHandler
> classes and
>> replacing them with java.lang.reflect.InvocationHandler implementations.
>>
>> As usual I'll probably look for an intermediary step in refactoring it
> out,
>> maybe some way to keep the MethodHandlers and get all the code working with
> a
>> different proxy impl, then refactor the handlers.
>>
>> Any thoughts or comments welcome.
>>
>>
>> -David
>>
>
Re: Yan: javassist removal
Posted by Mark Struberg <st...@yahoo.de>.
I fear this is not easy to do.
Either we use commons-proxy (which is exactly such an abstraction SPI layer) or we just do it ourselfs. The real work is no movin the proxy generation to ASM but to migrate our MethodHandlers to InvocationHandlers. It's not a huge effort, but it is certainly quite some homework.
An SPI only makes sense if it abstracts away something. In that case it is already there. I already looked at Davids code he uses for OpenEJB. It uses he java.lang.reflect.Proxy interfaces but contrary to the jdk proxy stuff he additionally creates subclasses as class-proxies. Thus I see no need for another SPI as we already use the standard Java interfaces for it.
LieGrue,
strub
----- Original Message -----
> From: Gurkan Erdogdu <gu...@yahoo.com>
> To: "dev@openwebbeans.apache.org" <de...@openwebbeans.apache.org>
> Cc:
> Sent: Thursday, August 9, 2012 8:51 PM
> Subject: Yan: javassist removal
>
> Hello David
>
> I favor that we can implement a common SPI like other integrations and refactor
> code to use SPI (Pluggable way of using javassist or ASM).
>
>
> Thanks.
>
>
> Gurkan
>
>
>
> ________________________________
> Kimden: David Blevins <da...@gmail.com>
> Kime: dev@openwebbeans.apache.org
> Gönderildiği Tarih: 9 Ağustos 2012 7:27 Perşembe
> Konu: javassist removal
>
> Hey All,
>
> Heads up that I'd like to investigate removing javassist and replacing it
> with some simple ASM code to create subclass based proxies. The proxy code is
> the small part, the bigger part is refactoring out the MethodHandler classes and
> replacing them with java.lang.reflect.InvocationHandler implementations.
>
> As usual I'll probably look for an intermediary step in refactoring it out,
> maybe some way to keep the MethodHandlers and get all the code working with a
> different proxy impl, then refactor the handlers.
>
> Any thoughts or comments welcome.
>
>
> -David
>
Yan: javassist removal
Posted by Gurkan Erdogdu <gu...@yahoo.com>.
Hello David
I favor that we can implement a common SPI like other integrations and refactor code to use SPI (Pluggable way of using javassist or ASM).
Thanks.
Gurkan
________________________________
Kimden: David Blevins <da...@gmail.com>
Kime: dev@openwebbeans.apache.org
Gönderildiği Tarih: 9 Ağustos 2012 7:27 Perşembe
Konu: javassist removal
Hey All,
Heads up that I'd like to investigate removing javassist and replacing it with some simple ASM code to create subclass based proxies. The proxy code is the small part, the bigger part is refactoring out the MethodHandler classes and replacing them with java.lang.reflect.InvocationHandler implementations.
As usual I'll probably look for an intermediary step in refactoring it out, maybe some way to keep the MethodHandlers and get all the code working with a different proxy impl, then refactor the handlers.
Any thoughts or comments welcome.
-David