|Re: [equinox-dev] support for component API refactoring|
I think this is a really interesting topic and it would be great if some kind of aspect runtime could help reducing the problem of API evolution somehow. I thought about it since you mentioned it during out short phone conference and these are my first thoughts about it:
My colleque Stefan Roock is writing his PhD thesis about a quite related topic (supporting framework API evolution). He analyzed in great detail for what kinds of API changes it is possible to adapt clients automatically and what dangerous situations might appear. I think we could really benefit from his work to discuss the challenges and especially the restrictions behind this idea. Therefore I would like to invite Stefan to join the discussion. Hope this is okay with you.
I also thought about using aspects to adapting clients to class name changes, for example. I didn't come up with an idea how to solve this. A problem seems to be that the current AspectJ language is not able to replace a type reference to a different type, I think. And the current AspectJ weaver needs the type information that are used within the class to be woven (would be a problem if you rename a class). But Matthew might know more about the AspectJ requirements...
I could think of some kind of specialized weaving mechanism that does not use the AspectJ implementation. But a specialized weaving would need a specialized aspect language or API evolution language to describe the API changes to adapt. Could be quite interesting...
Just to let you know about my first thoughts...
To date we have operated under a 100% binary compatibility rule with an underlying assumption that the original code itself could not be modified. Over time our API has become ladden with old methods, old package and class names, old extension points, ... The challenge is keeping the API fresh, clean and clear while not breaking existing code which, according to the assumption, cannot be changed.
The importance of API maintenance should not be underestimated. It is vital both for the smooth consumption of components as they evolve but for its effect on producer/consumer trust.
With that in mind, it may be interesting to challenge the assumption the consumer's code cannot change and instead assume that the consumer does not change the code -- allow the producer change it for them. This direction was discussed amongst a number of us at the OSGi World Congress a few weeks ago. There are several flavours but here is the basic idea.
- The producer of an API, for example, changes the name of a package/class/method from A to B
- the producer also creates an aspect definition that "co-opts" all consumers and modifies references to the old package/class/method to reference the new package/class/method.
- this can capture package, class and mehod changes
- there are corner cases involving reflection and OSGi service lookup etc that may be more challenging
Similarly, a registry munging mechanism would be required to update extension/extension point usage in the face of renamed or refactored plugins.
Is there any interest in looking at this problem (I'm thinking specifically from the aspect folks). Thisis a pretty mundane use of aspects but it would be hugely useful.
_______________________________________________ equinox-dev mailing list equinox-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/equinox-dev
Description: S/MIME Cryptographic Signature