View
219
Download
0
Category
Preview:
DESCRIPTION
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
Citation preview
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
4/22/02 Cardone Defense 3
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
4/22/02 Cardone Defense 4
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
4/22/02 Cardone Defense 5
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
4/22/02 Cardone Defense 6
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
4/22/02 Cardone Defense 7
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
4/22/02 Cardone Defense 8
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
4/22/02 Cardone Defense 9
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
4/22/02 Cardone Defense 10
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
4/22/02 Cardone Defense 11
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
4/22/02 Cardone Defense 12
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
class ParentA {ParentA(){…} …}class ParentB {ParentB(String s){…} …}class M<T> extends T {M(int i){x = i;…} …}
Classes
class ParentA {ParentA(){…} …}class ParentB {ParentB(String s){…} …}class M<T> extends T {M(int i){x = i;…} …}
Classes
class ParentA {ParentA(){…} …}class ParentB {ParentB(String s){…} …}class M<T> extends T {M(int i){x = i;…} …}
4/22/02 Cardone Defense 13
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
4/22/02 Cardone Defense 14
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;…} …}
class M_ParentB extends ParentB {
M_ParentB(int i, String s) {super(s); x = i;…} …}
class M_ParentB extends ParentB {
M_ParentB(int i, String s) {super(s); x = i;…} …}
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
4/22/02 Cardone Defense 15
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 {…}
4/22/02 Cardone Defense 16
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 {…}
4/22/02 Cardone Defense 17
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
4/22/02 Cardone Defense 18
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
4/22/02 Cardone Defense 19
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
4/22/02 Cardone Defense 20
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
4/22/02 Cardone Defense 21
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
4/22/02 Cardone Defense 22
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 {…} …}
4/22/02 Cardone Defense 23
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
4/22/02 Cardone Defense 24
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
4/22/02 Cardone Defense 25
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
4/22/02 Cardone Defense 26
The Big Picture
Java Layers =Java + Constrained Parametric Polymorphism
+ Constructor Propagation
+ Implicit This Type Parameter
+ Deep Conformance
+ Semantic Checking
+ Class Hierarchy OptimizationDesign only
4/22/02 Cardone Defense 27
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
4/22/02 Cardone Defense 28
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?
4/22/02 Cardone Defense 29
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
4/22/02 Cardone Defense 30
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
4/22/02 Cardone Defense 31
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
4/22/02 Cardone Defense 32
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
4/22/02 Cardone Defense 33
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
4/22/02 Cardone Defense 34
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
4/22/02 Cardone Defense 35
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
4/22/02 Cardone Defense 36
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
4/22/02 Cardone Defense 37
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:
4/22/02 Cardone Defense 38
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]
4/22/02 Cardone Defense 39
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
4/22/02 Cardone Defense 40
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
4/22/02 Cardone Defense 42
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
4/22/02 Cardone Defense 43
Semantic Checking Contributions
JL’s Semantic Checking is:
Simple
Static
Orthogonal
Expressive (so far) [Batory97]
Designed, but not implemented
4/22/02 Cardone Defense 44
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(){…; super.send();}
send(){…; super.send();}
send(){…}
Network Protocol Stack
4/22/02 Cardone Defense 45
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)
4/22/02 Cardone Defense 46
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 {…} …}
4/22/02 Cardone Defense 47
Building Fidget LibrariesColorFidget<LtWtFidget<BaseFidget>>
BaseFidget Component Button ...
ColorFidget Component Button ...
LtWtFidget Component Button ...
4/22/02 Cardone Defense 48
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]
4/22/02 Cardone Defense 49
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!
4/22/02 Cardone Defense 50
Fidget DesignApplications
User
Kernel
HAL
Graphic System
Fidget Code
Recommended