Re: [Springframework-developer] Extending Spring AOP

[Rob H. <ro...@ca...>]

Eugene,

We are fine with direct bytecode manipulation, we just want to avoid it 
if we can. Spring AOP ism't meant to have absolute raw performance. 
Instead it is meant to over competitive performance in any easy to use 
and understand package. With CGLIB, the biggest problem is that we cant 
create specific bytecode for each advice type using CGLIB as is. With 
Janino we can build specific Java code for each each advice type in a 
proxy and then compile this all to bytecode. The compilation will be a 
one off cost for class/advice chain combinations.

We should be providing AWProxy support as well since it covers most of 
our needs, but Janino is a possibility for the proxy platform for the 
future features to be added to Spring AOP.

The ASM sub-library you are talking about sounds nice and I will 
certainly consider using it - can you send more details?

Rob

Eugene Kuleshov wrote:

> Rob,
>
>   I'm not sure where you actually expecting to gain performance by 
> using Janino. i believe that manually crafted bytecode will provide 
> much better control. However if you are not confortable with direct 
> bytecode manipulation you can use one of the existing high-level class 
> proxy generators:
>
>   -- CGLIB (with an appropriate fixes and extensions that CGLIB team 
> should take care of),
>   -- JBoss's Javaassist (closest to Janino in terms of providing 
> Java-like granularity)
>   -- AWProxy (it is directly using ASM and provide enough features for 
> common AOP needs)
>   -- Eric Bruneton of ASM recently proposed a new ASM subproject for 
> most commonly used bytecode transformation (so, perhaps it could 
> generalize CGLIB and/or AWProxy code) This will be the most 
> lightweight but also most low level option.
>
>   I believe that at least one of the above options should give enough 
> comfort to Spring dev team, to it will not be necessary to invent a 
> bycicle and introduce new runtime dependencies.
>
>   Also, just for the record, class proxy will always cause security 
> issues because they can't be instantiated without nested classloading 
> or tricks with injecting classes into current classloaders (like CGLIB 
> is doing), so you have to deal with it using Java security policy.
>
>   regards,
>   Eugene
>
>
>> Oliver,
>>
>> I think you are right on this point - Janino should in theory be much 
>> faster since we can produce specific code for each advice type as 
>> required, and we can do so easily. Coupled with some clever caching 
>> we can do a lot with the Janino approach, make it very performant, 
>> and we have full control over it. I am hoping to add this support in 
>> time for 1.2 but I will be fixing current bugs with the CGLIB 
>> implementation provided I can get the appropriate patches added to 
>> CGLIB as required.
>>
>> Rob
>>
>> Oliver Hutchison wrote:
>>
>>> Using Janino is a great idea.
>>>
>>> A few months back I was playing around with implementing "abstract
>>> schema" for the Spring AOP  subsystem and I did some simple 
>>> benchmarking
>>> of Janino, CGLIB and JDK proxies and found that Janino was surprisingly
>>> efficient given the extra processing it needs to do.
>>>
>>> I generated the proxies using raw java code rather with than a template
>>> system as I didn't want to have any additional dependencies but what
>>> would be really nice is if you could generate the AST directly and I
>>> believe this may be on the way.
>>>
>>> Janino also includes line number (but not local variable) info in the
>>> generated classes. So if you save the code to disk you can step through
>>> the proxy implementation!
>>> Oliver
>>>
>>>
>>>  
>>>
>>>> -----Original Message-----
>>>> From: spr...@li... 
>>>> [mailto:spr...@li...]
>>>> On Behalf Of Rob Harrop
>>>> Sent: Friday, 17 December 2004 11:43 PM
>>>> To: spr...@li...
>>>> Subject: [Springframework-developer] Extending Spring AOP
>>>>
>>>>
>>>> All,
>>>>
>>>> I am planning to add to an additional proxy implementation to 
>>>> Spring to solve some of the problems we are experiencing with other 
>>>> approaches and to allow for additional optimizations and advice 
>>>> types to be added in the most efficient way.
>>>>
>>>> Currently, I'm looking at two separate approaches - Java-based 
>>>> using Janino and Bytecode-based using SERP. The Java-based approach 
>>>> should be quite simple to create and could be coupled with Velocity 
>>>> to externalize much of the boilerplate code needed for the creation 
>>>> of proxy classes. Alternatively we could add a simple abstraction 
>>>> layer on top of Janino, a la .NET CodeDOM (good idea James). The 
>>>> bytecode approach is much more complex and will be harder to debug 
>>>> but it would probably allow for absolute raw performance.
>>>>
>>>> I am comfortable with either approach although I think that Janino 
>>>> would be ideal for our purposes.
>>>>
>>>> Your thoughts?
>>>>
>>>> Rob
>>>>
>>>>
>
>
>
> -------------------------------------------------------
> 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
>
>