Re: [equinox-dev] support for component API refactoring

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

Clearly I have not thought deeply about
this but superficially, the OSGi bundle markup gives you enough information
to figure out where exactly each referenced class will come from.  With
this info, you should be able to correctly apply the transformations without
accidents.  You would have to do an analysis to see that the set of
"new" classes does not overlap the set of existing classes but
that should be pretty straightforward.

As for BCEL and ASM, yes, you would
want some abstraction above this.  I wonder if there are any really
simple tools out there since the sort of transformations (at least initially)
envisioned here are very simple (e.g., add some constant pool entries and
change some constant pool references).

Jeff

Martin Lippert <lippert@xxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

11/24/2005 04:08 PM

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

Hi,

I am not sure whether BCEL or ASM are the only tools to do such kind of
client migration to evolved APIs. I definitely think that you would need
some kind of abstraction layer above those bytecode libraries to let API
producers define those "API migrators". This abstraction layer
could be 
a specialized API evolution DSL or a framework or something similar...

In addition to that: I think that the implementation of such a migrator
framework would need to do a lot of analysis of the client code in order
not to damage its implementation. For example: renaming a class would 
cause the migrator to adapt references to that class. What happens if a
class with that name already exists in the client? And I think there are
a lot of more difficult situations where a "stupid" modification
of the 
client code would break the implementation. Any thoughts on that?

-Martin



> 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
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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