Re: [equinox-dev] Integrating AspectJ Load-Time Weaving into OSGi/Eclips

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

equinox-dev-bounces@xxxxxxxxxxx wrote on 09/20/2005
05:19:42 PM:

> Some more details on the AJEER implementation:
> 
> - AJEER creates separate weaver instances for each bundle. This is
done 
> to ensure that the type resolution for the weaver matches exactly
the 
> class loading of the bundle.

Interesting point.  The view of the world differs
from bundle to bundle.  A and B may both see some package P but may
see completely different version of it.  From your comment hten I
assume that the weaver somehow has a cache or view of the types in a system
such that having just one weaver would result in flat namespace?

What are the performance implications of having multiple
weavers?  Like say I was to have 2000 of them?  Do they stick
around or are the created serially as each bundle is woven?

> - AJEER implements a byte-code caching mechanism
to skip the 
> time-consuming weaving task if nothing has changed (same bundle version,
> same aspect version, same set of aspects).

Cool.  any idea how this might play with a VM
based shared classes mechanism?  On a different point, do you also
have to know about changes in supporting classes (e.g., supertypes) and
classes from fragments?

> Therefore AJEER is separated into two bundles:
the first one enhances 
> the OSGi framework adaptor to intercept class loading and takes care
of 
> the byte-code cache. It provides a hook for other bundles to inject
> bytecode modifier components. The second bundle injects the AspectJ
> weaver as a bytecode modifier component.

So is the adaptor would be one point of overlap between
the two approaches?  Would it make sense to try and reconcile/unify
that hook as first step?  Seems that such a mechanism should be generic.
 Exploring this is interesting as we are wanting to refactor the adpator
to make this kind of change independent of, for example, the disk layout,
which also happens to be defined by adaptors but is clearly not interesting
here.

Jeff