You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by James Carman <ja...@carmanconsulting.com> on 2003/09/20 00:37:55 UTC
[HIVEMIND] Why Javassist?
What is the benefit of using Javassist rather than just using dynamic
proxies? Consider the following code.
public interface Interceptor
{
public Object intercept( Method method, Object[] args, InterceptorChain
chain ) throws Throwable;
}
public interface InterceptorChain
{
public Object intercept( Method method, Object[] args ) throws Throwable;
}
If HiveMind used this approach (similar to how I structured it in my article
at JavaWorld), all interceptor logic could be coded in straight Java code,
rather than using javassist to add logic to the invocation. Consider the
following interceptor...
public class LoggingInterceptor implements Interceptor
{
private Log log = LogFactory.getLog( getClass() );
public Object intercept( Method method, Object[] args, InterceptorChain
chain ) throws Throwable
{
log.debug( "Entering " + method );
chain.intercept( method, args );
log.debug( "Leaving " + method );
}
}
Now, this is a trivial example, but you can see that the potential is there
for a more robust implementation. Maybe I'm just not understanding the
framework correctly, but I don't see how javassist buys us much and it adds
a TREMENDOUS complexity! This code is MUCH simpler than the
LoggingInterceptorFactory class! An added bonus, we can rely upon the
COMPILER rather than waiting until runtime to find a typo.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [HIVEMIND] Why Javassist?
Posted by Christian Essl <ch...@yahoo.de>.
On Fri, 19 Sep 2003 18:56:08 -0400, James Carman
<ja...@carmanconsulting.com> wrote:
> Since you stated on the website that HiveMind is "agnostic" about how
> interceptors are implemented, is there a way to use proxies rather than
> javassist?
>
Yes you can use DynamicProxies. Just create a ServiceInterceptorFactory
Service like this:
public class DynaInterceptorService implements ServiceInterceptorFactory
{
public void createInterceptor(InterceptorStack stack, Module
invokingModule, List parameters)
{
ClassLoader loader = stack.getServiceModule().getClassResolver()
.getClassLoader();
Class interfaceCl = stack.getServiceInterface();
Object toWrap = stack.peek();
InvocationHandler iHandler = new MyInvocationHandler(toWrap); //thats
where you have all your interception code
Object intercepted = Proxy.newProxyInstance(loader,new
Class[]{interfaceCl},iHandler);
stack.push(intercepted); //push your intercepted object on the stack
}
}
Than define the service
<service-point id="MyInterceptorFactory"
interface="org.apache.commons.hivemind.ServiceInterceptorFactory">
<create-instance class="DynaInterceptorService"/>
</service-point>
Than use it like normal:
<interceptor service-id="MyInterceptorFactory"/>
> -----Original Message-----
> From: Howard M. Lewis Ship [mailto:hlship@comcast.net] Sent: Friday,
> September 19, 2003 6:45 PM
> To: 'Jakarta Commons Developers List'
> Subject: RE: [HIVEMIND] Why Javassist?
>
> Mostly, because of the improved speed. Javassist code will not use any
> runtime reflection; its pure
> java code no different from what's generated by the java compiler, so
> Hotspot can optimize it quite
> a bit.
>
> Reflection is faster in JDK 1.4, but still slower than full-bore code.
>
> http://www.freeroller.net/page/hlship/20030708
>
> I saw improvements of at least 5x using Javassist vs. JDK proxies. Since
> then, I've optimized the
> interceptors even more by leveraging the actual types of objects (i.e.,
> using invokevirtual rather
> than invokeinterface). Still, it may all disappear into the noise of a
> real
> application (that hits a
> database, or an EJB via RMI).
>
> Finally, by using Javassist, I could implement toString() sensibly in the
> fabricated interceptor or
> proxy, which is very, very useful when debugging (since there's no source
> to
> step into for
> fabricated classes).
>
> --
> Howard M. Lewis Ship
> Creator, Tapestry: Java Web Components
> http://jakarta.apache.org/tapestry
> http://jakarta.apache.org/commons/sandbox/hivemind/
> http://javatapestry.blogspot.com
>
>> -----Original Message-----
>> From: James Carman [mailto:james@carmanconsulting.com] Sent: Friday,
>> September 19, 2003 6:38 PM
>> To: commons-dev@jakarta.apache.org
>> Subject: [HIVEMIND] Why Javassist?
>>
>>
>> What is the benefit of using Javassist rather than just using dynamic
>> proxies? Consider the following code.
>>
>> public interface Interceptor
>> { public Object intercept( Method method, Object[] args,
>> InterceptorChain chain ) throws Throwable; }
>>
>> public interface InterceptorChain
>> {
>> public Object intercept( Method method, Object[] args ) throws
>> Throwable; }
>>
>> If HiveMind used this approach (similar to how I structured it in my
>> article at JavaWorld), all interceptor logic could be coded in straight
>> Java code, rather than using javassist to add logic to the invocation.
>> Consider the following interceptor...
>>
>> public class LoggingInterceptor implements Interceptor
>> {
>> private Log log = LogFactory.getLog( getClass() );
>> public Object intercept( Method method, Object[] args, InterceptorChain
>> chain ) throws Throwable
>> {
>> log.debug( "Entering " + method );
>> chain.intercept( method, args );
>> log.debug( "Leaving " + method );
>> }
>> }
>>
>> Now, this is a trivial example, but you can see that the potential is
>> there for a more robust implementation. Maybe I'm just not
>> understanding the framework correctly, but I don't see how javassist
>> buys us much and it adds a TREMENDOUS complexity! This code is MUCH
>> simpler than the LoggingInterceptorFactory class! An added bonus, we
>> can rely upon the COMPILER rather than waiting until runtime to find a
>> typo.
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [HIVEMIND] Why Javassist?
Posted by Christian Essl <ch...@yahoo.de>.
On Fri, 19 Sep 2003 18:56:08 -0400, James Carman
<ja...@carmanconsulting.com> wrote:
> Since you stated on the website that HiveMind is "agnostic" about how
> interceptors are implemented, is there a way to use proxies rather than
> javassist?
>
Yes you can use DynamicProxies. Just create a ServiceInterceptorFactory
Service like this:
public class DynaInterceptorService implements ServiceInterceptorFactory
{
public void createInterceptor(InterceptorStack stack, Module
invokingModule, List parameters)
{
ClassLoader loader = stack.getServiceModule().getClassResolver()
.getClassLoader();
Class interfaceCl = stack.getServiceInterface();
Object toWrap = stack.peek();
InvocationHandler iHandler = new MyInvocationHandler(toWrap); //thats
where you have all your interception code
Object intercepted = Proxy.newProxyInstance(loader,new
Class[]{interfaceCl},iHandler);
stack.push(intercepted); //push your intercepted object on the stack
}
}
Than define the service
<service-point id="MyInterceptorFactory"
interface="org.apache.commons.hivemind.ServiceInterceptorFactory">
<create-instance class="DynaInterceptorService"/>
</service-point>
Than use it like normal:
<interceptor service-id="MyInterceptorFactory"/>
> -----Original Message-----
> From: Howard M. Lewis Ship [mailto:hlship@comcast.net] Sent: Friday,
> September 19, 2003 6:45 PM
> To: 'Jakarta Commons Developers List'
> Subject: RE: [HIVEMIND] Why Javassist?
>
> Mostly, because of the improved speed. Javassist code will not use any
> runtime reflection; its pure
> java code no different from what's generated by the java compiler, so
> Hotspot can optimize it quite
> a bit.
>
> Reflection is faster in JDK 1.4, but still slower than full-bore code.
>
> http://www.freeroller.net/page/hlship/20030708
>
> I saw improvements of at least 5x using Javassist vs. JDK proxies. Since
> then, I've optimized the
> interceptors even more by leveraging the actual types of objects (i.e.,
> using invokevirtual rather
> than invokeinterface). Still, it may all disappear into the noise of a
> real
> application (that hits a
> database, or an EJB via RMI).
>
> Finally, by using Javassist, I could implement toString() sensibly in the
> fabricated interceptor or
> proxy, which is very, very useful when debugging (since there's no source
> to
> step into for
> fabricated classes).
>
> --
> Howard M. Lewis Ship
> Creator, Tapestry: Java Web Components
> http://jakarta.apache.org/tapestry
> http://jakarta.apache.org/commons/sandbox/hivemind/
> http://javatapestry.blogspot.com
>
>> -----Original Message-----
>> From: James Carman [mailto:james@carmanconsulting.com] Sent: Friday,
>> September 19, 2003 6:38 PM
>> To: commons-dev@jakarta.apache.org
>> Subject: [HIVEMIND] Why Javassist?
>>
>>
>> What is the benefit of using Javassist rather than just using dynamic
>> proxies? Consider the following code.
>>
>> public interface Interceptor
>> { public Object intercept( Method method, Object[] args,
>> InterceptorChain chain ) throws Throwable; }
>>
>> public interface InterceptorChain
>> {
>> public Object intercept( Method method, Object[] args ) throws
>> Throwable; }
>>
>> If HiveMind used this approach (similar to how I structured it in my
>> article at JavaWorld), all interceptor logic could be coded in straight
>> Java code, rather than using javassist to add logic to the invocation.
>> Consider the following interceptor...
>>
>> public class LoggingInterceptor implements Interceptor
>> {
>> private Log log = LogFactory.getLog( getClass() );
>> public Object intercept( Method method, Object[] args, InterceptorChain
>> chain ) throws Throwable
>> {
>> log.debug( "Entering " + method );
>> chain.intercept( method, args );
>> log.debug( "Leaving " + method );
>> }
>> }
>>
>> Now, this is a trivial example, but you can see that the potential is
>> there for a more robust implementation. Maybe I'm just not
>> understanding the framework correctly, but I don't see how javassist
>> buys us much and it adds a TREMENDOUS complexity! This code is MUCH
>> simpler than the LoggingInterceptorFactory class! An added bonus, we
>> can rely upon the COMPILER rather than waiting until runtime to find a
>> typo.
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
RE: [HIVEMIND] Why Javassist?
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
Absolutely; if you look at the ServiceInterceptorFactory interface, there's no mention of Javassist
or the ClassFactory service. The implementations chose to do it this way; I think inside the unit
tests, the Count service may still be implemented using proxies.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
> -----Original Message-----
> From: James Carman [mailto:james@carmanconsulting.com]
> Sent: Friday, September 19, 2003 6:56 PM
> To: 'Jakarta Commons Developers List'
> Subject: RE: [HIVEMIND] Why Javassist?
>
>
> Since you stated on the website that HiveMind is "agnostic"
> about how interceptors are implemented, is there a way to use
> proxies rather than javassist?
>
> -----Original Message-----
> From: Howard M. Lewis Ship [mailto:hlship@comcast.net]
> Sent: Friday, September 19, 2003 6:45 PM
> To: 'Jakarta Commons Developers List'
> Subject: RE: [HIVEMIND] Why Javassist?
>
> Mostly, because of the improved speed. Javassist code will
> not use any runtime reflection; its pure java code no
> different from what's generated by the java compiler, so
> Hotspot can optimize it quite a bit.
>
> Reflection is faster in JDK 1.4, but still slower than full-bore code.
>
> http://www.freeroller.net/page/hlship/20030708
>
> I saw improvements of at least 5x using Javassist vs. JDK
> proxies. Since then, I've optimized the interceptors even
> more by leveraging the actual types of objects (i.e., using
> invokevirtual rather than invokeinterface). Still, it may all
> disappear into the noise of a real application (that hits a
> database, or an EJB via RMI).
>
> Finally, by using Javassist, I could implement toString()
> sensibly in the fabricated interceptor or proxy, which is
> very, very useful when debugging (since there's no source to
> step into for fabricated classes).
>
> --
> Howard M. Lewis Ship
> Creator, Tapestry: Java Web Components
> http://jakarta.apache.org/tapestry
> http://jakarta.apache.org/commons/sandbox/hivemind/
> http://javatapestry.blogspot.com
>
> > -----Original Message-----
> > From: James Carman [mailto:james@carmanconsulting.com]
> > Sent: Friday, September 19, 2003 6:38 PM
> > To: commons-dev@jakarta.apache.org
> > Subject: [HIVEMIND] Why Javassist?
> >
> >
> > What is the benefit of using Javassist rather than just using
> > dynamic proxies? Consider the following code.
> >
> > public interface Interceptor
> > {
> > public Object intercept( Method method, Object[] args,
> > InterceptorChain chain ) throws Throwable; }
> >
> > public interface InterceptorChain
> > {
> > public Object intercept( Method method, Object[] args )
> > throws Throwable; }
> >
> > If HiveMind used this approach (similar to how I structured
> > it in my article at JavaWorld), all interceptor logic could
> > be coded in straight Java code, rather than using javassist
> > to add logic to the invocation. Consider the following
> interceptor...
> >
> > public class LoggingInterceptor implements Interceptor
> > {
> > private Log log = LogFactory.getLog( getClass() );
> > public Object intercept( Method method, Object[] args,
> > InterceptorChain chain ) throws Throwable
> > {
> > log.debug( "Entering " + method );
> > chain.intercept( method, args );
> > log.debug( "Leaving " + method );
> > }
> > }
> >
> > Now, this is a trivial example, but you can see that the
> > potential is there for a more robust implementation. Maybe
> > I'm just not understanding the framework correctly, but I
> > don't see how javassist buys us much and it adds a TREMENDOUS
> > complexity! This code is MUCH simpler than the
> > LoggingInterceptorFactory class! An added bonus, we can rely
> > upon the COMPILER rather than waiting until runtime to find a typo.
> >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
RE: [HIVEMIND] Why Javassist?
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
Absolutely; if you look at the ServiceInterceptorFactory interface, there's no mention of Javassist
or the ClassFactory service. The implementations chose to do it this way; I think inside the unit
tests, the Count service may still be implemented using proxies.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
> -----Original Message-----
> From: James Carman [mailto:james@carmanconsulting.com]
> Sent: Friday, September 19, 2003 6:56 PM
> To: 'Jakarta Commons Developers List'
> Subject: RE: [HIVEMIND] Why Javassist?
>
>
> Since you stated on the website that HiveMind is "agnostic"
> about how interceptors are implemented, is there a way to use
> proxies rather than javassist?
>
> -----Original Message-----
> From: Howard M. Lewis Ship [mailto:hlship@comcast.net]
> Sent: Friday, September 19, 2003 6:45 PM
> To: 'Jakarta Commons Developers List'
> Subject: RE: [HIVEMIND] Why Javassist?
>
> Mostly, because of the improved speed. Javassist code will
> not use any runtime reflection; its pure java code no
> different from what's generated by the java compiler, so
> Hotspot can optimize it quite a bit.
>
> Reflection is faster in JDK 1.4, but still slower than full-bore code.
>
> http://www.freeroller.net/page/hlship/20030708
>
> I saw improvements of at least 5x using Javassist vs. JDK
> proxies. Since then, I've optimized the interceptors even
> more by leveraging the actual types of objects (i.e., using
> invokevirtual rather than invokeinterface). Still, it may all
> disappear into the noise of a real application (that hits a
> database, or an EJB via RMI).
>
> Finally, by using Javassist, I could implement toString()
> sensibly in the fabricated interceptor or proxy, which is
> very, very useful when debugging (since there's no source to
> step into for fabricated classes).
>
> --
> Howard M. Lewis Ship
> Creator, Tapestry: Java Web Components
> http://jakarta.apache.org/tapestry
> http://jakarta.apache.org/commons/sandbox/hivemind/
> http://javatapestry.blogspot.com
>
> > -----Original Message-----
> > From: James Carman [mailto:james@carmanconsulting.com]
> > Sent: Friday, September 19, 2003 6:38 PM
> > To: commons-dev@jakarta.apache.org
> > Subject: [HIVEMIND] Why Javassist?
> >
> >
> > What is the benefit of using Javassist rather than just using
> > dynamic proxies? Consider the following code.
> >
> > public interface Interceptor
> > {
> > public Object intercept( Method method, Object[] args,
> > InterceptorChain chain ) throws Throwable; }
> >
> > public interface InterceptorChain
> > {
> > public Object intercept( Method method, Object[] args )
> > throws Throwable; }
> >
> > If HiveMind used this approach (similar to how I structured
> > it in my article at JavaWorld), all interceptor logic could
> > be coded in straight Java code, rather than using javassist
> > to add logic to the invocation. Consider the following
> interceptor...
> >
> > public class LoggingInterceptor implements Interceptor
> > {
> > private Log log = LogFactory.getLog( getClass() );
> > public Object intercept( Method method, Object[] args,
> > InterceptorChain chain ) throws Throwable
> > {
> > log.debug( "Entering " + method );
> > chain.intercept( method, args );
> > log.debug( "Leaving " + method );
> > }
> > }
> >
> > Now, this is a trivial example, but you can see that the
> > potential is there for a more robust implementation. Maybe
> > I'm just not understanding the framework correctly, but I
> > don't see how javassist buys us much and it adds a TREMENDOUS
> > complexity! This code is MUCH simpler than the
> > LoggingInterceptorFactory class! An added bonus, we can rely
> > upon the COMPILER rather than waiting until runtime to find a typo.
> >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [HIVEMIND] Why Javassist?
Posted by James Carman <ja...@carmanconsulting.com>.
Since you stated on the website that HiveMind is "agnostic" about how
interceptors are implemented, is there a way to use proxies rather than
javassist?
-----Original Message-----
From: Howard M. Lewis Ship [mailto:hlship@comcast.net]
Sent: Friday, September 19, 2003 6:45 PM
To: 'Jakarta Commons Developers List'
Subject: RE: [HIVEMIND] Why Javassist?
Mostly, because of the improved speed. Javassist code will not use any
runtime reflection; its pure
java code no different from what's generated by the java compiler, so
Hotspot can optimize it quite
a bit.
Reflection is faster in JDK 1.4, but still slower than full-bore code.
http://www.freeroller.net/page/hlship/20030708
I saw improvements of at least 5x using Javassist vs. JDK proxies. Since
then, I've optimized the
interceptors even more by leveraging the actual types of objects (i.e.,
using invokevirtual rather
than invokeinterface). Still, it may all disappear into the noise of a real
application (that hits a
database, or an EJB via RMI).
Finally, by using Javassist, I could implement toString() sensibly in the
fabricated interceptor or
proxy, which is very, very useful when debugging (since there's no source to
step into for
fabricated classes).
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
> -----Original Message-----
> From: James Carman [mailto:james@carmanconsulting.com]
> Sent: Friday, September 19, 2003 6:38 PM
> To: commons-dev@jakarta.apache.org
> Subject: [HIVEMIND] Why Javassist?
>
>
> What is the benefit of using Javassist rather than just using
> dynamic proxies? Consider the following code.
>
> public interface Interceptor
> {
> public Object intercept( Method method, Object[] args,
> InterceptorChain chain ) throws Throwable; }
>
> public interface InterceptorChain
> {
> public Object intercept( Method method, Object[] args )
> throws Throwable; }
>
> If HiveMind used this approach (similar to how I structured
> it in my article at JavaWorld), all interceptor logic could
> be coded in straight Java code, rather than using javassist
> to add logic to the invocation. Consider the following interceptor...
>
> public class LoggingInterceptor implements Interceptor
> {
> private Log log = LogFactory.getLog( getClass() );
> public Object intercept( Method method, Object[] args,
> InterceptorChain chain ) throws Throwable
> {
> log.debug( "Entering " + method );
> chain.intercept( method, args );
> log.debug( "Leaving " + method );
> }
> }
>
> Now, this is a trivial example, but you can see that the
> potential is there for a more robust implementation. Maybe
> I'm just not understanding the framework correctly, but I
> don't see how javassist buys us much and it adds a TREMENDOUS
> complexity! This code is MUCH simpler than the
> LoggingInterceptorFactory class! An added bonus, we can rely
> upon the COMPILER rather than waiting until runtime to find a typo.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [HIVEMIND] Why Javassist?
Posted by James Carman <ja...@carmanconsulting.com>.
Since you stated on the website that HiveMind is "agnostic" about how
interceptors are implemented, is there a way to use proxies rather than
javassist?
-----Original Message-----
From: Howard M. Lewis Ship [mailto:hlship@comcast.net]
Sent: Friday, September 19, 2003 6:45 PM
To: 'Jakarta Commons Developers List'
Subject: RE: [HIVEMIND] Why Javassist?
Mostly, because of the improved speed. Javassist code will not use any
runtime reflection; its pure
java code no different from what's generated by the java compiler, so
Hotspot can optimize it quite
a bit.
Reflection is faster in JDK 1.4, but still slower than full-bore code.
http://www.freeroller.net/page/hlship/20030708
I saw improvements of at least 5x using Javassist vs. JDK proxies. Since
then, I've optimized the
interceptors even more by leveraging the actual types of objects (i.e.,
using invokevirtual rather
than invokeinterface). Still, it may all disappear into the noise of a real
application (that hits a
database, or an EJB via RMI).
Finally, by using Javassist, I could implement toString() sensibly in the
fabricated interceptor or
proxy, which is very, very useful when debugging (since there's no source to
step into for
fabricated classes).
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
> -----Original Message-----
> From: James Carman [mailto:james@carmanconsulting.com]
> Sent: Friday, September 19, 2003 6:38 PM
> To: commons-dev@jakarta.apache.org
> Subject: [HIVEMIND] Why Javassist?
>
>
> What is the benefit of using Javassist rather than just using
> dynamic proxies? Consider the following code.
>
> public interface Interceptor
> {
> public Object intercept( Method method, Object[] args,
> InterceptorChain chain ) throws Throwable; }
>
> public interface InterceptorChain
> {
> public Object intercept( Method method, Object[] args )
> throws Throwable; }
>
> If HiveMind used this approach (similar to how I structured
> it in my article at JavaWorld), all interceptor logic could
> be coded in straight Java code, rather than using javassist
> to add logic to the invocation. Consider the following interceptor...
>
> public class LoggingInterceptor implements Interceptor
> {
> private Log log = LogFactory.getLog( getClass() );
> public Object intercept( Method method, Object[] args,
> InterceptorChain chain ) throws Throwable
> {
> log.debug( "Entering " + method );
> chain.intercept( method, args );
> log.debug( "Leaving " + method );
> }
> }
>
> Now, this is a trivial example, but you can see that the
> potential is there for a more robust implementation. Maybe
> I'm just not understanding the framework correctly, but I
> don't see how javassist buys us much and it adds a TREMENDOUS
> complexity! This code is MUCH simpler than the
> LoggingInterceptorFactory class! An added bonus, we can rely
> upon the COMPILER rather than waiting until runtime to find a typo.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [HIVEMIND] Why Javassist?
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
Mostly, because of the improved speed. Javassist code will not use any runtime reflection; its pure
java code no different from what's generated by the java compiler, so Hotspot can optimize it quite
a bit.
Reflection is faster in JDK 1.4, but still slower than full-bore code.
http://www.freeroller.net/page/hlship/20030708
I saw improvements of at least 5x using Javassist vs. JDK proxies. Since then, I've optimized the
interceptors even more by leveraging the actual types of objects (i.e., using invokevirtual rather
than invokeinterface). Still, it may all disappear into the noise of a real application (that hits a
database, or an EJB via RMI).
Finally, by using Javassist, I could implement toString() sensibly in the fabricated interceptor or
proxy, which is very, very useful when debugging (since there's no source to step into for
fabricated classes).
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
> -----Original Message-----
> From: James Carman [mailto:james@carmanconsulting.com]
> Sent: Friday, September 19, 2003 6:38 PM
> To: commons-dev@jakarta.apache.org
> Subject: [HIVEMIND] Why Javassist?
>
>
> What is the benefit of using Javassist rather than just using
> dynamic proxies? Consider the following code.
>
> public interface Interceptor
> {
> public Object intercept( Method method, Object[] args,
> InterceptorChain chain ) throws Throwable; }
>
> public interface InterceptorChain
> {
> public Object intercept( Method method, Object[] args )
> throws Throwable; }
>
> If HiveMind used this approach (similar to how I structured
> it in my article at JavaWorld), all interceptor logic could
> be coded in straight Java code, rather than using javassist
> to add logic to the invocation. Consider the following interceptor...
>
> public class LoggingInterceptor implements Interceptor
> {
> private Log log = LogFactory.getLog( getClass() );
> public Object intercept( Method method, Object[] args,
> InterceptorChain chain ) throws Throwable
> {
> log.debug( "Entering " + method );
> chain.intercept( method, args );
> log.debug( "Leaving " + method );
> }
> }
>
> Now, this is a trivial example, but you can see that the
> potential is there for a more robust implementation. Maybe
> I'm just not understanding the framework correctly, but I
> don't see how javassist buys us much and it adds a TREMENDOUS
> complexity! This code is MUCH simpler than the
> LoggingInterceptorFactory class! An added bonus, we can rely
> upon the COMPILER rather than waiting until runtime to find a typo.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
RE: [HIVEMIND] Why Javassist?
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
Mostly, because of the improved speed. Javassist code will not use any runtime reflection; its pure
java code no different from what's generated by the java compiler, so Hotspot can optimize it quite
a bit.
Reflection is faster in JDK 1.4, but still slower than full-bore code.
http://www.freeroller.net/page/hlship/20030708
I saw improvements of at least 5x using Javassist vs. JDK proxies. Since then, I've optimized the
interceptors even more by leveraging the actual types of objects (i.e., using invokevirtual rather
than invokeinterface). Still, it may all disappear into the noise of a real application (that hits a
database, or an EJB via RMI).
Finally, by using Javassist, I could implement toString() sensibly in the fabricated interceptor or
proxy, which is very, very useful when debugging (since there's no source to step into for
fabricated classes).
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
> -----Original Message-----
> From: James Carman [mailto:james@carmanconsulting.com]
> Sent: Friday, September 19, 2003 6:38 PM
> To: commons-dev@jakarta.apache.org
> Subject: [HIVEMIND] Why Javassist?
>
>
> What is the benefit of using Javassist rather than just using
> dynamic proxies? Consider the following code.
>
> public interface Interceptor
> {
> public Object intercept( Method method, Object[] args,
> InterceptorChain chain ) throws Throwable; }
>
> public interface InterceptorChain
> {
> public Object intercept( Method method, Object[] args )
> throws Throwable; }
>
> If HiveMind used this approach (similar to how I structured
> it in my article at JavaWorld), all interceptor logic could
> be coded in straight Java code, rather than using javassist
> to add logic to the invocation. Consider the following interceptor...
>
> public class LoggingInterceptor implements Interceptor
> {
> private Log log = LogFactory.getLog( getClass() );
> public Object intercept( Method method, Object[] args,
> InterceptorChain chain ) throws Throwable
> {
> log.debug( "Entering " + method );
> chain.intercept( method, args );
> log.debug( "Leaving " + method );
> }
> }
>
> Now, this is a trivial example, but you can see that the
> potential is there for a more robust implementation. Maybe
> I'm just not understanding the framework correctly, but I
> don't see how javassist buys us much and it adds a TREMENDOUS
> complexity! This code is MUCH simpler than the
> LoggingInterceptorFactory class! An added bonus, we can rely
> upon the COMPILER rather than waiting until runtime to find a typo.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org