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

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

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

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

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

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

7. 4/22/02Cardone Defense7 Mixins as Reusable Components Mixins: types with parametrically-specified supertypes class F1 extends T {…} Prototypical JL Mixin Classes class F2 extends U {…} F2 > Stack F1_Stack F2_F1_Stack F1 Vector F1_Vector Mixins increase modularity Encapsulate feature implementations Mixins support flexible composition Parent/Child relationships are not hardcoded

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

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

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

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

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

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

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

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

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

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

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

19. 4/22/02Cardone Defense19 Previous Approaches Ad-hoc naming conventions Fixed leaf class name Configuration repositories [Czarnecki00] Maintain auxiliary data New type systems [Thorup97, Bruce97-98] Powerful, but change Java semantics and implementation

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

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

22. 4/22/02Cardone Defense22 Defining Mixin Layers class BaseFidget { class Button {…} class Checkbox {…} …} class LtWtFidget extends T { class Button extends T.Button {…} class Checkbox extends T.Checkbox {…} …} class ColorFidget extends T { class Button extends T.Button {…} class Checkbox extends T.Checkbox {…} …} Basic widget support Basic display support Color display support class BaseFidget { class Button {…} class Checkbox {…} …} class LtWtFidget extends T { class Button extends T.Button {…} class Checkbox extends T.Checkbox {…} …}

23. 4/22/02Cardone Defense23 Composing Mixin Layers ColorFidget > BaseFidget ButtonCheckBox... ColorFidget Button CheckBox... LtWtFidget ButtonCheckBox... Deep Conformance inheritance pattern for mixin layers [Smaragdakis99] Enclosing classes form a hierarchy Nested classes form hierarchies with corresponding nested classes

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

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

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

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

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

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

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

31. 4/22/02Cardone Defense31 Generating Fidget Libraries class BaseFidget { class Button {…} class Checkbox {…} …} Basic Fidget Class Optional features implemented in 13 mixin layers: Color, event handling, look and feel, … class Fidget extends EventMouse > {} class Fidget extends ColorFidget >>> {} GUI Library: Handles Mouse Events GUI Library: Handles Mouse, Keys and Color

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

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

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

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

36. 4/22/02Cardone Defense36 Re-Engineered Interfaces No. of JL Interfaces 10 Avg. JL Interface Width 1.5 1 No. of ACE Interfaces ACE Interface Width 15 Task 2734 2.41.71.3 11 5 1 665 ReactorAcceptorConnector 13 1.51.8 11 2024 TimerQueue

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

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

39. 4/22/02Cardone Defense39 Conclusion Designed/Implemented novel support for mixin programming [Cardone & Lin, ICSE 2001], [Cardone, Brown, McDirmid & Lin, AOSD 2002] Integrated mixin support into a conventional OO language 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

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

41. 4/22/02Cardone Defense41 The End www.cs.utexas.edu/users/richcar/JavaLayers.html

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

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

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

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

46. 4/22/02Cardone Defense46 An Interesting Design Topic class BaseFidget { abstract class Component {…} class Button extends Component {…} …} Basic Fidget Class Mixin Layers class LtWtFidget extends T deeply { abstract class Component extends T.Component {…} class Button extends T.Button {…} …} class ColorFidget extends T deeply { abstract class Component extends T.Component {…} class Button extends T.Button {…} …} … 11 other mixin layers class BaseFidget { abstract class Component {…} class Button extends Component {…} …} class LtWtFidget extends T deeply { abstract class Component extends T.Component {…} class Button extends T.Button {…} …}

47. 4/22/02Cardone Defense47 Building Fidget Libraries ColorFidget > BaseFidget Component Button... ColorFidget Component Button... LtWtFidget Component Button...

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

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

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