=Paper=
{{Paper
|id=None
|storemode=property
|title=Generic IDE Support for Dispatch-Based Composition.
|pdfUrl=https://ceur-ws.org/Vol-564/compositionvariability2010_submission_2.pdf
|volume=Vol-564
}}
==Generic IDE Support for Dispatch-Based Composition.==
https://ceur-ws.org/Vol-564/compositionvariability2010_submission_2.pdf
Generic IDE Support for Dispatch-Based Composition
Christoph Bockisch Andreas Sewe
Software Engineering group – University of Software Technology group – Technische
Twente, P.O. Box 217, 7500 AE Enschede, the Universität Darmstadt, Hochschulstr. 10, 64289
Netherlands Darmstadt, Germany
c.m.bockisch@ewi.utwente.nl sewe@st.informatik.tu-darmstadt.de
ABSTRACT guages share concepts from several broad categories: selection of
Programming-language research produces a significant number of new call sites based on syntactic properties, access to the runtime state
programming styles to improve the composability of programs. This in which they are executed, evaluation of functions over the runtime
increases re-usability as well as other quality characteristics. But al- state to select from alternative meanings, declaration of meaning in
though they offer interesting composition concepts, new program- terms of actions on the runtime state, and description of relationships
ming languages are rarely used because IDE support, which devel- between applicable actions. Each language uses some extension of
opers are used to, is missing. Examples of such IDE support are the each core concept and the concrete concepts used in different lan-
visualization of call hierarchies or interactive debugging. While some guages often overlap.
languages, e.g., AspectJ, eventually reach a more mature level with Similarly, the requirements for IDE support of such languages over-
elaborate IDE integration, not all language designers are able to invest lap. Different kinds of support for the development in the investigated
this much effort towards IDE integration. Furthermore, the IDE inte- languages are recurring, but have to be implemented from scratch for
gration of AspectJ also has its limitations; when debugging, the devel- each language. As a result, the IDE support for new languages is typ-
oper is confronted with synthetic code with no exact correspondence ically limited, as more effort is spent on the design of the language
in the source code. As a result, the developer needs to understand the and the implementation of compilers than on the language’s IDE inte-
transformations performed by the compiler. Finally, some informa- gration. In the following, we discuss a few examples of IDE support
tion invariably gets lost during weaving, e.g., the ability to map code from which all investigated languages can benefit.
evaluating pointcut designators to their definition in the source code. Among the investigated languages, the aspect-oriented ones sup-
In this paper, we propose to implement generic IDE tools for pro- port implicit invocation. It thus is desirable to let the IDE visualize the
gramming languages that provide advanced dispatching mechanisms. places in the code at which other code may be (implicitly) the target
Such languages, including predicate dispatching and pointcut-advice of dispatch. To this end, the IDE support for the AspectJ language, the
languages, can be mapped to our execution model, called ALIA. The AspectJ Development Tools (AJDT), provides different ways of visu-
same execution model can then drive debugging functionality as well alizing such relations. However, even for languages with only explicit
as static IDE services. invocation, similar IDE support is present. The Eclipse Java Develop-
ment Tools (JDT) allow, e.g., to search for all call sites of a method,
or to show the possible targets of a call site. It should be noted that,
1. INTRODUCTION while calls must be explicit in Java, they can be virtual and multiple
In order to improve the modularity of source code, research strives implementations may be applicable. The potential targets depend on
to define new composition mechanisms, often in terms of new lan- the inheritance hierarchy, which may be too complex for the devel-
guages. Many such languages provide composition mechanisms by oper to grasp in its entirety. IDE support is therefore essential. The
allowing to influence the dispatch of, e.g., method calls, like in multi- same observation holds for predicate-dispatching languages.
ple dispatching [9] or predicate dispatching [14]. But other composi- All investigated languages can be compiled to pure Java bytecode
tion styles can be mapped to a dispatching-based execution model as and can run on a standard JVM. Therefore, the default debugger of
well, as we have shown [5] for pointcut-advice languages [15], Com- the IDE can be used to debug programs written in those languages.
position Filters [12], and a DSL for composing objects following the What is debugged, however, is the program after the transformation.
Decorator design pattern. Consequently, the developer is facing large amounts of infrastructural
Usually, advanced dispatching mechanisms are provided as an ex- code that has been inserted by the compiler to realize the semantics
tension of an existing programming language, the so-called base lan- and will often end up stepping through code for which no source code
guage, and the semantics of the advanced program features are re- exists, which makes it even harder to understand. Another difficulty is
alized by transforming them to the base language’s imperative code. that the Java debugger assumes that all code of a class was compiled
We have shown [5] that the dispatching mechanisms of all these lan- from a single source file, but with new composition mechanisms this
assumption may no longer hold: one class may be composed of multi-
ple source files. Compilers merge all files into one; thus, the mapping
from target code to the source code is lost and cannot be used by the
debugger anymore.
We have provided an architecture for implementing advanced-dis-
patching languages in a way that they can share the implementation
of overlapping concepts [5]; it is called the Advanced-dispatching
Language-Implementation Architecture (ALIA) and consists of a lan-
.
5
LIAM FIAL
4
Refinement
of LIAM
2 3 FIAL in-
Importer LIAM model
stantiation
1 6
Compiler Java bytecode Java Virtual
Machine
Figure 1: Overview of the application life cycle in ALIA4J-based language implementations.
guage-independent meta-model of advanced dispatching concepts and Attachment
any number of execution environments that process models conform-
1..*
ing to this single meta-model. For languages extending Java we have
Action Specialization ScheduleInfo
implemented this architecture, called ALIA for Java (ALIA4J), which
furthermore provides a framework factoring out shared components *
0..2
of such execution environments. Context
*
Expression
Predicate Pattern
In this position paper, we will discuss how ALIA’s meta-model,
more specifically its implementation in ALIA4J, and the framework * 0..1
for execution environments can be used to provide a generic infras- AtomicPredicate
tructure for IDE support of advanced-dispatching languages.
Figure 2: Entities of the Language-Independent Advanced-
2. THE ALIA ARCHITECTURE FOR JAVA dispatching Meta-Model (LIAM) as UML class diagram.
In ALIA4J, the meta-model stipulated by ALIA is embodied in the
Language-Independent Advanced-dispatching Meta-model (LIAM). pair, in terms of predicate dispatching, an attachment corresponds to
LIAM hereby acts as the form of intermediate representation for ad- a predicate method. Action specifies an action to which the dispatch
vanced dispatching in programs. The actual intermediate representa- may lead (e.g., an advice or the predicate-method body). Special-
tion, in turn, is a model conforming this meta-model (the so-called ization defines static and dynamic properties affecting dispatch: pat-
LIAM model). Code of the program not using advanced dispatching terns specify syntactic properties of call sites which are affected by
mechanisms is represented in its conventional Java bytecode form. the declared dispatch; predicate and atomic predicate entities model
The Framework for Implementing Advanced-dispatching Languages (FIAL) dynamic properties a dispatch depends on (dynamic pointcut desig-
implements common components and work flows required to imple- nators in AO terminology). Context entities model access to values in
ment execution environments based on a JVM for executing LIAM the context of a dispatch, like the calling object or argument values.
models. A brief overview, of the approach can be found in [7]1 . Finally, the schedule information models constraints between multi-
Figure 1 shows an overview of the ALIA4J approach. Concretely, ple actions applicable at the same generic-function call. This includes
the flow of compiling and executing applications in this approach is the order of their execution, as well as relations like mutual exclusion.
shown. The compiler 1 starts processing the source code; a dedi- At runtime, FIAL derives a dispatch model for each dispatch site
cated importer component 2 adapts the compiler’s output to a model in the program from all attachments that have been defined. Thereby,
for the advanced dispatch declarations in the program 3 based on the FIAL solves the constraints specified as schedule information and de-
refined subclasses 4 of the LIAM meta-entities 5 . Furthermore, the rives a single dispatch function per call site from the predicates of
compiler produces an intermediate representation of those parts of the all specializations. This function is represented as a binary decision
program that are expressible in the base language 6 alone. diagram (BDD) [8], where the inner nodes are the atomic predicates
The nine meta-entities of LIAM capture the core concepts under- used in the predicate definitions and the leaf nodes are labeled with
lying the various dispatching mechanisms, but at a finer granularity the actions to be executed. For each possible result of dispatch, the
than the concrete concepts found in high-level languages; one con- BDD has one leaf node. Figure 3 shows an example of such a dis-
crete concept often maps to a combination of LIAM’s core concepts. patch model with the atomic predicates x1 and x2 and the actions y1
Figure 2 shows the meta-entities in LIAM, which are implemented and y2 . For a detailed explanation of this model, we refer the reader
as abstract classes. Attachment, specialization, and predicate are an to [18].
exception to this rule, i.e., they are concrete classes, as they provide The dispatch model is defined in such a way that an execution strat-
logical groupings of entities of the meta-model and cannot be refined. egy can immediately be derived from it. The default execution strat-
The meta-entities are discussed in detail in [5, Chapter 3.2] .2 egy requires that each concrete entity implementation provides a Java
In short, an attachment corresponds to a unit of dispatch descrip- method implementing its semantics. It is possible to override the de-
tion. In terms of aspect-orientation (AO), this is a pointcut-advice fault strategy and implement an optimization strategy on a per atomic
predicate basis, in a modular way. These strategies are extensively
1
Some details presented in [7] are outdated, but it may nevertheless discussed in [5].
act as an introduction to the basic concepts. The approach allows to implement new concrete concepts modu-
2
There, some meta-entities are named differently, but the structure of larly by refining the abstract class of a meta-entity. We have already
the meta-entities is the same. Therefore, the interested reader will be shown how to map the languages AspectJ, JAsCo, Compose*, Cae-
able to map the discussion to the new names.
x1
e
tru
fals
x2
e
fa
true
ls
e
y1 , y 2 y1 y2
Figure 3: A dispatch function’s evaluation strategy.
sarJ, and a simple domain-specific language to our meta-model [5].
By now, we have also developed mappings for the languages Mul-
tiJava [10], JPred [16], and ConSpec [4], which are, however, still
unpublished work.
Important for the present paper is the fact that all concrete concepts
participating in a dispatch are expressed in a declarative and fine- Figure 4: Linking of pointcut-advice and advised locations in
grained model. This model can thus be used to derive information AJDT.
relevant to the different services of an IDE. Furthermore, the model
stays first-class during the execution of a program and can therefore whose compilation has lead to a bytecode instruction, respectively in
easily support dynamic features of an IDE, e.g., debugging, profiling, the case of LIAM to a model entity. The builder uses this informa-
or testing. tion to establish links between source locations, as is stipulated by the
AJDT abstract structure model.
In the current version, input is hard-wired to the AspectJ compiler’s
3. ALIA4J-BASED IDE SUPPORT output. But since our architecture already provides a plug-in mech-
So far, we have implemented a limited IDE integration for the anism to provide input in different formats, a straight-forward exten-
ALIA4J mapping of AspectJ language. However, we aim at making sion is to use this mechanism. Then, the same support can be provided
this support more general and support other languages, too. More- for any language that can be mapped to our approach.
over, we aim at filling the gaps in our IDE support. While the above AJDT extension shows the feasibility of building
static tool support based on our ALIA approach, we do not aim to
3.1 Cross References for AspectJ extend the AJDT in our future research work. Instead, we will re-
For the AspectJ language, we have implemented a nearly complete implement similar support, including an AJDT-like structure model
integration with our architecture. All necessary LIAM entities are and related views, by directly extending the Java Development Tools
implemented and we have developed an automatic importer compo- (JDT). This is necessary because the AJDT and the structure model
nent which allows to execute AspectJ programs on an FIAL-based are hard-linked to the AspectJ compiler, a dependency that we would
execution environment while developing it in the standard AJDT. The rather avoid. Furthermore, we have already outlined that there are
benefit of this integration is that some FIAL-based execution envi- commonalities between the cross references view and, e.g., the call
ronments perform sophisticated dynamic optimizations which make hierarchy of methods explicitly called. Since both concepts, explicit
AspectJ programs execute faster than the product of the standard com- and implicit calls, are unified in our architecture, we like to provide
piler [6]. IDE support for both in the same way. The developer will benefit
Because we bypass the weaving phase of the AspectJ compiler in from such unified tools, because he will see all contributors to a call
this approach, pointcuts are not evaluated at compile time anymore. at the same time.
Thus, the compiler also cannot determine the crosscutting structure
of the aspects which would normally be used by the IDE to show,
e.g., in the “Cross References” view, or which would be used to facil-
itate navigation between advised join point shadows and their advice, 3.2 Debugging Support
as depicted in Figure 4. To restore the accustomed functionality, we The debugging support we envision will be based on the availabil-
have developed an extension to the AJDT that provides the crosscut- ity of our declarative dispatch model at runtime. For example, this
ting structure when compiling AspectJ applications for execution on a makes it possible to visualize the dispatch model for a call at a break-
FIAL-based execution environment, i.e., without compile-time weav- point. The dispatch model is complete in the sense that it specifies on
ing. This comprises an instantiation of the FIAL framework which is, which runtime values the dispatch depends and which predicates are
however, not integrated in a Java Virtual Machine like a full-fledged evaluated on these values. While the model, naturally, only specifies
FIAL-based execution environment. Instead of providing FIAL with the role of values that are used (e.g., “the first argument value”), in a
dynamic information about generic-function calls, it provides static debugger, also the value can be shown. This is already done by mod-
approximations of call sites. Our framework then evaluates all pat- ern debuggers, e.g., in the “Variables” view of the Eclipse debugger.
terns in the LIAM models of the AspectJ project and builds the dis- In contrast to general-purpose debuggers, our debugger for advanced
patch model for each call site. Afterwards, for dispatch models which dispatch will only show values relevant for the dispatch, and associate
are not trivial, i.e., where no advice is attached, the links are estab- them to their role names.
lished in AJDT’s abstract structure model. Another contribution that results from using the ALIA approach
To support this work, the LIAM meta-entities are extended to also to enable debugging is that dispatch declarations defined in different
store the location in the source code where they are defined. This is languages can be combined. Since all dispatch declarations (pointcut-
similar to the debug information present in Java bytecode. This de- advice, multi-methods, etc.) are mapped to the same meta-model,
bug information facilitates recovery of the file name and line number i.e., to LIAM, the actions resulting from these declarations can be
Nevertheless, we envision to increase the provided information in
several ways. First, it is interesting to specify not only that an ad-
vice is conditional but also, what the condition is. Next, presenting a
sequential list of advice is too limited because some languages sup-
port more complex relations between advice at a join-point shadow.
AspectJ, e.g., already provides “around” advice which can be nested;
thus, a tree would be more suitable to present this information. Other
languages allow to define more complex relationships between advice
at a shared join-point shadow. Examples are mutual exclusion or con-
ditional execution in Compose*, or overriding in JPred and MultiJava.
The dispatch model, explained in some detail in the previous sub-
section, can also be made available before runtime. A visualization
of the cross references can, thus, take all information in the dispatch
model into account. This includes the exact specification of the condi-
Figure 5: An idea of the GUI for generic debugging support for tion under which an action is applicable at a call, dispatch declarations
multiple advanced-dispatching languages. sharing the call site and relationships (order, execution constraints,
etc.) among them.
executed alongside. That means that, e.g., calls to multi-methods can Since the implementation of our architecture, i.e., FIAL and LIAM,
be advised. is very modular, it is also easily possible to make part of their im-
Figure 5 illustrates the envisioned visualization in debugger. At the plementation interactive. A possible use is making pattern matching
top of the figure, three editors are shown. The editor at the left-hand interactive in order to debug patterns. The AJDT shows the devel-
side shows Java code calling the method C.m(A) in line 7; at this line, oper in which places pointcuts match, but in some cases, developers
a breakpoint is set. At the right-hand side, the top editor shows an of pointcut-advice may wonder why a specific pointcut (respectively
AspectJ pointcut-advice and the bottom editor shows a multi-method the pattern used in a pointcut) does or does not match. Since the def-
defined in MultiJava. Both dispatch declarations define a dynamic inition of specializations (the equivalent to pointcuts in AspectJ) and
constraint on the first argument: Only when this is of type B, the the call sites are available first-class in FIAL, it is possible to perform
advice is to be executed, respectively, the multi-method applies. In the evaluation, e.g., for a specific call site, and show the developer
this case, the multi-method overrides the Java method definition. the different steps in the evaluation. This is similar to the debugging
The bottom part of Figure 5 shows a possible visualization of the support for dispatch functions, but can be performed before runtime.
(simplified) dispatch model for the call at the breakpoint. The dis-
patch function is simple and only contains one atomic predicate, which 4. RELATED WORK AND FUTURE WORK
tests the type of a context value, in the example that of the first argu- Eaddy et al. [13] have identified several requirements for debug-
ment. The bold elements show the path which the evaluation actu- ging aspect-oriented programs. They support source-level debugging
ally has followed. The bold solid arrow emerging from the predi- by deferring the weaving to runtime, as in our approach. It is thus
cate indicates that it has been satisfied, therefore, the actions in the possible to view the definition of pointcut-advice that have lead to the
bold box are to be executed as the dispatch’s result, i.e., the actions execution of a specific statement. In contrast to our approach, the dis-
Logger.before1 and handleB.m(B). If the predicate was satisfied, the
patch function is not represented in a structured declarative way, but
action C.m(A) would be executed. only by the imperative code resulting from the pointcut-advice defi-
In a graphical debugger as proposed here, the user can select and nitions. Thus, the dynamic program state that has lead to executing
introspect entities that participate in the dispatch at which the virtual or not executing an advice is more difficult to determine for the de-
machine is currently suspended. In the figure, the TypePredicate is veloper. Furthermore, the original definition of an aspect (or dispatch
selected. The selection in the editors showing the AspectJ and Mul- declaration) is not presented. Therefore, constraints among advice
tiJava code highlights the code which has led to this predicate in the sharing this join-point shadow are not easily visible, and, thus, cannot
dispatch function. The “Variables” view shows the runtime values on be easily debugged.
which the current selection depends, i.e., the first argument value. As Pothier et al. [17] discuss a retrospective debugging approach for
can be seen, this is an instance of B and therefore, the predicate is aspect-oriented programs. They record a complete execution trace
satisfied. that can be inspected after the execution. While this is not the kind
As outlined above, the entities in the dispatch model can be linked of debugging that we will support, we will nevertheless take inspira-
to multiple source locations. The result of single atomic predicates in tion from their work in order to present AO-specific visualization of
the dispatch function can be presented, which explains the result of debugging information.
the dispatch. Potentially, it will be advantageous not to completely De Borger at al. [11] define an architecture for implementing de-
evaluate the dispatch function and let the developer view the result buggers for aspect-oriented languages. This architecture is based on a
afterward, but to allow a step-wise evaluation of the dispatch function. structurally reflective model of aspect definitions. For each aspect that
We will investigate both approaches. is active during the program’s execution, its structure can be queried
by means of this model. It is possible to determine the executions of
3.3 Additional Ideas advice, which are caused by a pointcut, including executions in the
The AJDT provides the developer with more detailed information past and in the future. Their model is meant to be an API used by a
than just “these advice apply to this join-point shadow”. It already debugger front-end and offers some infrastructure required by debug-
includes additional information by specifying whether the join-point gers, e.g., to enable aspect-specific breakpoints.
shadow is always affected by an advice or only sometimes because Our underlying model is more fine-grained and provides more in-
there is a dynamic pointcut designator in the matching pointcut. Also, formation: constraints among aspects like precedence are not avail-
when showing the applicable advice, the AJDT orders them according able through the reflective API. Nevertheless, we plan to investigate
to their precedence. whether their work can be used as an interface for our approach. It
may be possible that our back-end, i.e., a FIAL-based execution envi- successfully mapped AspectJ’s inter-type member declarations to our
ronment, can be used as an implementation of their API. Should we approach; in fact, the example used in section Section 3.2 uses the
follow this path, we aim to contribute additional functionality to the open classes feature of MultiJava, which is equivalent to inter-type
API which can be provided by means of our back-end. Similarly, the member declarations.
IDE integration of debugging that we envision, may be implementable
with their API as back-end. 6. ACKNOWLEDGMENTS
The IDE Meta-tooling Platform (IMP) [2] is an Eclipse project aim-
We would like to thank all contributors to the ALIA4J project. In
ing at providing meta-implementations of typical IDE tools. Exam-
particular, our thanks go to Jannik Jochem, who developed the inte-
ples are a re-usable infrastructure for syntax highlighting, refactoring
gration of ALIA4J with the AJDT.
support, semantic or static analyses, execution and debugging. Their
focus is on providing an infrastructure for the IDE integration and
the graphical user interface, but not on providing an infrastructure for 7. REFERENCES
the runtime part of actual debugger implementations. Nevertheless, [1] The Dynamic Language Toolkit.
we will consider to integrate our work with this project. Potentially, http://eclipse.org/dltk/, 2010.
the LIAM meta-model can act as re-usable abstract syntax tree for [2] The IDE Meta-tooling Platform.
dispatch declarations in the IMP. We hope to be able to re-use compo- http://eclipse.org/imp/, 2010.
nents for the more static IDE support like the visualization of implicit [3] The Textual Modeling Framework.
and explicit calls. http://eclipse.org/xtext/, 2010.
There are other Eclipse projects into which we may integrate our [4] I. Aktug and K. Naliuka. ConSpec: A formal language for
envisioned work. The first option is the Dynamic Languages Toolkit policy specification. In Proceedings of REM. Elsevier Science
(DLTK) [1] which is a collection of frameworks to minimize the ef- Publishers B. V., 2008.
fort of developing IDEs for dynamic languages. The second option is
[5] C. Bockisch. An Efficient and Flexible Implementation of
the Textual Modeling Framework (Xtext) [3] which is a framework
Aspect-Oriented Languages. PhD thesis, Technische
for generating full-fledged Eclipse text editors from grammars for
Universität Darmstadt, 2009.
domain-specific languages, including an abstract source code model.
[6] C. Bockisch, S. Kanthak, M. Haupt, M. Arnold, and M. Mezini.
Efficient control flow quantification. In Proceedings of
5. CONCLUSION OOPSLA. ACM Press, 2006.
In the suggested research work, we aim at providing a generic im- [7] C. Bockisch and M. Mezini. A flexible architecture for
plementation of IDE support, most importantly containing debugging pointcut-advice language implementations. In Proceedings of
support, for advanced-dispatching programming languages. We will VMIL, New York, NY, USA, 2007. ACM.
build this support on the FIAL framework and the LIAM meta-model [8] R. E. Bryant. Graph-based algorithms for Boolean function
(part of the ALIA architecture for Java), which provide a first-class, manipulation. IEEE Transactions on Computers, C-35, 1986.
declarative model of all dispatches in a program. We have mapped [9] C. Chambers. Object-oriented multi-methods in cecil. In
the aspect-oriented languages AspectJ, CaesarJ, Compose*, JAsCo, Proceedings of ECOOP. Springer Verlag, 1992.
the predicate-dispatching languages JPred and MultiJava, and other
[10] C. Chambers and W. Chen. Efficient multiple and predicated
languages to this model. All mapped languages will thus be able to
dispatching. In Proceedings of OOPSLA. ACM, 1999.
directly benefit from the IDE support we aim to provide.
[11] W. De Borger, B. Lagaisse, and W. Joosen. A generic and
The IDE support will primarily consist of a navigable visualization
reflective debugging architecture to support runtime visibility
of explicit as well as implicit calls (the former are used in predicate
and traceability of aspects. In Proceedings of AOSD. ACM,
dispatching, the latter in pointcut-advice languages), and of debug-
2009.
ging support. Both kinds of IDE integration will be driven by the
declarative, first-class dispatch model available in ALIA. Since ALIA [12] A. de Roo, M. Hendriks, W. Havinga, P. Dürr, and
facilitates the execution of dispatch declarations written in different L. Bergmans. Compose*: a language- and
languages, all such dispatch declarations can be executed in one pro- platform-independent aspect compiler for composition filters.
gram run alongside; similarly, the debugging support we envision will In Proceedings of WASDeTT, 2008.
be able to debug all such declarations at the same time. It will fa- [13] M. Eaddy, A. V. Aho, W. Hu, P. McDonald, and J. Burger.
cilitate to jump to the source code defining the dispatch declaration, Debugging aspect-enabled programs. In Software Composition.
and it will to show all execution steps leading to a specific dispatch- Springer, 2007.
ing result. We will investigate similar support for reasoning about [14] M. Ernst, C. Kaplan, and C. Chambers. Predicate dispatching:
the evaluation of patterns used in pointcut-advice, respectively for the A unified theory of dispatch. In Proceedings of ECOOP.
composition of actions applicable at the same call site. Springer Verlag, 1998.
Providing such IDE support that will work “out of the box” will [15] H. Masuhara and G. Kiczales. Modeling crosscutting in
increase the acceptance of new programming languages which offer aspect-oriented mechanisms. In Proceedings of ECOOP.
sophisticated composition mechanisms by means of dispatch decla- Springer Verlag, 2003.
rations. The envisioned IDE support will make the effects of apply- [16] T. Millstein, C. Frost, J. Ryder, and A. Warth. Expressive and
ing advanced composition mechanisms to a program more obvious modular predicate dispatch for Java. ACM Transactions on
to developers, which will help them to learn such new mechanisms. Programming Languages and Systems, 31(2), 2009.
ALIA’s ability to execute programs written in different languages with [17] G. Pothier and E. Tanter. Extending omniscient debugging to
different composition primitives and the resulting IDE support, will support aspect-oriented programming. In In Proceedings of
give developers the free choice of combining different languages and SAC. ACM, 2008.
benefit from all their features. We would also like to note that many [18] A. Sewe, C. Bockisch, and M. Mezini. Redundancy-free
composition mechanisms which do not obviously map to a dispatch- residual dispatch. In Proceedings of FOAL. ACM, 2008.
ing problem can still be handled by our architecture. For example, we