Feature Proposal: Bytecode generated Proxies

["Clute, Andrew" <An...@osn.state.oh.us>]

In my everyday application, I am starting to see some issues where
restoring graphs that contain references to other graphs is slowing us
down. We make extensive use of Collection Proxies, but make minimal use
of Reference Proxies (1 class is proxy-enabled out of about 200 domain
objects) -- due mostly to the overhead of maintaining Interfaces for the
objects.
 
I believe I am not alone in this case. As more and more people start to
move their existing code-bases over to an O/R mapping system, they are
going to face a similar scenario. As such, I would like to propose the
addition of byte-code generated Proxies. This would allow for the
returning of true 'flat' objects, and delaying the walking of graphs
until needed. There has been talk before of this, but most of that has
died in the trenches. I would like to pick this back up and get this
feature implemented into OJB.
 
So, what exactly are we talking about?
Adding the ability for users to specify reference proxies for classes
that are not backed by an interface. The proxies themselves will be
generated via a bytecode library (most notably CGLIB).
 
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.
They would work the exact same way. They can use the same
InvocationHandler stack (IndirectionHandler) and they still do
method-interception. Very little, if any, user code would need to be
changed to take advantage.
 
Libraries like CGLIB only do method-level interception, so the generated
classes do not contain any of the same fields -- so doing field
introspection would break on the proxies. While this seems like a pretty
big "gotcha", the Proxies currently being used by OJB (JDK produced)
have the same constraint. So, no new issues are being introduced, just
old ones not being addressed
 
2) One could go a route where the generation of Proxies could be an
externalized, plugged-in process, and thus allow different bytecode
libraries the ability to generate the proxy. This is probably a good
idea in the long run, but not necessary for a first release of this. By
sticking to one library, an effective replacement solution can be
introduced almost immediately.
 
3) I teeter back and forth on this: You could even go so far as to have
all Proxies generated by CGLIB, interface-backed and auto-generated
ones. You could remove the JDK versions and have one consistent proxy
generation. I don't know exactly what I think about this yet, as there
might be some benefits to having JDK-produced ones for interface-backed,
but I don't know yet.
 
4) How it affects configuration (I am open to all kinds of suggestions):
My initial thought is to keep the current pattern in place of allowing
ClassDescriptors to set a proxy-class that is secondary to
ReferenceDescriptors that specify "proxy=true". 
 
My initial thought is to follow the pattern for the atuo-XXX fields and
add additional values for the proxy setting in ReferenceDescriptors.
Whereas the current values are "true", "false", the new values would be
"auto-gen", "interface", "none", "true" (interface) and false ("none").
 
On the ClassDescriptors, the only option is to specify the proxy-class,
and in that case a user could continue to specify an interface, or they
could either specify the same class as the proxy (the way Hibernate does
it), or the setting could look for a key word, like "auto-gen".
 

I currently have a working prototype of this (without the configuration
right now), and have not seen any significant issues. 
 
I would love to get any and all feedback about the possibility of adding
this to OJB (which version would be best?)
 
Thank you for your time,
 
-Andrew
 
 

Re: Feature Proposal: Bytecode generated Proxies

[Brian McCallister <br...@apache.org>]

I'd actually like to go much further than bytecode proxies replacing 
jdk proxies, I'd like to move state tracking etc fully to the instance 
via bytcode munging and not have to track it externally. This has the 
nice side effect of letting transactional object get garbage collected 
if memory gets low (so you can stream through them for example).

IIRC Chris added field interception capabilities to cglib a while back 
(at the request, of, erm, *cough* hibernate *cough*). I'd be more in 
favor of using (AspectWerks) AWProxy except for its licensing (grr) as 
it is much easier to work with, and provides for much more naturally 
expressed code. I doubt Jonas and company are interested in 
re-licensing it, though. Another option on that is to look at ASM 
directly -- I recall hearing that they were going to bundle up support 
for most of the common use cases, proxying/interception being the #1 
use case.

Aside from those details, I wholly agree with you that we should do 
this. I also think we should proxy collections and references by 
default instead of nulling them by default

-Brian

On Mar 17, 2005, at 11:41 AM, Clute, Andrew wrote:

> In my everyday application, I am starting to see some issues where
> restoring graphs that contain references to other graphs is slowing us
> down. We make extensive use of Collection Proxies, but make minimal use
> of Reference Proxies (1 class is proxy-enabled out of about 200 domain
> objects) -- due mostly to the overhead of maintaining Interfaces for 
> the
> objects.
>
> I believe I am not alone in this case. As more and more people start to
> move their existing code-bases over to an O/R mapping system, they are
> going to face a similar scenario. As such, I would like to propose the
> addition of byte-code generated Proxies. This would allow for the
> returning of true 'flat' objects, and delaying the walking of graphs
> until needed. There has been talk before of this, but most of that has
> died in the trenches. I would like to pick this back up and get this
> feature implemented into OJB.
>
> So, what exactly are we talking about?
> Adding the ability for users to specify reference proxies for classes
> that are not backed by an interface. The proxies themselves will be
> generated via a bytecode library (most notably CGLIB).
>
> 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.
> They would work the exact same way. They can use the same
> InvocationHandler stack (IndirectionHandler) and they still do
> method-interception. Very little, if any, user code would need to be
> changed to take advantage.
>
> Libraries like CGLIB only do method-level interception, so the 
> generated
> classes do not contain any of the same fields -- so doing field
> introspection would break on the proxies. While this seems like a 
> pretty
> big "gotcha", the Proxies currently being used by OJB (JDK produced)
> have the same constraint. So, no new issues are being introduced, just
> old ones not being addressed
>
> 2) One could go a route where the generation of Proxies could be an
> externalized, plugged-in process, and thus allow different bytecode
> libraries the ability to generate the proxy. This is probably a good
> idea in the long run, but not necessary for a first release of this. By
> sticking to one library, an effective replacement solution can be
> introduced almost immediately.
>
> 3) I teeter back and forth on this: You could even go so far as to have
> all Proxies generated by CGLIB, interface-backed and auto-generated
> ones. You could remove the JDK versions and have one consistent proxy
> generation. I don't know exactly what I think about this yet, as there
> might be some benefits to having JDK-produced ones for 
> interface-backed,
> but I don't know yet.
>
> 4) How it affects configuration (I am open to all kinds of 
> suggestions):
> My initial thought is to keep the current pattern in place of allowing
> ClassDescriptors to set a proxy-class that is secondary to
> ReferenceDescriptors that specify "proxy=true".
>
> My initial thought is to follow the pattern for the atuo-XXX fields and
> add additional values for the proxy setting in ReferenceDescriptors.
> Whereas the current values are "true", "false", the new values would be
> "auto-gen", "interface", "none", "true" (interface) and false ("none").
>
> On the ClassDescriptors, the only option is to specify the proxy-class,
> and in that case a user could continue to specify an interface, or they
> could either specify the same class as the proxy (the way Hibernate 
> does
> it), or the setting could look for a key word, like "auto-gen".
>
>
> I currently have a working prototype of this (without the configuration
> right now), and have not seen any significant issues.
>
> I would love to get any and all feedback about the possibility of 
> adding
> this to OJB (which version would be best?)
>
> Thank you for your time,
>
> -Andrew
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org

Re: Feature Proposal: Bytecode generated Proxies

[Jakob Braeuchi <jb...@gmx.ch>]

hi andrew,

Clute, Andrew schrieb:
> In my everyday application, I am starting to see some issues where
> restoring graphs that contain references to other graphs is slowing us
> down. We make extensive use of Collection Proxies, but make minimal use
> of Reference Proxies (1 class is proxy-enabled out of about 200 domain
> objects) -- due mostly to the overhead of maintaining Interfaces for the
> objects.
>  
> I believe I am not alone in this case. As more and more people start to
> move their existing code-bases over to an O/R mapping system, they are
> going to face a similar scenario. As such, I would like to propose the
> addition of byte-code generated Proxies. This would allow for the
> returning of true 'flat' objects, and delaying the walking of graphs
> until needed. There has been talk before of this, but most of that has
> died in the trenches. I would like to pick this back up and get this
> feature implemented into OJB.
>  
> So, what exactly are we talking about?
> Adding the ability for users to specify reference proxies for classes
> that are not backed by an interface. The proxies themselves will be
> generated via a bytecode library (most notably CGLIB).
>  
> 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.

> They would work the exact same way. They can use the same
> InvocationHandler stack (IndirectionHandler) and they still do
> method-interception. Very little, if any, user code would need to be
> changed to take advantage.
>  
> Libraries like CGLIB only do method-level interception, so the generated
> classes do not contain any of the same fields -- so doing field
> introspection would break on the proxies. While this seems like a pretty
> big "gotcha", the Proxies currently being used by OJB (JDK produced)
> have the same constraint. So, no new issues are being introduced, just
> old ones not being addressed
>  
> 2) One could go a route where the generation of Proxies could be an
> externalized, plugged-in process, and thus allow different bytecode
> libraries the ability to generate the proxy. This is probably a good
> idea in the long run, but not necessary for a first release of this. By
> sticking to one library, an effective replacement solution can be
> introduced almost immediately.
>  
> 3) I teeter back and forth on this: You could even go so far as to have
> all Proxies generated by CGLIB, interface-backed and auto-generated
> ones. You could remove the JDK versions and have one consistent proxy
> generation. I don't know exactly what I think about this yet, as there
> might be some benefits to having JDK-produced ones for interface-backed,
> but I don't know yet.

imo we should let the users decide what kind of proxies the like. that's 
why i think the proxy-generator has to be pluggable.

>  
> 4) How it affects configuration (I am open to all kinds of suggestions):
> My initial thought is to keep the current pattern in place of allowing
> ClassDescriptors to set a proxy-class that is secondary to
> ReferenceDescriptors that specify "proxy=true". 
>  
> My initial thought is to follow the pattern for the atuo-XXX fields and
> add additional values for the proxy setting in ReferenceDescriptors.
> Whereas the current values are "true", "false", the new values would be
> "auto-gen", "interface", "none", "true" (interface) and false ("none").

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.

jakob

>  
> On the ClassDescriptors, the only option is to specify the proxy-class,
> and in that case a user could continue to specify an interface, or they
> could either specify the same class as the proxy (the way Hibernate does
> it), or the setting could look for a key word, like "auto-gen".
>  
> 
> I currently have a working prototype of this (without the configuration
> right now), and have not seen any significant issues. 
>  
> I would love to get any and all feedback about the possibility of adding
> this to OJB (which version would be best?)
>  
> Thank you for your time,
>  
> -Andrew
>  
>  
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org