You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-dev@db.apache.org by "Clute, Andrew" <An...@osn.state.oh.us> on 2005/03/21 16:45:27 UTC
UPDATE: (was: Feature Proposal: Bytecode generated Proxies)
I have finished the changes to make all dynamic proxies generated by
CGLIB. In the limited testing that I have done, proxy generation using
CGLIB seems to be in the order of 30-50% faster than JDK proxies
(assuming you cache the initial CGLIB Factory). The code is very
straight forward, and works great!
However, at this point I would not recommend introducing it to the 1.0.X
line. :(
While it *should* be completely transparent to the user which proxy
system is being used, there is one vital spot where it does become
apparent: the new generated proxies *are not* of type
java.lang.reflect.Proxy. This could be troublesome for people who have
infrastructure depending on the notion that those objects are of type
Proxy. This change could unknowingly break that code.
So, while this has been very helpful as an R&D project, I think the only
right away do to this is as we have said before, introduce it into the
HEAD as a pluggable interface, with a common base Proxy implementation
that all Proxy plug-ins would generate (like OJBProxy). That way, the
current JDK based implementation could be maintained, and probably be
the default.
-Andrew
> -----Original Message-----
> From: Clute, Andrew [mailto:Andrew.Clute@osn.state.oh.us]
> Sent: Friday, March 18, 2005 2:31 PM
> To: OJB Developers List
> Subject: RE: Feature Proposal: Bytecode generated Proxies
>
>
>
>
> > > There are several points to consider with this, and I am
> > going to try
> > > to hit them all (in no particular order)
> > >
> > > 1) What are the downsides to doing this? If the goal is
> > give a drop-in
> > > replacement to the JDK-generated proxies based on
> > interfaces, then none.
> >
> > if this feature is planned for 1.0.x we should introduce as less
> > incompatibilities as possible.
>
>
> I agree completely. I think the plan of a drop-in replacement
> that is invisable to the user for 1.0.X line and a
> configurable strategy for 1.X is wise. I could see waiting
> for 1.1 to introduce any of this, but the timeline for that
> is so unknown, and I think this could be useful in the
> immediate future.
>
>
>
> > is it really necessary to define the proxy-generator on
> > class-descriptor level ? what's the benefit of having a
> bytecode proxy
> > on one class and a jdk-proxy on the other class. imo we
> could define a
> > global proxy-generator to generate the proxies for classes with
> > proxy='dynamic'
> > and for classes with proxy = 'myclass' it's up to the user.
> >
>
>
> I agree completely, and eventually worked myself to that way.
> My current
> implementation of this only uses CGLIB to generate proxies.
> JDK proxies
> are no longer used. There are no new configuration settings. Setting
> either 'dynamic' at the ClassDescriptor, or 'proxy=true' at the
> ReferenceDescriptor generates a CGLIB-backed Proxy based on the
> itemClass, regardless of what interfaces it implements (since the new
> proxy is guaranteed to implement them all since it is a
> subclass of the
> itemClass).
>
> Thanks for all the feedback! I really do appreciate it. My hope is to
> have something done for the 1.0.X line by early next week that can be
> reviewed, and then I will start work on design for the 1.X lines
> pluggable model.
>
> -Andrew
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: UPDATE: (was: Feature Proposal: Bytecode generated Proxies)
Posted by Martin Kalén <mk...@apache.org>.
Thomas Dudziak wrote:
>>I have finished the changes to make all dynamic proxies generated by
>>CGLIB. In the limited testing that I have done, proxy generation using
>>CGLIB seems to be in the order of 30-50% faster than JDK proxies
>>(assuming you cache the initial CGLIB Factory). The code is very
>>straight forward, and works great!
>>
>>However, at this point I would not recommend introducing it to the 1.0.X
>>line. :(
>>
>>While it *should* be completely transparent to the user which proxy
>>system is being used, there is one vital spot where it does become
>>apparent: the new generated proxies *are not* of type
>>java.lang.reflect.Proxy. This could be troublesome for people who have
>>infrastructure depending on the notion that those objects are of type
>>Proxy. This change could unknowingly break that code.
>
> I would not let this hinder us to introduce cglib in 1.0.x, especially
> when proxies would be that much faster. There are methods in the
> ProxyHelper class that do these kinds of test, so if we document the
> cglib change and encourage anyone to use the ProxyHelper class than
> that should be alright ?!
I tend to agree with Andrew, since it's not a drop in replacement it's
not really good for 1.0.3. In my opinion this is one thing that has not
been good with OJB releases in the past, too much incompatible changes
have been made between RC:s or releases (API breakage between RC:s is a
pain but OK, but releases should just not change on a binary level).
On the other hand if it's going to be pluggable in the trunk, I guess a
backpatch of the pluggable mechanism with a backwards-compatible default
choice of JDK proxies for 1.0.x would be possible.
Regards,
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: UPDATE: (was: Feature Proposal: Bytecode generated Proxies)
Posted by Thomas Dudziak <to...@gmail.com>.
On Mon, 21 Mar 2005 10:45:27 -0500, Clute, Andrew
<An...@osn.state.oh.us> wrote:
> I have finished the changes to make all dynamic proxies generated by
> CGLIB. In the limited testing that I have done, proxy generation using
> CGLIB seems to be in the order of 30-50% faster than JDK proxies
> (assuming you cache the initial CGLIB Factory). The code is very
> straight forward, and works great!
>
> However, at this point I would not recommend introducing it to the 1.0.X
> line. :(
>
> While it *should* be completely transparent to the user which proxy
> system is being used, there is one vital spot where it does become
> apparent: the new generated proxies *are not* of type
> java.lang.reflect.Proxy. This could be troublesome for people who have
> infrastructure depending on the notion that those objects are of type
> Proxy. This change could unknowingly break that code.
I would not let this hinder us to introduce cglib in 1.0.x, especially
when proxies would be that much faster. There are methods in the
ProxyHelper class that do these kinds of test, so if we document the
cglib change and encourage anyone to use the ProxyHelper class than
that should be alright ?!
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org