Language and Compiler Support for Mixin Programming Richard

Language and Compiler Support for Mixin Programming Richard Cardone Calvin Lin, Advisor Department of Computer Sciences University of Texas at Austin April 22, 2002 4/22/02 Cardone Defense

The Problem l Large applications are difficult and expensive to build! l Variation over time l Variation in execution environments 4/22/02 Cardone Defense 2

Variation over Time Class Hierarchy Tangled feature code feature 1 feature 2 feature 3 feature 4 feature 5 4/22/02 Scattered feature code Scattered/Tangled code: hard to understand, maintain, and reuse Cardone Defense 3

Variation in Execution Environments l Need multiple versions of an application l Different users l Different market segments l Different computer architectures Support for multiple versions requires effective reuse 4/22/02 Cardone Defense 4

Our Solution: Java Layers (JL) l Address problems of variation over time and environments l l Extend Java with mixins l l Build software from reusable components Mixins: an object-oriented reuse technology Provide novel language and compiler support for mixin programming 4/22/02 Cardone Defense 5

Presentation Overview l Mixin Background l Contributions l Support for Mixin Programming l l 4/22/02 l Addressing complexity l Increasing expressiveness Evaluating Mixin Programming l Fidget: Building flexible widgets l ACE: Comparing OO frameworks Conclusion & Future Work Cardone Defense 6

Mixins as Reusable Components Mixins: types with parametrically-specified supertypes F 1<Vector> F 2<F 1<Stack>> class F 1<T> extends T {…} Vector Stack class F 2<U> extends U {…} F 1_Vector F 1_Stack Prototypical JL Mixin Classes F 2_F 1_Stack l Mixins increase modularity l l Encapsulate feature implementations Mixins support flexible composition l 4/22/02 Parent/Child relationships are not hardcoded Cardone Defense 7

Mixins Increase Complexity l Increased flexibility can lead to increased complexity! l Can arbitrarily compose mixins Easy to make undesirable compositions l Supertypes are not known at definition time Initialization is tricky l Existing OO languages don’t support useful mixin idioms 4/22/02 Cardone Defense 8

Why Java Layers? Make mixins a practical way to program l l Start with Java l Widespread use l Embodies good software engineering characteristics Address complexity of mixin programming l 4/22/02 Design and implement specialized mixin support Cardone Defense 9

Contributions 1. Design new language and compiler support for mixin programming l Enhance effectiveness of mixins 2. Integrate mixin support into an OO language l Implement Java Layers as an extension of Java 3. Demonstrate effectiveness of mixin programming using Java Layers 4/22/02 l Cardone Defense Show that mixin programming improves application development 10

Overview l Mixin Background l Contributions l Support for Mixin Programming l l 4/22/02 l Addressing complexity l Increasing expressiveness Evaluating Mixin Programming l Fidget: Building flexible widgets l ACE: Comparing OO frameworks Conclusion & Future Work Cardone Defense 11

Mixin Initialization Problem: Mixin initialization is tricky because superclass is not known Classes class Parent. A {Parent. A(){…} …} class Parent. B {Parent. B(String s){…} …} class M<T> extends T {M(int i){x = i; …} …} Instantiations Superclass no-argument constructor implicitly called M<Parent. A> // OK M<Parent. B> // ERROR! 4/22/02 Cardone Defense 12

Previous Approaches to Mixin Initialization l l Restrict constructor signatures l Often only no-arg constructor allowed l Sometimes special argument classes are used Leads to ad-hoc initialization protocols l Special initialization methods l Maintenance of auxiliary data structures 4/22/02 Cardone Defense 13

Constructor Propagation JL Solution: Automatically add constructor arguments Redefined Classes class Parent. B {propagate Parent. B(String s){…} …} class M<T> extends T {propagate M(int i){x = i; …} …} M<Parent. B> Parent. B M_Parent. B class M_Parent. B extends Parent. B { M_Parent. B(int i, String s) {super(s); x = i; …} …} l Simple, orthogonal, no extra code to maintain l Reduces the number of hand-coded constructors 4/22/02 Cardone Defense 14

Restricting Composition Problem: Mixins can be composed in arbitrary ways Common Solution: Use type parameter constraints to prohibit invalid or undesirable compositions Constrained Type Parameter Example class Task. Base implements Task. Ifc {…} class Task. Queue<T implements Task. Ifc> extends T {…} Instantiations Task. Queue<Task. Base> Task. Queue<Hashtable> // OK // ERROR! But What About: Task. Queue<Task. Base>> 4/22/02 Cardone Defense // Type-safe, but… 15

Semantic Checking l JL’s Semantic Checking goes beyond syntactic type checking l Tests for the presence, absence, ordering and cardinality of mixins l Tests use regular expression pattern matching and a count operator Single Use Idiom class Task. Queue<T implements Task. Ifc> extends T requires unique {…} l Simpler programming model than previous approach [Batory 97] l See thesis for details 4/22/02 Cardone Defense 16

Overview l Mixin Background l Contributions l Support for Mixin Programming l l 4/22/02 l Addressing complexity l Increasing expressiveness Evaluating Mixin Programming l Fidget: Building flexible widgets l ACE: Comparing OO frameworks Conclusion & Future Work Cardone Defense 17

Referencing the Most-Derived Class l Applications are built incrementally in layers using mixins l l Features added one-by-one Most-derived class in mixin hierarchy contains all features DNode<SNode<int>> Linked List Example class SNode<T> { T data; SNode<T> next; } SNode_int next; class DNode<T> extends T { DNode<T> prev; } DNode_SNode_int prev; We want next and prev to be type DNode_SNode_int 4/22/02 Cardone Defense 18

Previous Approaches l Ad-hoc naming conventions l l Configuration repositories [Czarnecki 00] l l Fixed leaf class name Maintain auxiliary data New type systems [Thorup 97, Bruce 97 -98] l 4/22/02 Powerful, but change Java semantics and implementation Cardone Defense 19

Implicit This Type Parameter l This refers to most-derived class in mixin-generated hierarchy l l Implicit type parameter This is bound at instantiation-time DNode<SNode<int>> SNode<int> Linked List Example class SNode<T> { T data; This next; } SNode_int next; DNode_SNode_int next; class DNode<T> extends T { This prev; } DNode_SNode_int prev; l Provides a static way to reference most-derived class l Easy to use 4/22/02 Cardone Defense 20

Encapsulating Feature Code Class Hierarchy feature 1 Encapsulate feature code l Mixin Layers are mixins with nested types [Smaragdakis 98] l Encapsulate application features that crosscut multiple classes l Specialize multiple (nested) classes simultaneously 4/22/02 Cardone Defense 21

Defining Mixin Layers Basic widget support class Base. Fidget { class Button {…} class Checkbox {…} …} Basic display support class Lt. Wt. Fidget<T> extends T { class Button extends T. Button {…} class Checkbox extends T. Checkbox {…} …} Color display support class Color. Fidget<T> extends T { class Button extends T. Button {…} class Checkbox extends T. Checkbox {…} …} 4/22/02 Cardone Defense 22

Composing Mixin Layers Color. Fidget<Lt. Wt. Fidget<Base. Fidget>> l Base. Fidget Button Check. Box . . . Lt. Wt. Fidget Button Check. Box . . . Color. Fidget Button Check. Box . . . Deep Conformance inheritance pattern for mixin layers [Smaragdakis 99] l Enclosing classes form a hierarchy l Nested classes form hierarchies with corresponding nested classes 4/22/02 Cardone Defense 23

Alternative Implementations of Deep Conformance Constraints l l l One size fits all l Make all subtyping deeply conforming l Breaks existing code l Inappropriate semantics Two sizes fit all [Smaragdakis 99] l Types require either deeply conforming subtypes or they don’t l Requires knowledge about future usage A more flexible approach l 4/22/02 Specify deep conformance constraints in subtypes Cardone Defense 24

Expressing Deep Conformance in JL l JL’s deeply modifier enforces deep conformance l Types can require deeply conforming type parameters l Types can declare themselves to be deeply conforming class Color. Fidget<T extends Base. Fidget deeply> extends T deeply {class Button extends T. Button {…} class Checkbox extends T. Checkbox {…} …} l T conforms to Base. Fidget Color. Fidget conforms to its superclass First implementation of deep conformance l Simple, orthogonal, static l Ensures structural compatibility in mixin layer compositions 4/22/02 Cardone Defense 25

The Big Picture Java Layers = Java + Constrained Parametric Polymorphism + Constructor Propagation + Implicit This Type Parameter + Deep Conformance + Semantic Checking + Class Hierarchy Optimization 4/22/02 Cardone Defense Design only 26

Overview l Mixin Background l Contributions l Support for Mixin Programming l l 4/22/02 l Addressing complexity l Increasing expressiveness Evaluating Mixin Programming l Fidget: Building flexible widgets l ACE: Comparing OO frameworks Conclusion & Future Work Cardone Defense 27

Evaluating Java Layers l Can we encapsulate application features in mixins? l If YES, then we automatically support application variation l Is JL’s language support for mixin programming effective? l Is mixin programming practical? l 4/22/02 Do mixins improve application development? Cardone Defense 28

Device-Independent Programming l l Today’s computing devices are diverse l Workstations, PDA’s, cell phones, consumer appliances l Different capabilities: CPU, RAM, I/O, graphics, storage, connectivity Still, different devices often support the same function l 4/22/02 Ex: User interface, network protocol stack Cardone Defense 29

Fidget = Flexible Widgets Problem: Same function is re-implemented for different devices Solution: Implement library code that’s reusable on dissimilar devices l Re-engineer a subset of Java AWT widget library using mixin layers l Generate specialized GUI libraries for different devices l l Workstations, PDAs and cell phones l Tailor interfaces to device capabilities l Minimize unneeded code Generate GUI libraries from a single code-base 4/22/02 Cardone Defense 30

Generating Fidget Libraries Basic Fidget Class class Base. Fidget { class Button {…} class Checkbox {…} …} Optional features implemented in 13 mixin layers: Color, event handling, look and feel, … GUI Library: Handles Mouse Events class Fidget extends Event. Mouse<Lt. Wt. Fidget<Base. Fidget>> {} GUI Library: Handles Mouse, Keys and Color class Fidget extends Color. Fidget<Event. Key<Event. Mouse<Lt. Wt. Fidget<Base. Fidget>>>> {} 4/22/02 Cardone Defense 31

Fidget Results l l Portable GUI libraries can be built using mixin layers l Encapsulate GUI features in mixin layers l Generate different GUI libraries from the same mixin code-base JL language support effective l This and deeply are key to Fidget’s design l Most widget constructors are automatically generated 4/22/02 Cardone Defense 32

Reuse with OO Frameworks l Frameworks are current state of the art OO reuse technology l l Compare programming with mixins and programming with frameworks Frameworks are application starter kits 4/22/02 l Abstract classes provide partially implemented applications l Programmers supply concrete classes to complete applications Cardone Defense 33

The ACE Framework l Schmidt’s Adaptive Communication Environment (ACE) l C++ client/server application framework l Proven, mature OO framework technology l 4/22/02 More than 60 commercial and academic applications Cardone Defense 34

Re-Engineering ACE l Re-engineer a subset of the ACE framework using mixins l Decompose ACE interfaces into smaller JL interfaces l l JL interfaces define-grain application features l Each feature is implemented in a mixin Compose applications by mixing and matching features 4/22/02 Cardone Defense 35

Re-Engineered Interfaces Task Timer Queue Reactor No. of ACE Interfaces 1 1 1 ACE Interface Width 15 20 24 66 5 5 No. of JL Interfaces 10 13 13 27 3 4 Avg. JL Interface Width 1. 5 1. 8 2. 4 1. 7 1. 3 4/22/02 Cardone Defense Acceptor Connector 36

ACE Results JL advantages over frameworks: l Avoids complex interfaces l l Avoids overfeaturing l l Allows precise customization of applications Avoids Framework Evolution problem l 4/22/02 Promotes smaller, faster executables Separately evolving framework and application code Cardone Defense 37

Related Work l CLOS mixin classes use multiple inheritance [Moon, 1986; Keene, 1989] l Mixins defined as abstract subclasses [Bracha & Cook, 1990] l Useful in single inheritance languages l Mixins are reusable software components [Van. Hilst & Notkin, 1996] l Mixin Layers simplify mixin composition [Smaragdakis & Batory, 1998] l 4/22/02 Encapsulate features that crosscut multiple classes Cardone Defense 38

Conclusion l Designed/Implemented novel support for mixin programming [Cardone & Lin, ICSE 2001], [Cardone, Brown, Mc. Dirmid & Lin, AOSD 2002] l Integrated mixin support into a conventional OO language l l Implementation lessons described in thesis Demonstrated benefits of mixin programming over current techniques [Batory, Cardone & Smaragdakis, SPLC 2000] Specialized language and compiler support make mixins a practical reuse technology 4/22/02 Cardone Defense 39

Future Work l Build real-world applications using mixins l Implement a JL-to-bytecode compiler l l Implement Semantic Checking and Class Hierarchy Optimization l Explore different Java bytecode representations for mixins Explore generative programming l 4/22/02 What compile-time code transformations should be supported? Cardone Defense 40

The End www. cs. utexas. edu/users/richcar/Java. Layers. html 4/22/02 Cardone Defense 41

Semantic Checking l Undesirable compositions are often type-safe l l l Ex: Task. Queue<Task. Base>> JL’s Semantic Checking goes beyond syntactic type checking l Classes define semantic attributes l Each class hierarchy constructs an ordered attribute list l Classes test attribute lists Tests use regular expressions and a count operator l Attributes are tested for presence, absence, ordering and cardinality l Test failure aborts compilation 4/22/02 Cardone Defense 42

Semantic Checking Contributions l JL’s Semantic Checking is: l Simple l Static l Orthogonal l Expressive (so far) [Batory 97] l Designed, but not implemented 4/22/02 Cardone Defense 43

Runtime Efficiency Fact: Mixins generate deep hierarchies of small classes Question: How does this affect performance? TCP Network Protocol Stack send(){…} Secure send(){…; super. send(); } Compress send(){…; super. send(); } Log. Error send(){…; super. send(); } Keep. Alive<Log. Error<Compress<Secure<TCP>>>> 4/22/02 Cardone Defense 44

Class Hierarchy Optimization l l l Class Hierarchy Optimization l Flatten hierarchies, but preserve leaf class interface l Inline methods Simple idea, not so simple to do l Nested types l Access control Contributions l Novel optimization l Novel design (not implemented) 4/22/02 Cardone Defense 45

An Interesting Design Topic Basic Fidget Class class Base. Fidget { abstract class Component {…} class Button extends Component {…} …} Mixin Layers class Lt. Wt. Fidget<T extends Base. Fidget deeply> extends T deeply { abstract class Component extends T. Component {…} class Button extends T. Button {…} …} class Color. Fidget<T extends Base. Fidget deeply> extends T deeply { abstract class Component extends T. Component {…} class Button extends T. Button {…} …} … 11 other mixin layers 4/22/02 Cardone Defense 46

Building Fidget Libraries Color. Fidget<Lt. Wt. Fidget<Base. Fidget>> Base. Fidget Lt. Wt. Fidget Color. Fidget 4/22/02 Component Button . . . Cardone Defense 47

The Sibling Pattern Basic Fidget Class class Base. Fidget<> { abstract class Component {…} class Button extends This. Component {…} …} l The Sibling design pattern l A nested class (Button) inherits from the most-derived subclass of its sibling class (Component) l Useful semantics for mixins l In a deeply conforming mixin layer, changes to a nested class can be inherited by its sibling classes l 4/22/02 Pattern also used in Gen. Voca [Batory 98] and Jiazzi [Mc. Dirmid 01] Cardone Defense 48

Key Insights l Mixins use feature-specific interfaces to enhance usability l l Applications support only the interfaces/code they need Mixins defer parent/child relationships to enhance flexibility l 4/22/02 Could use mixins to build frameworks! Cardone Defense 49

Fidget Design Applications User Kernel Fidget Code HAL Graphic System 4/22/02 Cardone Defense 50