|
From: Bob L. <cra...@cr...> - 2004-12-19 17:43:46
|
On Dec 19, 2004, at 2:58 AM, Rod Johnson wrote: > Bob > > "Gutting our implementation" isn't quite accurate: proxy creation is > behind an implementation, so it has purely localized effect. Didn't mean to sound inflammatory. Simply meant "replacing the insides." > Our experience has been that CGLIB is getting harder and harder to > maintain, for some of what we need to do with it. Am I going to fall in the same trap? > Have to agree with RJ's point re dynamic proxies being preferable for > various reasons, anyway. The only reason I would prefer DPs is serialization. There are still some problems with serializing circular class proxy references transparently, though most people don't serialize proxies directly anyway, and there is a workaround. Class proxies are better performance wise. For methods with no interceptors, you can delegate directly to the target object or mixin without creating an object array, boxing arguments, etc. I do wish cglib created it's own classloader rather than injecting classes directly into the current one. AFAIK, they do this so proxies can call package-private methods. I'd prefer they just created a new class loader. This would alleviate any security concerns. Bob > Rgds > Rod > > Bob Lee wrote: >> Out of curiosity, what problems are you having with cglib that could >> justify completely gutting your implementation? >> You really can't optimize any more than cglib. The only reason >> AspectWerkz is faster in those micro benchmarks literally amounts to >> one object array creation. If it's that big of a deal, statically >> analyze the bytecode of your interceptor class. If it never uses the >> argument array, use a callback type that doesn't create it. This >> would be insane, but it doesn't force the performance optimization on >> the user. >> Also, notice that all of the methods in the AWBench that take >> arguments, take a single int, which requires boxing. Not something >> that we should worry about. >> In reality, real world stuff like invoking a mixin in Dynaop is as >> fast as AW. >> I'm just wondering because I'm personally liking cglib more and more. >> I just submitted a couple patches to support Dynaop and found their >> code pretty easy to maintain. Also, I've completely dumped dynamic >> proxies in favor of cglib proxies. >> Bob >> On Dec 17, 2004, at 8:50 AM, Eugene Kuleshov wrote: >>> Folks, >>> >>> That is an interesting discussion... >>> >>> I've been looking to Janino for quite some time (actually it is >>> used for some of the ASM's tests, especially to test for ASMifier >>> tool). >>> >>> I can say that maintainer is quite busy and there still some bugs >>> (at least one we hit from ASM test cases). >>> >>> However there is some activity going on about moving Janino to >>> Codehaus and also it has been suggested to port Janino to use ASM as >>> an internal bytecode toolkit underneath (right now it has its own >>> proprietory bytecode manipulation framework). Also I know that >>> Groovy and AW teams has been looking at Janino in order to use it >>> for bytecode generation. The main reason is that Janino has extremly >>> simplistic AST model, that allows to generate high level language >>> constructs in memory without parsing strings (so, you can skip >>> Velocity all together, which would be an important part in order to >>> reduce dependencies for core AOP framework). >>> >>> regards, >>> Eugene >>> >>> >>>> Good point. What is the license (and maturity) of Janino? AWProxy >>>> is also very new. >>>> Colin Sampaleanu wrote: >>>> >>>>> One concern with AspectWerkz is the LGPL license. While Hibernate >>>>> is also LGPL licensed, it is less a core part of Spring than the >>>>> AOP stuff is. Now both Hibernate and AspectWerkz have a >>>>> 'clarifying' statement about their interpretation of the LGPL: >>>>> http://aspectwerkz.codehaus.org/license.html >>>>> such that there is less ambiguity (in theory) about linkage to it, >>>>> but I would be a bit reticent to have the main (non-proxy) AOP >>>>> implementation in Spring be based on AspectWerkz because of >>>>> concerns that Spring using organizations would have about LGPL. >>>>> Whatever it's intentions, the LGPL is so badly worded that a >>>>> number of companies will simply not use any libraries which are >>>>> LGPL licensed... >>>>> >>>>> Colin >>> >>> >>> >>> >>> ------------------------------------------------------- >>> SF email is sponsored by - The IT Product Guide >>> Read honest & candid reviews on hundreds of IT Products from real >>> users. >>> Discover which products truly live up to the hype. Start reading >>> now. http://productguide.itmanagersjournal.com/ >>> _______________________________________________ >>> Springframework-developer mailing list >>> Spr...@li... >>> https://lists.sourceforge.net/lists/listinfo/springframework- >>> developer >> ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT Products from real >> users. >> Discover which products truly live up to the hype. Start reading now. >> http://productguide.itmanagersjournal.com/ >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework-developer > > -- > > ____________________________________________________ > Rod Johnson > CEO, Interface21 - Spring Services from the Source > http://www.springframework.com > > Founder, Spring Framework: > http://www.springframework.org > > Author, "Expert One-on-One J2EE Development Without EJB" > (May 2004, with Juergen Hoeller). > http://www.amazon.com/exec/obidos/ASIN/0764558315/ > > Author, "Expert One-on-One J2EE Design and Development" > (October 2002). > http://www.amazon.com/exec/obidos/tg/detail/-/0764543857/ > > > ____________________________________________________ > Interface21 Limited > Registered Office Summit House, 2-2a Highfield Road, Dartford, Kent > DA1 2JY > Registered in England and Wales No. 5187766 > ____________________________________________________ > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |