[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [equinox-dev] support for component API refactoring
|
Hmm, we don't really want to support
the old version of the API. It leads to all manner of surplus code,
wrappering and strange coding practices. Ideally developers would
be able to just move on and leave behind some aspects (whatever we want
to call them) that would dynamically modify old syntax/references to new.
Obviously this simplistic approach would only capture some of the
cases. Even so, it would be interesting as those cases are pretty
common.
So is the only way to do this with tools
such as BCEL or ASM?
Jeff
Matthew Webster <matthew_webster@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx
11/21/2005 04:03 AM
Please respond to
Equinox development mailing list |
|
To
| Equinox development mailing
list <equinox-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
| Re: [equinox-dev] support
for component API refactoring |
|
Jeff,
I think Martin is right. While it is possible to (mis)use around advice
to coerce a method call from one signature (type, name or parameters) to
another you cannot change declared field types whether members or local.
Are there fundamental problems with the old-fashioned way of dealing with
API evolution i.e. support the old version of an API but only load it when
needed?
Matthew Webster
AOSD Project
Java Technology Centre, MP146
IBM Hursley Park, Winchester, SO21 2JN, England
Telephone: +44 196 2816139 (external) 246139 (internal)
Email: Matthew Webster/UK/IBM @ IBMGB, matthew_webster@xxxxxxxxxx
http://w3.hursley.ibm.com/~websterm/
Please respond to Equinox
development mailing list <equinox-dev@xxxxxxxxxxx>
Sent by:
equinox-dev-bounces@xxxxxxxxxxx
To:
Equinox development mailing
list <equinox-dev@xxxxxxxxxxx>
cc: Stefan
Roock <stefan@xxxxxxxxxxxxxx>
Subject: Re:
[equinox-dev] support for component API refactoring
Hi Jeff,
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...
-Martin
Jeff McAffer wrote:
> 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.
>
> Jeff
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
Attachment:
smime.p7s
Description: Binary data