Java Layers Language Support for Layered Refinement Rich

Java Layers Language Support for Layered Refinement Rich Cardone Calvin Lin, Advisor Department of Computer Sciences University of Texas at Austin January 16, 2001 1/16/01 Java Layers Proposal

In a Nutshell n Goal: Application assembly from reusable parts n Our Solution: Java Layers (JL) n n Increase code reuse n Novel language features Results: A practical way to construct applications 1/16/01 n Simple n Effective n Evolutionary Java Layers Proposal 2

Presentation Overview n Motivation n Background n Mixins n Java Layers n Methodology n Related Work 1/16/01 Java Layers Proposal 3

Problem n n Software development and maintenance is expensive n Difficult n Takes a long time Assemble applications from off-the-shelf components n Mix and match features to create applications n Plug and unplug components to change applications 1/16/01 Java Layers Proposal 4

Reusable Components n Separation of concerns n n One application feature per component Flexible composition 1/16/01 Java Layers Proposal 5

Our Solution Provide language support for reuse: n Software components n n Encapsulate feature implementations Stepwise Program Refinement n 1/16/01 Build applications incrementally in layers Java Layers Proposal 6

Contributions 1) Feature identification n 2) Feature implementation n 3) Show features can be integrated into an OO language Language evaluation n 4) Identify essential features for domain-independent, stepwise refinement Demonstrate advantages in building large applications Domain-independence evaluation n Compare to domain-specific implementations of stepwise refinement 1/16/01 Java Layers Proposal 7

Background n Let’s look at a problem in object-oriented programming. 1/16/01 Java Layers Proposal 8

An OO Problem Car Box House Lockable Car Lockable Box Lockable House lock(), unlock() Problem: Lockable code replicated 3 times 1/16/01 Java Layers Proposal 9

An OO Solution n Use same lockable code for all 3 classes n n Encapsulate lockable code in a class Subtype Car, Box, House with new class Mixin Class class Lockable<T> extends T { lock(){…} unlock(){…} } [Bracha 90] 1/16/01 Java Layers Proposal 10

Mixed-In Classes <T> Car Box House Lockable<T> Lockable<Car> Lockable<Box> Lockable<House> Lockable code reused 3 times 1/16/01 Java Layers Proposal 11

Mixins n Types with parameterized supertypes n Depend on type parameters n More precisely: Parametric Polymorphism n An OO mechanism for code reuse n Apply same code to unrelated classes n Work with single inheritance 1/16/01 Java Layers Proposal 12

Example: Music Server n Variation can occur on many axes: n Client interface {get. Song, erase. Copyright, hide. Britney, …} n Server execution strategy {single threaded, thread-spawning, thread pool, …} 1/16/01 n Transport type n Fault tolerance n Server discovery n … Java Layers Proposal 13

Music Application Instances Simple No. Britney Base Get. Song Erase. Copyright Hide. Britney Get. Song leaf-types Thief … Thread. Spawn 1/16/01 Java Layers Proposal 14

Application Assembly is Easy class Simple extends Get. Song<Base> {…} class No. Britney extends Hide. Britney<Get. Song<Base>> {…} class Thief extends Thread. Spawn<Get. Song<Erase. Copyright< Base>>> {…} 1/16/01 Java Layers Proposal 15

Mixins as Reusable Components n n Van. Hilst & Notkin, 1996 n C++ mixins encapsulate changes to individual classes n Composed OO collaborations using multiple mixins n Built applications by combining multiple collaborations Batory & Smaragdakis, 1998 -present n Mixin Layers can encapsulate complete collaborations n Mixin Layers are mixins that contain nested mixins Mixins can encapsulate all features in our example 1/16/01 Java Layers Proposal 16

Stepwise Program Refinement class Thief extends Thread. Spawn<Get. Song<Erase. Copyright<Base>>> {…} Client Server Layers Base Erase. Copyright Get. Song Thread. Spawn [Batory 92] 1/16/01 Java Layers Proposal 17

The Good News n Mixins enhance OO code reuse n n Each class encapsulates one feature Mixins build applications incrementally n 1/16/01 Add features one at a time Java Layers Proposal 18

The Bad News Mixins can have usability & efficiency drawbacks That’s why Java Layers exists! n Implements mixins n Addresses mixin drawbacks 1/16/01 Java Layers Proposal 19

Java Layers Overview n Introduce JL’s technology base n Introduce 5 novel JL features n Describe mixin problem n Present JL solution All JL features are designed to support stepwise program refinement 1/16/01 Java Layers Proposal 20

JL’s Foundation n Java + Constrained Parametric Polymorphism (CPP) n There are several proposals for adding CPP to Java [Agesen 97, Bokowski 98, Bracha 98, Cartwright 98, Myers 97, Solorzano 98] n JL’s implementation of CPP n Conventional syntax and semantics n Parametric classes and interfaces n Mixins 1/16/01 Java Layers Proposal 21

P 1: Superclass Initialization n Superclass initialization is tricky with mixins Class Constructor House Car Lockable<House> Lockable<Car> 1/16/01 House(Address) Car(Make, Model) ? ? Java Layers Proposal 22

S 1: Constructor Propagation n n Automatic constructor generation n Generates constructors based on superclass n Adjusts constructor signatures Contribution: Flexible mixin initialization n Mixin constructors generated at instantiation time n Superclasses get their initialization parameters 1/16/01 Java Layers Proposal 23

P 2: Permissive Type Checking interface I { interface Inner {…} } class C implements I {…} n Question: Does C implement nested interface Inner? Answer: Maybe Classes are not required to implement nested interfaces 1/16/01 Java Layers Proposal 24

S 2: Deep Conformance n n Enhances Java’s type checking for nested types n Supertypes can be checked for required nested types n Classes implement interfaces at all nesting depths n Promotes mixin composition Contribution: Client-centric semantics n Users of types decide on deep or shallow type checking n More flexible than producer-centric approaches [Smaragdakis 99] 1/16/01 Java Layers Proposal 25

P 3: Referencing Leaf-Types n No way to express leaf-types within mixins n n Runtime object’s precise type cannot be used Possible in non-parameterized inheritance 1/16/01 Java Layers Proposal 26

S 3: Static Virtual Typing n n The automatic adaptation of types through inheritance n A virtual type in a parent class can change when subclassed n Specialized types automatically replace more general types n Mixins can express leaf-types in generated hierarchies Contribution: Static binding of virtual types n No increase in dynamic type checking n No change in Java’s type system n Dynamic approaches are more expressive [Bruce 98, Thorup 97] 1/16/01 Java Layers Proposal 27

P 4: Composition Correctness n Syntactically correct mixin compositions can yield semantically meaningless results 1/16/01 n Mixins are too flexible! n Ex: Hide. Britney<Base>> ? Java Layers Proposal 28

S 4: Semantic Checking n Restrict inheritance with semantic constraints n Manually disallow syntactically correct but semantically invalid mixin instantiations n Contribution: Use of pattern-matched constraints n Regular expression matching and a count operator n Familiar, simple, limited scope n Sufficient expressive power (so far) [Batory 96, Perry 89] 1/16/01 Java Layers Proposal 29

P 5: Performance n Increased load times n n Deep class hierarchies of many small classes Increased method calls n Feature code executes, then passes control on n Mixin method calls same method in superclass n Less efficient than conventional, unlayered code 1/16/01 Java Layers Proposal 30

S 5: Class Hierarchy Optimization n n Class hierarchy optimization n Inline calls to superclass methods w/same signature n Collapse class hierarchy into a single class Contribution: Generate efficient mixin code n Remove design-time layering from runtime code n Extends existing compiler optimization techniques 1/16/01 Java Layers Proposal 31

Java Layers Anatomy Java Layers = Java + Constrained Parametric Polymorphism + Constructor Propagation + Deep Conformance + Static Virtual Typing + Semantic Checking + Class Hierarchy Optimization 1/16/01 Java Layers Proposal 32

Methodology Design Evaluate Develop n Validate our analyses n Make implementations available to others n 2 design-develop-evaluate cycles planned 1/16/01 Java Layers Proposal 33

Cycle 1 (completed) n Performed initial analysis n Implemented JL prototype n Compared JL to OO Frameworks n Reengineered Schmidt’s ACE n ICSE 2001 paper 1/16/01 Java Layers Proposal 34

ICSE Paper Results JL advantages over frameworks: n Avoids overfeaturing n n Avoids complex interfaces n n Allows precise customization of applications Promotes smaller, faster executables Avoids the Framework Evolution problem 1/16/01 Java Layers Proposal 35

Cycle 2 (in progress) n Refined JL Language n Develop new JL compiler n Apply and evaluate refined language n Build a family of related applications n Compare to Domain-Specific Languages 1/16/01 Java Layers Proposal 36

Related Work n Gen. Voca – Batory 92 -00, Smaragdakis 98 -99 n Parametric Polymorphism – Agesen 97, Bokowski 98, Bracha 90, Bracha 98, Cartwright 98, Myers 97, Solorzano 98 n Virtual Types – Bruce 97 -98, Madsen 89, Thorup 97, Thorup 99, Torgerson 98 n Semantic Checking – Batory 95, Perry 89 -93 n Programming Paradigms – Danforth 98, Gamma 94, Harrison 93, Johnson 91, Kiczales 97, Schmidt 98, Tarr 99 1/16/01 Java Layers Proposal 37

JL and Gen. Voca n JL’s based on the Gen. Voca model n JL refines the Gen. Voca model n n Specifies layer initialization n Integrates semantic checking JL has novel language & compiler support 1/16/01 Java Layers Proposal 38

Summary n JL promotes an alternative programming methodology n Reduce development costs through reuse n Bring mixins into mainstream programming n Contributions: identification, integration and evaluation n Methodology: emphasize the practical 1/16/01 Java Layers Proposal 39

THE END Think Layers 1/16/01 Java Layers Proposal 40

Base Class class Base { static public class Client {…} static public class Server { void dispatch. Loop(){for(; ; ) dispatch(read. Request()); } void dispatch(Req req){error. Unknown. Req(req); } … } } 1/16/01 Java Layers Proposal 41

Get. Song Mixin constraint nested mixins class Get. Song<T extends Base> extends T { static public class Client extends T. Client { void get. Song(…){…} } static public class Server extends T. Server { void dispatch(Req req){ if (req. name. equals(“get. Song”)) process. Get. Song(req); else super. dispatch(req); } … } } 1/16/01 [Smaragdakis 98] Java Layers Proposal 42

Other Mixins class Erase. Copyright<T extends Base> extends T { static public class Client extends T. Client { void erase. Copyright(…){…} } … } class Thread. Spawn<T extends Base> extends T { static public class Server extends T. Server { void dispatch. Loop(){…} } … } 1/16/01 Java Layers Proposal 43

The Need for Deep Conformance Question: class Parent { class Inner {…} } Does Child contain a nested class named Inner? class Child extends Parent {…} n Java supports shallow type checking n n Answer: Maybe Interfaces and classes JL adds support for deep type checking n 1/16/01 Supertypes are checked for required nested types Java Layers Proposal 44

Deep Conformance n Deep Conformance supports stepwise refinement n Enforces structural conformance at all nesting depths n Subtypes can safely refer to nested types in their supertypes n Feature composition is enhanced by added type precision 1/16/01 Java Layers Proposal 45

Deep Conformance Example class Hide. Britney<T extends Base deeply> extends deeply T { static public class Client extends T. Client {…} static public class Server extends T. Server {…} } n Type parameter T binds to classes that: n n Extend Base Contain a nested Client class that extends Base. Client Contain a nested Server class that extends Base. Server Hide. Britney contains all the public nested types of T n 1/16/01 Compiler generates missing nested types if necessary Java Layers Proposal 46

Deep Conformance Syntax n n Deeply modifier for implements and extends clauses n Different meaning in constraint and inheritance clauses n Operates on public nested types by default Propagate modifier for non-public nested types n n Enables selective deep type checking Use in parameterized and non-parameterized types 1/16/01 Java Layers Proposal 47

A Use of Virtual Types class Node {Node next; } class Node {virtual Node; Node next; } class Double. Node extends Node {Double. Node prev; } class Double. Node extends Node {typedef Node as Double. Node; Double. Node prev; } n In Double. Node: n next is type Node n next is type Double. Node n prev is type Double. Node [Thorup 97] 1/16/01 Java Layers Proposal 48

Virtual Types n n The automatic adaptation of types through inheritance. n Virtual types change through subtyping n A child class can change the type of its parent Benefits of Virtual Typing n Greater type precision n Better type checking n Less manual typecasting n Genericity (Beta) 1/16/01 Java Layers Proposal 49

JL’s This Virtual Type n This pseudo-type is like the “type of this. ” n Static binding n n Used in parametric types only n Bound at instantiation time Enhances JL’s expressiveness n 1/16/01 Allows the instantiated leaf-type to be expressed within the mixins being composed to define that leaf-type. Java Layers Proposal 50

Hypothesis Stepwise program refinement can: 1) be supported by a small number of domain -independent language features, and 2) provide an effective way to build large applications 1/16/01 Java Layers Proposal 51

Flexible Class Hierarchies Replaced class Inserted class Flexible Rigid classhierarchy 1/16/01 Java Layers Proposal 52

Evaluation n n Evaluate JL vs. standard OO development n Build a family of related applications n Compare flexibility, usability and reusability Evaluate domain-independence n Compare to Domain-Specific Languages n Analyze tradeoffs of each approach 1/16/01 Java Layers Proposal 53

Gen. Voca Implementations n n n JL introduces no new type constructs JL enhances mixin usability JL is domain-independent Average Programming Dude GPL Specialist Assembled Applications Domain Expert / Programmer DSL Bring stepwise refinement to mainstream programming 1/16/01 Java Layers Proposal 54