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

Language and Compiler Support for Mixin Programming

Richard CardoneCalvin Lin, Advisor

Department of Computer SciencesUniversity of Texas at Austin

April 22, 2002

4/22/02 Cardone Defense 2

The Problem

Large applications are difficult and expensive to build!

Variation over time

Variation in execution environments


Variation over Time

feature 1

feature 2feature 3feature 4feature 5

Scattered feature code

Tangled feature code

Class Hierarchy

Scattered/Tangled code:hard to understand, maintain, and reuse


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


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


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


Mixins as Reusable ComponentsMixins: types with parametrically-specified supertypes

class F1<T> extends T {…}

Prototypical JL Mixin Classes

class F2<U> extends U {…}

F2<F1<Stack>>Stack

F1_Stack

F2_F1_Stack

F1<Vector>

Vector

F1_Vector

Mixins increase modularity Encapsulate feature implementations

Mixins support flexible composition Parent/Child relationships are not hardcoded


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


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


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


Overview Mixin Background

Contributions

Support for Mixin Programming Addressing complexity Increasing expressiveness





Mixin InitializationProblem: Mixin initialization is tricky because superclass is not known

Classes

class ParentA {ParentA(){…} …}class ParentB {ParentB(String s){…} …}class M<T> extends T {M(int i){x = i;…} …}

Instantiations

M<ParentA> // OKM<ParentB> // ERROR!

Superclass no-argument constructor implicitly called

Classes


Classes


Classes



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


Constructor PropagationJL Solution: Automatically add constructor arguments

Redefined Classesclass ParentB {propagate ParentB(String s){…} …}class M<T> extends T {propagate M(int i){x = i;…} …}

M<ParentB>

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


Restricting CompositionProblem: Mixins can be composed in arbitrary ways

Constrained Type Parameter Exampleclass TaskBase implements TaskIfc {…}class TaskQueue<T implements TaskIfc> extends T {…}

InstantiationsTaskQueue<TaskBase> // OKTaskQueue<Hashtable> // ERROR!

Common Solution: Use type parameter constraints to prohibit invalid or undesirable compositions

But What About:TaskQueue<TaskQueue<TaskBase>> // Type-safe, but…

Constrained Type Parameter Exampleclass TaskBase implements TaskIfc {…}class TaskQueue<T implements TaskIfc> extends T {…}


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<T implements TaskIfc> extends T requires unique {…}



Contributions







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> { T data; SNode<T> next;}

class DNode<T> extends T { DNode<T> prev;}

Linked List Example DNode<SNode<int>>

DNode_SNode_int

DNode_SNode_int prev;

SNode_int

SNode_int next;

We want next and prev to be type DNode_SNode_int


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


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> { T data; This next;}

class DNode<T> extends T { This prev;}

Linked List Example SNode<int>

DNode_SNode_int

DNode_SNode_int prev;

SNode_int

SNode_int next;

DNode<SNode<int>>

DNode_SNode_int next;

Provides a static way to reference most-derived class Easy to use


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


Defining Mixin Layersclass BaseFidget { class Button {…} class Checkbox {…} …}

class LtWtFidget<T> extends T { class Button extends T.Button {…} class Checkbox extends T.Checkbox {…} …}

class ColorFidget<T> 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<T> extends T { class Button extends T.Button {…} class Checkbox extends T.Checkbox {…} …}


Composing Mixin LayersColorFidget<LtWtFidget<BaseFidget>>

BaseFidget Button CheckBox ...

ColorFidget Button CheckBox ...

LtWtFidget Button CheckBox ...

Deep Conformance inheritance pattern for mixin layers [Smaragdakis99]

Enclosing classes form a hierarchy Nested classes form hierarchies with corresponding nested classes


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


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<T extends BaseFidget deeply>

extends T deeply {class Button extends T.Button {…} class Checkbox extends T.Checkbox {…} …}

T conforms to BaseFidget

ColorFidget conforms to its superclass

class ColorFidget<T extends BaseFidget deeply>

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


The Big Picture

Java Layers =Java + Constrained Parametric Polymorphism

+ Constructor Propagation

+ Implicit This Type Parameter

+ Deep Conformance

+ Semantic Checking

+ Class Hierarchy OptimizationDesign only



Contributions







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?


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


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


Generating Fidget Libraries

class BaseFidget { class Button {…} class Checkbox {…} …}

Basic Fidget ClassOptional features implemented in 13 mixin layers: Color, event handling, look and feel, …

class Fidget extends EventMouse<LtWtFidget<BaseFidget>> {}

class Fidget extends ColorFidget<EventKey<EventMouse<LtWtFidget<BaseFidget>>>> {}

GUI Library: Handles Mouse Events

GUI Library: Handles Mouse, Keys and Color


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


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


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


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


Re-Engineered Interfaces

No. of JL Interfaces 10

Avg. JL Interface Width

1.5

1

No. of ACE Interfaces

ACE Interface Width

15

Task

27 3 4

2.4 1.7 1.3

11

5

1

66 5

Reactor Acceptor Connector

13 13

1.5 1.8

11

20 24

Timer Queue


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:


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]

CLOS mixin classes use multiple inheritance[Moon, 1986; Keene, 1989]


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


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?

41Cardone Defense4/22/02

The End

www.cs.utexas.edu/users/richcar/JavaLayers.html


Semantic Checking Undesirable compositions are often type-safe

Ex: TaskQueue<TaskQueue<TaskBase>>

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


Semantic Checking Contributions

JL’s Semantic Checking is:

Simple

Static

Orthogonal

Expressive (so far) [Batory97]

Designed, but not implemented


Runtime EfficiencyFact: Mixins generate deep hierarchies of small classesQuestion: How does this affect performance?

KeepAlive<LogError<Compress<Secure<TCP>>>>

TCP

Secure

Compress

LogError

KeepAlive send(){…; super.send();}

send(){…; super.send();}



send(){…}

Network Protocol Stack


Class Hierarchy Optimization 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)


An Interesting Design Topic

class BaseFidget { abstract class Component {…} class Button extends Component {…} …}

Basic Fidget Class

Mixin Layersclass LtWtFidget<T extends BaseFidget deeply> extends T deeply { abstract class Component extends T.Component {…} class Button extends T.Button {…} …}

class ColorFidget<T extends BaseFidget deeply> 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<T extends BaseFidget deeply> extends T deeply { abstract class Component extends T.Component {…} class Button extends T.Button {…} …}


Building Fidget LibrariesColorFidget<LtWtFidget<BaseFidget>>

BaseFidget Component Button ...

ColorFidget Component Button ...

LtWtFidget Component Button ...


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]


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!


Fidget DesignApplications

User

Kernel

HAL

Graphic System

Fidget Code

Documents

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