[equinox-dev] Equinox Aspects CachingService

[Heiko Seeberger <heiko@xxxxxxxxxxxxx>]

Hi Matthew, Martin and all other Equinox Aspects freaks,

Last year I was working on AJEER but in my current project I decided 
using Equinox Aspects. Not only, because it will be the future standard, 
but also, to be honest, because I ran into some trouble with AJEER which 
Martin and me could not fix. As I need caching for improved startup 
performance I decided to help Martin out and implement a caching service 
for Equinox Aspects. Well, I did, but I found out some issues, the most 
important come here:

1. I doubt that caching can be implemented using 
ClassLoadingStatsHook.recordClassDefine() like in AspectJHook.
ClasspathManager.findClassImpl() calls recordClassDefine() with the 
orignial byte[], not with the woven one. Therefore 
ICachingService.storeClass() will be passed the useless original byte[], 
weaving will not be cached.
I suggest placing the caching calls into AspectJHook.processClass() 
after the weaving calls.

2. I wonder if AspectJAdaptor.shouldWeave() ever returns false.
I checked with a modified implementation of AspectJHook (see 1.) where 
my caching seemed to work but after loading the woven class (from cache) 
sholdWeave() returned true.
Is this magic method surely working correctly? Could anone please 
explain that "first four bytes logic" of shouldWeave() to me?

3. ICachingService.getInstance() and IWeavingService.getInstance() seem 
strange design to me.
This is mixing of concerns. Once the caller (Activator of implementing 
bundles) expects the implementations to be singleton factories, and once 
something different.
Why not refactor getInstance() to ServiceFactories and let only these 
ServiceFactories be OSGi services (singletons)?

4. The method ICachingService.hashNamespace() is never used externally, 
thus can be removed from the interface. Right?

Heiko