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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
