Evolution of collective object behavior in presence of simultaneous client-specific views

Transcription

1 Hi Eddy This copy is for our eyes only! Evolution of collective object behavior in presence of simultaneous client-specific views Bo Nørregaard Jørgensen, Eddy Truyen The Maersk Mc-Kinney Moller Institute for Production Technology, University of Southern Denmark, Odense Campus, DK-5230 Odense M, Denmark. Computer Science Department, Katholieke Universiteit Leuven Celestijnenlaan 200A, B-3001 Leuven Belgium Abstract. In this paper we describe a novel extension of the Java programming language that allow non-invasive additive incremental refinement of collective objects behavior. 1 Introduction The need to support simultaneous client-specific views on a single shared system is becoming increasingly important. Some application domains in which this need is rising includes: [We want to support unanticipated non-intrusive customization and integration] We support non-intrusive client-specific evolution of object-oriented programs, for the purpose of customi zation and integration, using additive incremental refinement of object instances at runtime. As a consequence, each client of the system instance must be able to customize the system instance for use in its own context, without affecting the service behavior that is delivered to other clients. We call this problem system customization in the presence of simultaneous client-specific views. This research was supported in part by the A. P. Møller and Chastine Mc-Kinney Møller Foundation, The Danish National Centre for IT Research and

2 1.1 Motivation [This section contains different examples on existing technologies that motivates our approach] [All examples should focus on problems caused by the simultaneous use of the same abstraction, instantiated from different subtypes outside the control of the clients] [Can we use the hospital example here? Person/animal!] [Discuss the problems with existing approaches (Design patterns: Decorator, Role Object, Abstract Factory, Factory Method. Frameworks: specialization, integration) when in the context of system-wide customization/specialization.] [Frameworks and Design patterns based designs are used to support anticipated customization] Composition of OO frameworks! [Make a search for Framework composition + problems ] [The problem with designing reusable classes is that we have to anticipate all future use] [Retro fitting design patterns into the application by refactoring results in intrusive change of the code base] [What does it mean to wrap a class/interface in the context of evolution? Why is wrapping of classes and interfaces different?] [John Vlissides, Subject-Oriented Design, C++ Report, February 1998.] [Linda Seiter, Jens Palsberg, and Karl Lieberherr, Evolution of object behavior using context relations, IEEE Transactions on Software Engineering. 24(1):79-92, 1998.] [Challenges of dynamic object extensibility] In general, it is hard if not impossible to anticipate in advance all collaborations that an object will participate in during its lifetime. An object developed within one context will participate in collaborations with objects developed in other contexts. Some of those contexts may not even exist jet. Hence, dynamical object extensibility is required to adapt objects on the fly to fit specific roles when reused in new contexts. Customizing an object in the traditional manner, specialization through subclassing, is not a possibility here, because the same object may be involved in simultaneous interactions with clients from different contexts. Adapting an object statically by sub-classing to fit a specific role, required by a particular client, makes the type of the object dependent on the client that it interacts with. This is not a workable solution since it requires the object to have multiple types at the same time. A number of wrapper-based design patterns, such as, Decorator [2], Extension Object [3], and Role Object [4] describe different approaches that allow us to dynamically extend object functionality at the instance level. However, these approaches only facilitate extension of individual objects, not collections of collaborating objects. Single object extensibility is only sufficient for dealing with very simple types of customization. Extensions that have system-wide impact require whole collections of collaborating objects to be customized.

3 In [5], we presented an approach that can support system wide customization though the coordinated use of decorators and role objects. It is this coordinated approach to achieve object extensibility that has inspired the extension to the language that we propose in this paper. Major challenges follow from using a Decorator and Role Object inspired approach to achieve dynamic object extensibility. We have named these challenges accordantly to the problems that they address. The language extension that we propose provides a solution to these problems. Multiple references problem: To use an object, that has been extended, we have to access the object through the reference to the decorator or the role object that provide the extension. Consequently, we have to maintain a reference for each extension that we add to the object. Maintaining this indirection is tedious and will lead to severe scalability problems when considering customisation of entire collaborations between objects. A solution must provide a mechanism that allows us to access all extended forms of an object through the same logical reference. Extension consistency problem: In the Decorator and Role Object design patterns the clients of an object are responsible for selecting and adding extensions. This scatters the code for managing extensions across the whole collection of collaborating objects. Each time a new extension has to be introduced, it will require updates at multiple places in the code, which is tedious to do in a consistent manner. Furthermore this doesn t scale in the presence of ordering constraints between extensions (i.e. when one extension must be applied before another). To cope with these management problems a solution must specify the extension composition logic in one place, externally from the clients. The dispatch mechanism in the language s runtime must interprets this externally specified composition logic when dispatching an invocation. [Additional problems: It is not possible to evolve abstractions whose instantiation is under the control of the system subject to evolution. The factory design pattern provides some solution to this problem, but it requires that change can be anticipated.] The object schizophrenia problem:. 1.2 Design requirements From the above discussion we can distill a number of requirements for an extension mechanism. These requirements reflect the very basic properties of the evolutionary forces that the extension mechanism must be able to deal with. The order in which the requirements are listed has no significance. 1. Client-specific: Each client must be able to customize the core system to fit her specific needs. This implies that each client has a subjectivistic view on the core system.

4 2. Simultaneous clients: More clients must be able to use the same instance of the system simultaneously. 3. Non-invasive: Any extension of the system should not required changes to existing code. That is, evolution of collective object behavior is additive rather than invasive. 4. Unanticipated change: Evolution should not require preplanning, or the presence of hooks in the existing code. 5. Work with existing code: In order not to prohibit the evolution of existing legacy classes and class libraries developed by third parties, it is required that the extension mechanism does not introduce any additional restrictions on the definition and use of classes (e.g. coding conventions). 6. Compositional: More extensions can be applied simultaneously. 7. Refinement of collective behavior: Refine the behavior of multiple objects in a coordinated manner. 8. Run-time applicable: The evolution mechanism should operate at the object level. That is, object are considered black boxes whose functionality can be extended along their collaborations. 9. Modular: Modularization of behavioral refinements into extensions. Each additive incremental refinement is defines as an extension. 10. Incremental refinement: To do additive incremental refinement an extension must be allowed to extension an existing extension. That is, it must be possible to use the mechanisms to do a new additive incremental refinement of a previously created additive incremental refinement. If not each extension just becomes a dead end in the evolution tree of the core class. [It must be possible to apply the evolution mechanism to a previous created product created by applying the evolution mechanism] 1.3 Terminology To establish common ground for the following discussions we will here introduce the terminology that we use in the rest of the paper. We will use the term collaboration when we refer to a group of object interactions between several objects that share the collective responsibility of realizing a distinct aspect of a system s behavior. When discussing wrapper related issues we adapt the terminology of [7]. Hence, a wrapped object is called a wrappee. A wrapper and a wrappee together are referred to as an aggregate. The declared type of an object reference is referred to as static (compile -time) type. The type of the actually referenced object is called the object reference s dynamic (actual, run-time) type. Likewise, we also distinguish between the static (declared, compile-time) and the dynamic (actual, run-time) wrappee type. The static type of a wrapper corresponds to at least the static type of the wrappee and the dynamic type of a wrapper equals at least the dynamic type of the wrappee. When we talk about extension of objects we distinguish between subtypes and subclasses. A wrapper is a subtype of the wrappee but not a subclass of its class. Only inheritance results in both a subclass and a subtype relationship between a class and its superclass (assuming that the subclasses respects the behavior contract of the

5 superclass). Wrapping only results in a subtype relationship between the wrapper and wrappee. In our discussion of wrappers we will use the term signature extensively. Accordantly to [10] the signature of a method consists of the name of the method and the number and types of formal parameters to the method. We will say that two methods match each other if their signatures and return types are identical. In discussions of invocation scenarios, we use the notation C.m() to refer to the implementation of instance method m in class C and the notation I.m() to refer to the declared method m in interface I. In all other respects general Java terminology and syntax apply. 1.4 Organization of this paper The paper is organized as follows. In section 1 we motivated our approach. Section 2 positions our work in relation to previous work that addresses the same or similar problems. The conceptual model behind our approach is explained in section 3. In section 4 we show how our approach is realized in Java using language level wrappers. Section 5 lists examples on other problems that can be solved using our approach. Finally we conclude in section 6. 2 Relation to previous work [Describe previous work that related to the design requirements and explain what it fulfills and how it comes short!] [Consider to organizes the related work along some dimensions.] [This section is placed up front such that the description of related work can serve to introduce and position our work][after explaining the focus and main feature of the related work, we will emphases the differences/similarities to our work] [Mixin layers] [Smith, R.B., Ungar, D., "A Simple and Unifying Approach to Subjective Objects," Theory and Practice of Object Systems, Vol. 2(3), ] [AspectJ] [Linda Seiter, Jens Palsberg, and Karl Lieberherr, Evolution of object behavior using context relations, IEEE Transactions on Software Engineering. 24(1):79-92, 1998.] [Yannis Smaragdakis and Don Batory, Implementing Layered Designs with Mixin Layers, 12th European Conference on Object-Oriented Programming (ECOOP 98). In Lecture Notes in Computer Science (Springer) 1445.] [Wrappers to the rescue] [Generic Wrappers] suffers from the extension consistency problem. Generic wrappers were introduced in the Java programming language in [7]. Generic wrappers are special class that wrap instances of a given reference type (i.e. interface or class) or of a subtype thereof.

6 3 Conceptual overview of our approach Central to the way that we approach the evolution of collective object behavior in the presence of simultaneous client-specific views are the concepts of layering and wrappers. A client-specific view defines a perspective on the entire system from the context of the client. Conceptually these individual client-specific views can be considered points of view through different layers on an underlying group of objects. These underlying objects offer a generic set of behaviors and thereto related attributes that together define the core system. Each client-specific view may just involve a single layer or it may require the participation of multiple layers. Consequently, the same underlying group of objects has different manifestations from within different client-specific views. Layer3 Core Layer 1 Layer 2 Figure 1 Simultaneous client-specific views Realization of a client-specific view as a collection of several layers that overlay a group of objects makes intuitively a lot of sense since any kind of evolution of a particular task in a system involves all the objects that are responsible for implementing that task. That is, the code that controls the flow of invocations that realize the task is scattered across those objects. Hence any refinement of such a task will crosscut the code of all of those objects. Consequently, a client-specific view crosscuts the class hierarchy of the core system, influences the behavior of multiple objects. Layers hold the responsibility for organizing the adjustments, in the form of wrappers, which have to be applied to each object within the group of objects that realize a particular collective behavior. Layers thereby define semantic units that refine the functionality of the core system. A particular client-specific view on a system can therefore be seen as a specific combination of layers. Wrappers define the individual adjustments for each object that has to be modified before it can participate in a client-specific view. Each wrapper modifies exactly one object. Taken together the wrappers within a layer collectively define a behavioral extension of the class hierarchies in the core system. On the request of clients the core

7 system can be integrated with one or more extensions to form a particular clientspecific view on the system. It is this combination of layers of wrappers that create the different client-specific views on the core system. Object A Object B Object C Object D System configured as requested by client one Client one Layer 3 System configured as requested by client two Client two Layer 1 Layer 2 Figure 2 Using wrappers to create client-specific configurations Stacking layers on top of one another allows the system s behavior to evolve in an incremental fashion. The stacking of layers can either be done by combining independent layers or by relating layers by a refinement relationship. One layer is said to be a refinement of another layer, if its wrappers refine the behavior of the wrappers contained in the overlaid layer. This stacking of layers on top of one another arranges layers into a refinement hierarchy that is considered to be orthogonal to the normal object inheritance hierarchy. An extension mechanism that is based on wrappers is both intuitive and easily to comprehend for programmers since it, in many ways, behaves similarly to class-based inheritance, just at the object level. However, our approach goes further since layering of wrappers introduces a horizontal relationship between the refinements of individual objects. This horizontal relationship ensures consistence for behavioral refinements. 4 Introducing layered wrappers to Java In this section we present our approach as a strict extension to Java; that is, existing Java applications need not to be modified. For the sake of simplicity of the code examples in the following sections we will omit return types when they have no significance for the example. 4.1 Defining wrappers In this section we give a very basic definition of wrappers. We will address more intrigue issues in the following sections.

8 For example, the following declaration states that each instances of SomeWrapper wraps an instance of SomeAbstraction. wrapper SomeWrapper wraps SomeAbstraction { The example introduces two new keywords to the Java language for defining wrappers. The keyword wraps is used to associate the wrapper with the wrappee and the keyword wrapper is introduced to distinguish the definition of a wrapper from the definition of a normal class. In later sections we will discuss situations where we need the keyword wrapper to distinguish the definition of wrappers from the definition of classes. The definition of a wrapper does have a lot in common with the definition of normal class, but as we will see they also differ in various ways. Similarly to the extends clause for class inheritance the wraps clause declares the wrapper to be a subtype of not only the static wrappee type but also the actual wrappee type. However, the actual wrappee type is not known until runtime. Since a wrapper is a subtype of the dynamic type of the wrappee, the aggregate can be used anywhere where the wrappee can be used. When a wrapper wraps a class the actual wrappee type corresponds to the static wrappee type or any subtype thereof. When a wrapper wraps an interface the actual wrappee type corresponds to the type of the class that implements the interface. Figure 3 shows the definition of the wrapper B as a subtype of the class A. wrapper X wraps A { Figure 3 Syntax for defining a wrapper. Accordingly to the genericity requirement of [7], stating that wrappers must be applicable to any subtype of the static wrappee type, it is required that a wrapper must conform to the following three rules. 1) If the wrapper is wrapping an interface, the wrapper must be applicable to all classes that implements that interface. 2) If the wrapper is wrapping an abstract class, the wrapper must be applicable to instances of all subclasses thereof. 3) Similar, if the wrapper is wrapping a non-final class the wrapper must be applicable to all subclasses thereof. In accordance with these rules we allow wrappers to be defined for both classes and interfaces. However, for certain usage situations we do place some restrictions on the their use. For instance, when a wrapper wraps an interface it is only allowed to override the methods declared by the interface, the wrapper is not allowed to add new methods. Wrappers cannot be used to evolve the type of an interface, they are merely thought of as a behavioral refinement mechanism for classes implementing the interface. On the contrary, wrappers that wrap classes are allowed to define additional methods. This is allowed because wrapping of classes constitute the foundation for extending and customizing the interactions within the system (i.e. interaction refinement [ref]).

9 Abstract classes can be wrapped. However, an abstract class cannot be instantiated so a wrapper that wraps an abstract class is intended for use with instances of its potential subclasses. Wrappers are not allowed to wrap final classes. Because a class is deliberately made final to prevent it from being subclassed. Allowing wrappers for final classes would interfere with such design decisions. Similarly, wrappers are not allowed to override methods that are declared final by the static type of the wrappee. Since we intend wrappers to be an extension mechanism for late customization we have to consider accessibility issues with respect to packages. For instance, using inheritance to extend classes or interfaces, which belong to a different package, requires that they are accessible outside the package, i.e. declared public. When we use wrapping as the extension mechanism we have similar accessibility requirements. Wrappers are only allowed to wrap classes and interfaces that are declared public. Hence it is only the so-called top-level classes and interfaces that can be subject to wrapping. All classes having package scope are merely considered to be implementation details of the package. Contrary to [7], we do not allow a wrapper to wrap another wrapper. However, we do allow a wrapper to specialize another wrapper. Wrapper specialization will be discussed further in section Overriding of instance methods In class-based inheritance certain rules must be followed to guarantee type and semantic soundness when overriding instance methods in subclasses. For example to guarantee type soundness in Java, the overridden method is not allowed to be final, the return type of the overriding method has to be the same as that of the overridden method, the overriding method must be at least as accessible, the overriding method may not allow additional types of exceptions to be thrown, and an instance method may not override a class method. To also guarantee semantic soundness, the overriding method must be a behavioral refinement of the overridden method [8]. Analogous to these rules for class-based inheritance we can formulate rules for overriding instance methods in a wrapper based approach. We will only allowed a wrapper to override a method if it is accessible outside its class. Public methods are accessible to all potential clients, protected methods are only accessible from within the class itself and it s subclasses, private methods are only accessible within the class itself. Due to the accessibility restrictions of protected and private methods, wrappers are only allowed to override public methods. Public methods that are not overridden by the wrapper are transparently accessible through the wrapper. In Figure 4 the method m in class A is overridden by the method m in the wrapper X. class A { wrapper X wraps A {

10 public m() { Figure 4 Overriding example public m() { An invocation of m on an aggregate of wrapper X and class A through an object reference of at least type A or X results in the execution of X.m(). In section we will see how the method A.m() can be invoked from within X.m() using an invocation expression similar to the use of super in subclass relations. Differentiating on accessibility means that any method defined by a wrapper that coincidentally happens to have the same signature and return type as a protected or private method of the wrappee or any subtype thereof, are completely unrelated the wrapper method does not override the method in the wrappee. This corresponds with the overriding rules for classes and subclasses in Java. If the method in the superclass is inaccessible to the subclass the method defined by the subclass does not override the method in the superclass. It is not without problems to allow a wrapper to define a method with a signature and return type that is identical to a protected or a private method in the wrappee. For instance, when an aggregate is constructed from a wrapper and wrappee that have methods with identical signatures and return types we have to consider how the process of method lookup and dispatch is working. Assume we have the class and wrapper definitions in Figure 5. class A { protected void m() { wrapper X wraps A { public void m() { Figure 5 Unrelated methods having identical signatures and return types The question is now when will an invocation of m result in the execution of A.m() and when will it result in the execution of X.m()? The answer can be found by inspecting the relationship between the static and dynamic type of a object refernce referencing an aggregate of the wrapper X and the class A. Assume that the object reference o with the static type A is referencing an aggregate of the wrapper X and the class A. Two different cases have to be considered for the invocation of m. An invocation of m made from within the class itself or from within any subclass thereof through an object reference that is of least the same type as the class that is, of the class s type or one of its subtypes results in the execution of the method A.m(). If the invocation is made from within an unrelated class the method X.m() will be executed. The choice of which method to execute is based on the method s accessibility and locality of definition with respect to the caller.

11 Let us now change the accessibility of the method m in class A to private. How does this affect the situation? Again we have to consider two different cases for the invocation of m. An invocation of m from within the class A through an object reference that is of the same type as the class results in the execution of A.m(). Any other invocation of m results in the execution of X.m(). The situation changes for invocation of m from within the class A or any subclass thereof if the static type of o is changed to X. Now all invocations of m results in the execution of X.m(). In Java a protected method can be promoted to public by subclassing. Figure 6 exemplifies this situation. class A { protected m() { wrapper X wraps A { public m() { class B extends A { public m() { Figure 6 Promotion of method accessibility This case is not in any way different from the previous cases, since the method m was not public accessible in the class A. An invocation of m on an aggregate of wrapper X and class B made from within the class A or from within any subclass thereof (e.g. class B) through an object reference that is of least type A will result in the execution of the method B.m(). If the invocation is made from within an unrelated class the method X.m() will be executed. When wrapping and inheritance are simultaneously used to evolve a class, we have a similar problem. It is possible that the wrapper and the subclass of the wrappee define methods with identical signatures, return types and accessibility. Again the aggregate will contain two methods with identical signature and return type. Which method should be invoked when? The method defined by the wrapper or the method defined by the subclass? Figure 7 exemplifies this situation with the method n. class A { public m() { class B extends A { public n() { wrapper X wraps A { public m() { public n() { Figure 7 Matching methods caused by subclassing

12 Clearly the method X.n() can not override the method B.n() since n was not define by A. That is, a wrapper cannot override any method within a subclass that was not present in the class that it wraps. To answer the question of when an invocation of n will result in the execution of B.n() and when will it result in the execution of X.n()we once again investigating the relationship between the static and dynamic type of an object reference o referencing an aggregate of the wrapper X and the class B. Now let the object reference o reference an aggregate of wrapper X and class B. Three different cases have to be considered for the invocation of n. That is, when the static type of o is respectively A, X, and B. If the static type of o is A the method n is not visible thus o has to be cast before n can be invoked. The method X.n()is execute by the cast ((X)a).n() and the cast ((B)a).n() results in the execution of the method B.n(). When the static type of o is X the invocation of n results in the execution of X.n(). Similarly the method B.n()is executed when the static type of o is B. It can happen that a method overridden by a wrapper will eventually be declare final by a subclass of the wrappee. In this case the overriding final method is still wrapped by the wrapper. The only implication of making the method final is that no new subclass will be allowed to override the method. If a wrapper incidentally defines a method with the same signature and return type as a public static method defined in the static type of the wrappee or any of it subclasses it is not considered an error. The process of method lookup and dispatch works in a similar fashion as described in the previously discussed cases. To summaries, we made the following choice for method lookup and dispatch when an aggregate contains multiple unrelated methods with identical signatures and return types. Invocations made through an object reference that is of the static wrapper type will result in execution of the wrapper implementation. And in case an invocation occur through an object reference that is of the static wrappee type or any subclass thereof, the wrappee implementation will be invoked. The rational for this choice is that a client who references the aggregate through an object reference of the static wrapper type expects the method to behave as defined by the wrapper. Similarly, a client who references the aggregate through an object reference of the static wrappee type expects the method to behave as defined by the static wrappee type or any subclass thereof Assignment and casting Assume that we have two aggregates consisting of the wrapper X and respectively the class A and the class B. We will refer to the former aggregate as XA and the later as XB. Both aggregates can be assigned to an object reference o that either has the type A or the type X. The aggregate XB can now be assigned to an object reference p of type B by type casting o (i.e. p = (B)o). Whereas trying to assign the aggregate XA to p by a similar type casting would lead to a runtime class cast exception.

13 4.1.3 Referencing the wrappee Within constructors and instance methods of a wrapper, the keyword inner references the wrappee. It can be thought of and treated as an implicitly declared and initialized final instance field. Hence, similar to the way subclasses use the keyword super to call overridden method of their superclass, the keyword inner can be used by wrappers to call overridden methods of the wrappee. The keyword inner defines the reference to the wrappee within the scope of the wrapper. The wrapper can conceal the behavior of the wrappee by not forwarding an invocation to inner. Optionally it can redirect an invocation by invoking another method on the wrappee. The shorthand notation for referencing the overridden method is shown in Figure 8. This will forward the invocation to the overridden method with the actual parameters of the overriding method. If the overriding method modifies the actual parameters, we must explicitly invoke the overridden method with the modified parameters. wrapper X wraps A { public m() { inner; // shorthand notation for inner.m() Figure 8 Referencing the wrappee Contrary to [7], we do not support an access modifier between the keyword wraps and the static wrappee type for controlling whether clients have direct access to the wrappee. In our approach clients are not supposed to tangle with the wrappee once it has been wrapped. When a wrapper wraps an interface it is oblige to call the wrapped methods of the wrappee through the inner reference. [Is this requirement in accordance with the idea of wrapping interface in the context of evolution?] If it does not forward the call, it results in a compiler error. Wrappers are not intended to be an implementation mechanism for interfaces. When a wrapper wraps a class, any additional method that is added to the static type of the wrappee is not allowed to refer to inner. If this were allowed it would result in some kind of abstract wrappers. [New formulation required!] Figure 3 shows the situation where a public method m of the class A is both overridden by the wrapper X and the subclass B. An external invocation of m on an aggregate consisting of an instance of the wrapper X and an instance of the subclasses B results in the method X.m() being invoked first and then the method B.m() through the use of the inner reference. The method A.m() will only be executed if it is called through super from within the method B.m(). class A { wrapper X wraps A {

14 public m() { class B extends A { public m() { ;super.m(); public m() { inner; Figure 9 Invoking overridden methods in the superclass using inner and super In section 4.4 we will return to the meaning of the keyword inner in the presence of conjunctive wrapping. Conjunctive wrapping refers to the situation where multiple wrappers are placed around each other. In our approach conjunctive wrapping is a result of wrapper specialization. 4.2 Grouping wrappers into extensions The process of extending an existing object system will typically require the creation of multiple wrappers. Taken together these wrappers form a collection that constitutes a well-defined system extension. We have chosen to organize such collections of wrappers in separate packages, so-called extension packages, in order to keep the definition of wrappers strictly separated from the definition of the classes and interfaces that they wrap. This implies that wrappers are always defined within another package than the classes and interfaces that they wrap. To create this separation we extended the notion of packages in Java with the modifier extension. Any package that is tagged with the modifier extension defines an extension. Wrappers can only be defined within packages tagged with the extension modifier. Only classes and interfaces that are visible outside their packages can be subject to wrapping by wrappers defined within an extension package. Within each extension package there can only be one wrapper per interface/class. Wrappers are implicitly declared public; that is, all wrappers within an extension package are visible from the outside. An extension package may contain classes and interfaces that serve in the construction of the wrapper. These classes and interfaces serve as utility abstractions for the wrappers. Utility abstraction must have package scope. Hence, they are only visible within the scope of the package. Figure 10 shows the definition of an extension package containing one wrapper and its support class. extension package dk.sdu.mip wrapper X wraps A { U u; class U { // Utility class Figure 10 Syntax for defining an extension package In the next section we will see how the naming of extension packages serve to coordinate the deployment of wrappers.

15 4.3 Activating extensions Any extension will typically crosscut the whole application by requiring wrappers to be applied at various places within the code. This means that the use of wrappers must be coordinated to ensure that an extension is consistently deployed. Furthermore an extension must be imposed on the target application in a non-invasive and transparent manner (i.e. without the need for modifying existing source code). In response to these requirements we chose not to allow programmers to directly create individual wrapper instances and apply them to objects. Instead we chose an approach in which wrapping is done by the language runtime on demand. That is, the language runtime is responsible of performing and coordinating the wrapping of application objects with wrappers from an arbitrary number of extensions. To perform this wrapping the language runtime needs to know from what point on it must start to wrap application objects (i.e. activate an extension), and it needs a mechanism to propagate this information along subsequent object interactions in order to correctly wrap all objects that participate in the collaboration. Information about active extensions can be propagated by including an invocation context with every invocation. To inform the language runtime about when to activate an extension, we extended the cast mechanism of the Java language to support constructive downcasting. In the context of this paper constructive downcasting refers to the dynamic extension of an object by changing the type of the object reference that references it into the type of a wrapper belonging to the desired extension. We call this cast constructive because the referenced object dynamically becomes a subtype of its current type when it is accessed through the cast object reference. A wrapper can only be used to change the type of an object reference into a subtype if the wrapper wraps the static type of the referenced object. Subtyping the object reference further, by another constructive downcast, requires that the second wrapper extends the first. This issue is discuss further in section 4.4. We will now explain how this semantics extension of the language s cast mechanism allows us to superimpose an arbitrary extension on an existing group of collaborating objects through any object reference referencing an object within that group. Figure 11 shows how the object reference a is temporally downcast to the subtype X as part of using it in an invocation expression. The object reference a will only have the type X for the duration of the execution of the method X.m(). When the method X.m() returns the type of a is restored to A. A a = new A(); ((dk.sdu.mip.x)a).m(); // executes X.m() a.m(); // executes A.m() Figure 11 Temporally downcasting From the point of the invocation expression ((dk.sdu.mip.x)a).m() and beyond the language runtime will dynamically apply the wrappers defined within the extension package dk.sdu.mip to all objects encountered along the invocation flow whose types are wrapped by those wrapper. In Figure 2 the wrappers defined within

16 the extension that represents layer 3 are dynamically wrapped around the objects A, B and C. When the wrappee is an interface the wrapper is applied to instances of classes that implement the interface. If the wrappee is a class the wrapper will be applied to all instances of that class. Multiple extensions can be superimposed by applying constructive downcasting recursively. For instance the cast expression ((be.ac.kuleuven.cs) dk.sdu.mip.x) will activate both extensions. This is illustrated in Figure 2 from the point of view of client two. Prohibiting programmers from directly creating individual wrapper instances eliminates a number of commonly known problems. For instance, we do not have to consider how to replace object references at runtime. Nor do we have to address such issues as whether it should be allowed to replace the wrappee within an aggregate. Since wrappers cannot be instantiated by the programmer, they cannot have parameterized constructors. By disallowing constructors with arguments we avoid the instantiation problem when multiple clients use the same wrapper. [In which section should we introduce constructors for wrapper?] An important property of constructive downcasting is that class cast exceptions cannot occur at runtime, because type casting transforms the referenced object into an object of the casting type when accessed through the cast object reference. The compiler can easily check that the casting type indeed does wrap the static type of the object reference Implementing client-specific customization In this section we shall see how extensions can be used to implement client-specific customization of a shared server application. Lets assume a situation where two clients with different customization requirements share a common server. Using wrappers we can now implement the customization for the clients within two different extension packages. package dk.sdu.mip.core class A {void m() { extension package dk.sdu.mip.one wrapper X wraps A {void m(){ ;inner; extension package dk.sdu.mip.two wrapper Y wraps A {void m(){ ;inner; Figure 13 Extension packages containing different customizations We now have the following code within client one Server s = (Server)Naming.lookup( MyServer );

17 ((dk.sdu.mip.one.x)s).service(); and within client two Server s = (Server)Naming.lookup( MyServer ); ((dk.sdu.mip.two.y)s).service(); When invoking m on the object reference s from within the code of client one, the invocation will first pass through an instances of the wrapper X before it is dispatched onto the instance of A. In the case where the invocation of m occur form within the code of client two the invocation will first go through an instance of the wrapper Y Activation extension from within subclasses Assume that we have the two classes as defined in Figure 14. class E { public void n(){/* do some job */; class A { E e = new E(); public void m() {e.n(); Figure 14 Now we want the logger wrapper X defined in Figure 15 to be activated when A.m() calls the method E.n(). extension package dk.sdu.mip wrapper X wraps E { void n(){ entrylog(); inner; exitlog(); void entrylog (){; void exitlog (){; Figure 15

18 However this has to be done in a non-invasive manner so we introduce the subclass B. class B extends A { void m() { (dk.sdu.mip)super.m(); Figure 16 Since it gives no meaning to cast the super reference into the subtype of the required wrapper we had to come up with another approach. We have chosen to activate the wrapper X for instances of the class E by prefixing the super reference in the class B with the name of the extension package that contains the definition of the wrapper X. An invocation of the method m on an instance of B will result in the execution sequence B.m(), A.m(), X.n(), and finally E.n(). 4.4 Extending wrappers Similar to classes, wrappers can form specialization hierarchies by extending the behavior of existing wrappers. wrapper Y extends X { public void m() { // inner; // Figure 17 Extending a wrapper In the context of a wrapper definition the keyword extends means that the wrapper Y refines the behavior of the wrapper X. The wrapper Y wraps the same type as the wrapper X. At runtime the two wrappers X and Y will conjunctively wrap the wrappee. The wrapper X will be the innermost wrapper and the wrapper Y will be the outermost wrapper. Here we need the keyword wrapper to distingue the specialization of wrappers from the specialization of classes. However, we could deduce this information by traversing the chain of extends clauses, because this chain will always end with a wrapper that wraps a class or an interface. Using the keyword wrapper increases the readability of the code. When a wrapper extends other wrapper, the use of the keyword inner within the outermost wrapper references the innermost wrapper. The outermost wrapper can conceal the behavior of the innermost wrapper and the wrappee by not forwarding a call to inner. If the outermost wrapper wants to bypass the innermost wrapper and directly invoke the wrappee, it must use an invocation statement of the form ((A)inner).m() (Assuming that the static type

19 of the wrappee is A and that the method m is overridden). This is similar to the way a subclass can invoke a method higher up in the inheritance hierarchy, see in [10]. Albeit, in general this is not considered good practice since wrapper extensibility is about incremental refinement of the wrappee, the chain of wrappers should therefore be respected. The specializing wrapper is allowed to add methods to the specialized wrapper this means that the specializing wrapper becomes a subtype of the specialized wrapper. These additional methods are accessible through an object reference that is at least of the same type as the specializing wrapper. Wrappers can only extend wrappers that are defined in other extension packages. A wrapper is not allowed to extend a wrapper that is defined within the same extension package as itself. If we allowed a wrapper to extend a wrapper from the same extension package it would result in the existence of two wrappers for the same wrappee class within the same extension package, which we do not allow accordingly to section 4.2. Wrapper specialization relates extensions with each other. When a wrapper that extends a wrapper defined in another extension is used in a cast expression the wrappers of the two extensions are combined from that point on. ((dk.sdu.mip.y)a).m(); // cast activating extension Y and X Figure 18 Activation of multiple extensions In Figure 18, an invocation of m on the object reference a results in the execution sequence Y.m(), X.m(), and finally A.m(). Extensions that are related due to wrapper specialization is said to be conjunctive and extensions in which no wrappers are related by an extends clause are said to be disjunctive Client-specific customization with shared state If two clients, each requiring their own specific customization, have some state in common we can implement this using three extension packages. The common state and behavior is placed in the root extension package and the specific customized behaviors are placed in two derived adjacent extension packages. To support state a wrapper must be allowed to have member variables. package dk.sdu.mip.core class A {void m() { extension package dk.sdu.mip.one wrapper X wraps A { int number; void int m(){ ;inner; return number++;

20 extension package dk.sdu.mip.two wrapper Y extends X extension package dk.sdu.mip.three wrapper Z extends X Figure 19 Sharing of state between extensions using wrapper specialization We now have the following code within client one A s = (Server)Naming.lookup( MyServer ); ((dk.sdu.mip.two.y)s.)service(); and within client two A s = (Server)Naming.lookup( MyServer ); ((dk.sdu.mip.three.z)s).service(); When invoking m on the object reference s from within the code of client one, the invocation will first pass through an instances of the wrapper Y, then go through an instance of the wrapper X before it is finally dispatched onto the instance of A. In the case of invoking m form within the code of client two the invocation will first go through an instance of the wrapper Z and then through an instance of X. 4.5 Wrappers implementing interfaces Above we discuss the case there a wrapper wraps an interface, now we will discuss the case where a wrapper implements an interface. A wrapper can implement one or more interfaces as part of wrapping a class or another interface. The type of the wrapper will be equal to the sum of the interfaces that it implements and the dynamic type of the wrappee. To understand the implications of allowing wrappers to implement interfaces we have to investigate both the static as well as the dynamic situation. In the static situation we have to consider two distinct cases. In the first case the wrapper implements an interface and wraps a class. Figure 20 illustrates this first case. wrapper SomeWrapper

21 implements SomeInterface wraps SomeClass { Figure 20 Wrapper implementing an interface Figure 21 shows the situation where the interface I declares a method n for which no matching method definition is present in the static type of the wrappee (i.e. in the class A), hence the wrapper X must implement the method n. class A { public void m() { interface I { public void n() { wrapper X implements I wraps A { public void m() { ;inner; public void n() { Figure 21 Next consider Figure 22 where the interface declares a method with a signature and return type that match a method implemented by the wrapped class. There are two subcases, exemplified by Figure 23 and Figure 24: class A { public void m() { interface I { public void m() { Figure 22 In Figure 23 the wrapper defines a method that match the signature and return type of the method declared in the interface and the method defined in the wrapped class. the method defined in the wrapper is considered to implement the method declared in the interface and override the method defined in the wrapped class. wrapper X implements I wraps A { public void m() { ;inner; // overrides m in A Figure 23 In Figure 24 the wrapper does not define a method with matching signature and return type; the method defined in the wrapped class is considered to implement the method declared in the interface. That is, an invocation of m on an aggregate consisting of wrapper X and class A through an object reference of type I will result in the execution of A.m(). wrapper X implements I wraps A {

22 // executes A.m() Figure 24 In the second case the wrapper implements an interface and wraps an interface. Figure 25 illustrates this second case. wrapper SomeWrapper implements SomeInterface wraps SomeInterface { Figure 25 If the implemented interface declares a method for which no matching method declaration is present in the wrapped interface, the wrapper must provide the implementation of that method. Figure 26 shows this situation for the method I.m(). interface I { public void m() { interface J { public void n() { wrapper X implements I wraps J { public void m() { public void n() { ;inner; Figure 26 If the implemented interface has a method that match a method in the wrapped interface (Figure 27), then there are two possible subcases (Figure 28 and Figure 29): interface I { public void m() { interface J { public void m() { Figure 27 In Figure 28 the wrapper defines a method that match the signature and return type of the method declared in the implemented interface and the method declared in the wrapped interface; this method is considered to implement the method declared in the implemented interface and override the method declared in the wrapped interface. wrapper X implements I wraps J { public void m() { ;inner; Figure 28

23 In Figure 29 the wrapper does not define a method with matching signature and return type. This means that any method defined in a class that implements the wrapped interface is considered to implement the method declared in the implemented interface. wrapper X implements I wraps J { // executes m in the class that implements J Figure 29 In the dynamic situation we have to consider the possibility that a class, which extends the wrapped class, might define a method that matches a method declared in the implemented interface, Figure 30. Similarly, it is possible that an interface, which extends the wrapped interface, might declare a method that matches a method declared in the implemented interface, Figure 31. In Figure 30 an invocation of the method n on an aggregate consisting of the wrapper X and the class B through an object reference of type A or I will result in the execution of the method X.n(). class A { public void m() { class B extends A { public void n() { interface I { public void n() { wrapper X implements I wraps A { public void m() { ;inner; public void n() { //hides Figure 30 In Figure 31 an invocation of the method m on an aggregate consisting of the wrapper X and a class which implements the interface K will result in the execution of the method X.m(). This is analogue to the way Java resolves the implementing method for abstract methods, se in [10]. interface I { public void m() { interface J { public void n() { wrapper X implements I wraps J { public void m() { //hides public void n() { ;inner; interface K extends J { public void m() {