\newcommand\kindrelated[1]{\ssect{#1}} \newcommand\instrelated[1]{\textbf{#1}} %\kindrelated{Concern and Aspect Oriented Systems} \johan{Is this comparison redundant? put it somewhere's else -- like end of aj/hj solutions?} %%***************************************************************** %% HyperJ \instrelated{\hj} and the work on Multi-dimensional Separation of Concerns \Cite{MDSOC} generalizes the ideas behind Subject-Oriented Programming \Cite{HarOss:93:SOP,HarrEtAl:95:SOCR} by moving to finer grained units of combination. A HyperSlice is a named set of classes containing sets of methods and fields, and can be added to new classes in a very similar way to collaborations. Our comparison found that HyperSlices fare well in capturing and composing reusable concerns in a type-safe manner, but lack sufficient expressiveness to conveniently perform behavioral crosscutting. While {\hj}'s HyperModule definitions make it explicit \emph{how} concerns are composed, alleviating the ``come-from'' nature of aspects, the seeming lack of encapsulation makes understanding \emph{what} concerns are composed impossible without performing a full trace of the concern composition history to gather up the accumulated interfaces for the slices, and opening up slice composition to inadvertent name capture \Cite{meyer:book-88}. {\hj} additionally offers several features that did not come up in the example. Post-hoc remodularization allows a HyperSlice to be teased out of a set of classes (possibly generated by composing slices, or by compilation of {\tt .java} files) and used separately. {\hj} also provides several dimensions of composition, of which our examples only used the feature dimension. %%***************************************************************** % AspectJ \RevC{Page 9- first paragraph on AspectJ: the reference to "[asp 1999]" does not seem to be an accurate pointer to anything listed in the references } \instrelated{\aj} from Xerox PARC~\Cite{Lopes:1998:RDA,Kiczales:2001:OAJ} resulted from the initiative to factor out commonalities in several domain specific aspect languages. Crista Lopes' thesis~\Cite{crista:thesis} investigated two of those languages in detail: COOL \Cite{sync-patts:ecoop94} for specifying the synchronization aspects, and RIDL~\Cite{Lopes95b} for specifying data transfer aspects. By integrating aspect features tightly into the language, {\aj} foregoes the semantic and syntactic overhead of module systems, but also the benefits of encapsulation and separate compilation. While this gives rise to very natural specification of aspectual behavior, it comes at a cost of program comprehension, as the lack of encapsulation boundaries for advice forces the programmer to read the whole program to determine whether a join-point has advice. Analogously, there is no way to protect a join-point against being advised. These deficiencies have been addressed with tool support, rather than language features, aiding the programmer in identifying advice attached to methods. % It is unclear whether this is a contribution towards the science of language design, a contribution to Human-Computer Interaction, or a symptomatic fix. %%Johan: someone commented out that line? nar nar! Chickens! \revC{ On page 9, first paragraph on AspectJ: there appears to be a contradiction in this paragraph. \HIDE{ At one point, you state that program comprehension suffers because it "forces the programmer to read the whole program to determine whether a join-point has advice." Then, just two sentences later, you state "...plugins..assisting in code comprehension by identifying advised join-points." I really do not buy into the argument that comprehension suffers, at least in this case. I think that the tool support provided by the AspectJ teams goes a long way toward improving comprehension and I feel that this paragraph does not bring that to light (and in fact, this paragraph implies the opposite). } ... Johan: are the two last senences of above paragraph too offensive? } {\aj} aspects are reusable by programming abstract aspects against interfaces that are attached at a later time to the host program. Aspectual advice achieves surprisingly good reuse, both by mentioning only the types necessary in a point-cut signature, and also by the somewhat unorthodox genericity mechanisms of around methods (see \Ref{Section}{unorthodoxgenericity}), which appear to work very well in practice. \RevC{Page 10- very first line on top of page: there are a few places throughout the text where it appears that there are spaces before a comma (here, "around methods ,") Please check for other occurrences (there is also a similar thing in the first paragraph on page 10). johan: came like this :''\twelve{}{},'' The macro has been removed in most places. } Unfortunately, programming abstract aspects against interfaces suffers from low levels of type safety: generating casts in programmer-invisible code that can fail, and forcing multiple uses of an aspect to share types (recall \Ref{Section}{aj-invasivetypes}), which opens up the program to further casting errors. The use of interfaces interferes with reuse, as it restricts expected members to be methods, and requires name equivalence between expected and provided methods. Hannemann and Kiczales \Cite{HanKic:02:DPIAJ} show how this style of programming can be used to implement standard design patterns. It identifies four properties by which such an implemented pattern can be considered modularized. The properties focus on textual invasiveness and locality of the design, rather than properties such as encapsulation and composition identified in this paper. The organization removes confusion about which instance of a pattern source code belongs to, but whether objects playing pattern roles can be confused between pattern instances is not discussed. %\toolong{ %\instrelated{{\longAC}s}'s %explicit use of reified aspectual methods may impose a performance penalty, and requiring the user to capture and return a reified result introduces some awkwardness into aspectual methods. %However, we gain a very clear insight into the exact behavior of our program, in addition to strong type-safety guarantees and flexible reuse, and special cases for ``before'' and ``after'' methods would obviate the need for capturing return values for such advice. % %Encapsulation allows us to also understand the program in a compositional manner: by looking only at one attachment specification, we can make accurate predictions about how the mentioned parts of the program can communicate with each other, without requiring tool support or understanding the whole program. %} %% ************************************************************************** %% ************************************************************************** \subsection{Invasiveness}\label{Section:aj-invasivetypes} Ernst \Cite{Ernst:2000:Invasive} defines \emph{invasiveness} as the ability to tell, from within a module, how it is being extended and used. An extension can be both type and behavior invasive. Using Java interfaces can result in both kinds of invasive extensions. The use of interfaces and ``implements'' to model roles affects the static correctness of a program, as well as its dynamic type safety. The key property of a Java interface is to assert that a class satisfies the properties necessary for the type defined by the interface. Thus, a class must provide implementations of all methods in an implemented interface, or be annotated as \keywrd{abstract}---in which case its subclasses inherit the burden of providing implementations. An aspect can render previously correct base classes incorrect by introducing an ``implements'' relationship between a base class and an interface: unless the class has the required methods, it must be marked abstract. %%% %%% JO Nov 15: slight rewording -- hints how even AJ can introduce behavior invasiveness %%% Consequently, care must therefore be taken to additionally introduce implementations of all methods required by an interface, lest the extension behavior-invasively (as per Ernst and \Ref{Section}{aop-props}) affects the base. %%% %%% JO Nov 15: commented out - not sure what this contributed: %%%Failure to do so will be statically detected by {\aj}. %%% In our example, the \type{Adapt} aspect introduces the necessary methods to allow the base classes to fulfill the requirements of the abstract aspects. %%% %%% JO nov 15 -------- Issue separator: above and below are really separate \ssssects %%% The use of interfaces can also render an aspect type-invasive. A fundamental difference between how {\hj} and {\aj} model roles is that in {\hj} there is no possibility of confusion between a \type{Source} object in one use of the \collab{Back} slice and another. This follows from the fact that none of the input types in a composed HyperSlice remain after composition. The opposite situation is true for any use of interfaces (including {\aj}'s external ``implements'' declarations): all classes that implement an interface share a common supertype: the interface. Thus, if the \type{Back} aspect is applied to two different source and target pairs, each of the source classes will be upcastable to \type{Source}. This has two effects: invasiveness, and also the possibility of type confusion. Type invasiveness follows from the code \java{anItem instanceof Target} testing whether the \collab{back} concern has been attached to \java{anItem}. Ironically, while it \emph{is} apparent at runtime that \type{Item} implements \type{Target}, this is not apparent statically by %%% %%% DL Nov 20: s/Concrete1/SuperimposeBack/ %%% inspecting the code, unless we come across \type{SuperimposeBack}. A naming convention can easily ameliorate this, however. The objection to runtime composition tests may appear more of an aesthetic than Software Engineering issue, but the mechanism of attaching participants by implementing interfaces has consequences for type safety as well. If the \collab{back} collaboration were attached twice in an application, there would be two classes that now have the common supertype \type{Target} (there may be additional such classes in library code). The problem is that the behavior provided to the application by the concern is written against the interface types, while the methods implementing the concern's required interface will likely be casting these types to the implementation classes. That is, it is possible to pass \emph{any} \type{Target} class to a method with that argument type, but that method's implementation may likely assume that the \type{Source} returned by \java{getSource} is actually a \type{Container}. This assumption would be foolish in normal code implementations of an interface, but since a concern is declared as a unit, it makes sense for the programmer to assume that the attachment is also a unit. Our examples do not expose participant types in expected method signatures, so this case does not appear with {\ACs}. % invasive, type confusion. %% ************************************************************************** %% ************************************************************************** \kindrelated{Module Systems} \RevC{ On page 10, first paragraph of section 4.1, I would have liked to see more comment on your plans to use a third-party back end. Could you provide a few more sentences on this } %% **************************** Jiazzi ************************************* \RevB{Jiazzi: What caching example? This is in the appendix, which hasn't even been mentioned by this point. Or ever. } \instrelated{\ji}~\Cite{McDFlaHsi:Jiazzi} is the implementation of the Units \Cite{FlaFel:Units} module system for Java. {\ji} reuses Java's core composition feature---inheritance---and the Open Class pattern to construct the resulting classes from partial implementations. Explicit late binding (via the s.c. Open Class Pattern \Cite{CliftonEtAl:2000:MultiJava}) is used to allow mutually recursive dependencies between modules. A {\ji} implementation of the caching example would likely look very similar to the {\hj} version, but it is unclear whether it is possible to express generic interception of method executions in {\ji}. It is interesting to note that although developed completely separately, the current back end for {\ac}s and {\ji} are strikingly similar. The main differences are how the finished classes are assembled ({\ji} favors inheritance, while we manually combine and link participant {\tt .class} files) and the fact that we favor intrinsic typing for collaborations, while {\ji} allows reuse of a unit type for several unit implementations. \revC{On page 10, second paragraph of section 4.1, it seems that the more recent work at the U. of Utah would be more applicable here. Have you seen the work on Maya and Handiwrap? Is it more relevant than the Jiazzi work? } %% **************************** Ancona ************************************* %\instrelated{JavaMod}~\Cite{AncZuc:TrueMod} is another module system available for Java. % don't know what to say! %% ******************* JavaLayers / MixinLayers **************************** %\toolong{ %\instrelated{Mixin-Layers}~\Cite{mixin-layers:ecoop98} represent a collaboration as a layer of mixin classes. %This layer is treated as a unit, so that the interface to the mixin layer is a set of superclass imports, and a set of class exports. %Mixin layers can be composed creating composite layers, allowing modular construction of complex programs. %Both {\ji} and {\ac}s generalize layers, in that both can represent layers as a programming pattern, but can also represent other forms of modular construction. %} %% ************************************************************************** %% ************************************************************************** \kindrelated{Component Systems} \HIDE{ %We want to call a component system anything which reifies the component as an object. Component Systems can be seen as a restricted form of module system, where imports are not classes, but rather objects and operations on objects. The distinction is that component systems seldomly offer any form of parametricity over types, relying rather on subtype polymorphism. Furthermore, the result of linking components typically does not generate a new type, but rather links existing component instances together to construct complex behaviors from simpler ones. } %% ***************************** ArchJava ******************************** \HIDE{ \instrelated{ArchJava}~\Cite{Aldrich:2002:AJC,Aldrich:2002:ARA} is a a modern example of a component system. Components communicate with each other over named sets of methods, called ports. Component instances can be connected both statically or dynamically, and in both cases, the system guarantees that components only communicate to their neighbors, ensuring \emph{communication-integrity}. However, the authors point out that this applies only to method invocations---shared object references can still be propagated through the system allowing communication to pass via the shared object. {\ac}s are not able to conveniently express, nor guarantee communication integrity for dynamic component connection, but are able to quite well for the static case. Using encapsulation, we are able to make statements not only which components a component is able to talk \emph{to}, but more strongly which components it can talk \emph{about}. If a component doesn't import another component's type, direct communication between them is impossible. This applies additionally to auxiliary classes and objects that are passed between components. If a component has only a limited view of a class (for example omitting a sensitive field), then we can statically guarantee that this field cannot be directly manipulated by the component. If a component does not know about a class at all, it cannot communicate via objects of that type at all. Interestingly, analysis of the ArchJava papers has yielded a programming pattern---tentatively called the \emph{component/port} pattern, which significantly enhances the readability of an {\ac} by separating out connections between collaborations onto port classes. } {\ac}s are not able to conveniently express, nor guarantee communication integrity as presented in \instrelated{ArchJava}~\Cite{Aldrich:2002:ARA,Aldrich:2002:AJC} for dynamic component connection, but are able to do so quite well for the static case. Using encapsulation, we are able to make statements not only which components a component is able to talk \emph{to}, but more strongly which components it can talk \emph{about}. If a component doesn't import another component's type, direct communication between them is impossible. This applies additionally to auxiliary classes and objects that are passed between components. If a component has only a limited view of a class (for example omitting a sensitive field), then we can statically guarantee that this field cannot be directly manipulated by the component. If a component does not know about a class at all, it cannot communicate via objects of that type at all. %% ******************************** APPC et al. ********************************* \instrelated{\theAPPC} ~\Cite{MezLie:98:APPC} and the follow-on report \Cite{aspectual:LLM} are the immediate precursors to {\ac}s. {\APPCs} are rooted in Holland's executable contracts~\Cite{holland:thesis93} and in Rondo~\Cite{mezini:thesis97}. This work builds on \Cite{aspectual:LLM}, but with significant modifications from experience with implementation, and with a very different attachment / matching model stemming from clarified semantics. The difference in attachment and matching reflects that {\APPCs} are aimed at being language level components rather than system structuring modules. Additionally, they {\APPCs} offered somewhat weaker aspectual capabilities. Mezini and Herrmann \Cite{HerMez:00:PIROL} discuss a software engineering environment capable of combining dynamic plugability, separate compilation, and aspectual attachment. It is unclear how their {\sf PIROL} system deals with type safety. Mezini and Ostermann \Cite{MezOst:2002:OnDemRemod} propose a component system that incorporates ideas from AP\&PCs, but separates implementation from interface. The interface of the components is expressed as Java interfaces, which are implemented by the implementation types of the component. They suggest the use of families of dependent types \Cite{Ernst:2001:FP} to solve the typing issues of shared supertypes for multiple instances of a component. Type families are believed to be statically sound, but this has not been formally proven. Type families would likely prove a convenient resolution to the issues we have raised concerning type-invasive use of Java interface for reusable aspects in {\aj}. The components are connected to their host objects by runtime attachment, which is used to provide implementations for expected methods---a commonality to {\ACs} which exposes the shared ancestry of AP\&PCs. Runtime attachment buys great flexibility, allowing attachment to be performed at the granularity of individual objects rather than classes, and behavior to be varied over an object's lifetime. Mezini and Ostermann suggest that such runtime attachment may be a good base for \emph{fluid AOP}, which likewise would allow aspects to be attached and detached dynamically. %% ************************************************************************** %% ************************************************************************** \kindrelated{Modeling Languages} % composition patterns \RevC{Page 10- very bottom of page: "Composition patterns [ref] adds the concept of composition patterns to UML" This sentence seems to be a bit self-referencing. Perhaps a change could be "The work described in [Clarke and Walker 2001a] adds the concept...."} Clarke and Walker \Cite{ClaWal:2001:CP} adds the concept of \instrelated{Composition Patterns} to UML~\Cite{rational:UML-LUG}. The implementation suggestions for composition patterns \Cite{ClaWal:2001:AJHJ,ClaWal:2002:TSDL} strongly influenced the expression of reusable aspects and hyperslices in this paper, and we propose that {\ac}s do a particularly elegant job of representing Composition Patterns. It is unclear whether Composition Patterns capture multiple attachments of a collaboration, and how sharing of members between such attachments would be expressed.