Download here - Department of Computer Science

Java Layers
Language Support for Layered
Refinement
Rich Cardone
Calvin Lin, Advisor
Department of Computer Sciences
University of Texas at Austin
January 16, 2001
In a Nutshell

Goal: Application assembly from reusable parts

Our Solution: Java Layers (JL)


Increase code reuse

Novel language features
Results: A practical way to construct applications
1/16/01

Simple

Effective

Evolutionary
Java Layers Proposal
2
Presentation Overview

Motivation

Background

Mixins

Java Layers

Methodology

Related Work
1/16/01
Java Layers Proposal
3
Problem


Software development and maintenance is expensive

Difficult

Takes a long time
Assemble applications from off-the-shelf components

Mix and match features to create applications

Plug and unplug components to change applications
1/16/01
Java Layers Proposal
4
Reusable Components

Separation of concerns


One application feature per component
Flexible composition
1/16/01
Java Layers Proposal
5
Our Solution
Provide language support for reuse:

Software components


Encapsulate feature implementations
Stepwise Program Refinement

1/16/01
Build applications incrementally in layers
Java Layers Proposal
6
Contributions
1)
Feature identification

2)
Feature implementation

3)
Show how features can be integrated into an OO language
Language evaluation

4)
Identify essential features for domain-independent, stepwise refinement
Demonstrate advantages in building large applications
Domain-independence evaluation

Compare to domain-specific implementations of stepwise refinement
1/16/01
Java Layers Proposal
7
Background

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

Use same lockable code for all 3 classes


Encapsulate lockable code in a class
Subtype Car, Box, House with new class
Mixin Class
class Lockable<T> extends T {
lock(){…}
unlock(){…}
}
[Bracha90]
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

Types with parameterized supertypes

Depend on type parameters

More precisely: Parametric Polymorphism

An OO mechanism for code reuse

Apply same code to unrelated classes

Work with single inheritance
1/16/01
Java Layers Proposal
12
Example: Music Server

Variation can occur on many axes:

Client interface
{getSong, eraseCopyright, hideBritney, …}

Server execution strategy
{single threaded, thread-spawning, thread pool, …}
1/16/01

Transport type

Fault tolerance

Server discovery

…
Java Layers Proposal
13
Music Application Instances
Simple
NoBritney
Base
Base
Base
GetSong
GetSong
EraseCopyright
HideBritney
GetSong
leaf-types
Thief
…
ThreadSpawn
1/16/01
Java Layers Proposal
14
Application Assembly is Easy
class Simple extends
GetSong<Base> {…}
class NoBritney extends
HideBritney<GetSong<Base>> {…}
class Thief extends
ThreadSpawn<GetSong<EraseCopyright<
Base>>> {…}
1/16/01
Java Layers Proposal
15
Mixins as Reusable Components


VanHilst & Notkin, 1996

C++ mixins encapsulate changes to individual classes

Composed OO collaborations using multiple mixins

Built applications by combining multiple collaborations
Batory & Smaragdakis, 1998-present

Mixin Layers can encapsulate complete collaborations

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
ThreadSpawn<GetSong<EraseCopyright<Base>>> {…}
Client
Server
Layers
Base
EraseCopyright
GetSong
ThreadSpawn
[Batory92]
1/16/01
Java Layers Proposal
17
The Good News

Mixins enhance OO code reuse


Each class encapsulates one feature
Mixins build applications incrementally

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!

Implements mixins

Addresses mixin drawbacks
1/16/01
Java Layers Proposal
19
Java Layers Overview

Introduce JL’s technology base

Introduce 5 novel JL features

Describe mixin problem

Present JL solution
All JL features are designed to support stepwise
program refinement
1/16/01
Java Layers Proposal
20
JL’s Foundation

Java + Constrained Parametric Polymorphism (CPP)

There are several proposals for adding CPP to Java
[Agesen97, Bokowski98, Bracha98, Cartwright98, Myers97, Solorzano98]

JL’s implementation of CPP

Conventional syntax and semantics

Parametric classes and interfaces

Mixins
1/16/01
Java Layers Proposal
21
P1: Superclass Initialization

Superclass initialization is tricky with mixins
Class
Constructor
House
Car
Lockable<House>
House(Address)
Car(Make, Model)
?
Lockable<Car>
1/16/01
?
Java Layers Proposal
22
S1: Constructor Propagation


Automatic constructor generation

Generates constructors based on superclass

Adjusts constructor signatures
Contribution: Flexible mixin initialization

Mixin constructors generated at instantiation time

Superclasses get their initialization parameters
1/16/01
Java Layers Proposal
23
P2: Permissive Type Checking
interface I {
interface Inner {…}
}
class C implements I
{…}

Question:
Does C implement nested
interface Inner?
Answer: Maybe
Classes are not required to implement
nested interfaces
1/16/01
Java Layers Proposal
24
S2: Deep Conformance


Enhances Java’s type checking for nested types

Supertypes can be checked for required nested types

Classes implement interfaces at all nesting depths

Promotes mixin composition
Contribution: Client-centric semantics

Users of types decide on deep or shallow type checking

More flexible than producer-centric approaches
[Smaragdakis99]
1/16/01
Java Layers Proposal
25
P3: Referencing Leaf-Types

No way to express leaf-types within mixins


Runtime object’s precise type cannot be used
Possible in non-parameterized inheritance
1/16/01
Java Layers Proposal
26
S3: Static Virtual Typing


The automatic adaptation of types through inheritance

A virtual type in a parent class can change when subclassed

Specialized types automatically replace more general types

Mixins can express leaf-types in generated hierarchies
Contribution: Static binding of virtual types

No increase in dynamic type checking

No change in Java’s type system

Dynamic approaches are more expressive
[Bruce98, Thorup97]
1/16/01
Java Layers Proposal
27
P4: Composition Correctness

Syntactically correct mixin compositions can
yield semantically meaningless results
1/16/01

Mixins are too flexible!

Ex: HideBritney<HideBritney<Base>> ?
Java Layers Proposal
28
S4: Semantic Checking

Restrict inheritance with semantic constraints

Manually disallow syntactically correct but semantically invalid
mixin instantiations

Contribution: Use of pattern-matched constraints

Regular expression matching and a count operator

Familiar, simple, limited scope

Sufficient expressive power (so far)
[Batory96, Perry89]
1/16/01
Java Layers Proposal
29
P5: Performance

Increased load times


Deep class hierarchies of many small classes
Increased method calls

Feature code executes, then passes control on

Mixin method calls same method in superclass

Less efficient than conventional, unlayered code
1/16/01
Java Layers Proposal
30
S5: Class Hierarchy Optimization


Class hierarchy optimization

Inline calls to superclass methods w/same signature

Collapse class hierarchy into a single class
Contribution: Generate efficient mixin code

Remove design-time layering from runtime code

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

Validate our analyses

Make implementations available to others

2 design-develop-evaluate cycles planned
1/16/01
Java Layers Proposal
33
Cycle 1 (completed)

Performed initial analysis

Implemented JL prototype

Compared JL to OO Frameworks

Reengineered Schmidt’s ACE

ICSE 2001 paper
1/16/01
Java Layers Proposal
34
ICSE Paper Results
JL advantages over frameworks:

Avoids overfeaturing


Avoids complex interfaces


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)

Refined JL Language

Develop new JL compiler

Apply and evaluate refined language

Build a family of related applications

Compare to Domain-Specific Languages
1/16/01
Java Layers Proposal
36
Related Work

GenVoca – Batory92-00, Smaragdakis98-99

Parametric Polymorphism – Agesen97, Bokowski98,
Bracha90, Bracha98, Cartwright98, Myers97, Solorzano98

Virtual Types – Bruce97-98, Madsen89, Thorup97,
Thorup99, Torgerson98

Semantic Checking – Batory95, Perry89-93

Programming Paradigms – Danforth98, Gamma94,
Harrison93, Johnson91, Kiczales97, Schmidt98, Tarr99
1/16/01
Java Layers Proposal
37
JL and GenVoca

JL’s based on the GenVoca model

JL refines the GenVoca model


Specifies layer initialization

Integrates semantic checking
JL has novel language & compiler support
1/16/01
Java Layers Proposal
38
Summary

JL promotes an alternative programming methodology

Reduce development costs through reuse

Bring mixins into mainstream programming

Contributions: identification, integration and evaluation

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 dispatchLoop(){for(;;) dispatch(readRequest());}
void dispatch(Req req){errorUnknownReq(req);}
…
}
}
1/16/01
Java Layers Proposal
41
GetSong Mixin
constraint
nested mixins
class GetSong<T extends Base> extends T {
static public class Client extends T.Client {
void getSong(…){…} }
static public class Server extends T.Server {
void dispatch(Req req){
if (req.name.equals(“getSong”)) processGetSong(req);
else super.dispatch(req);
}
…
}
}
1/16/01
[Smaragdakis98]
Java Layers Proposal
42
Other Mixins
class EraseCopyright<T extends Base> extends T {
static public class Client extends T.Client {
void eraseCopyright(…){…}
} …
}
class ThreadSpawn<T extends Base> extends T {
static public class Server extends T.Server {
void dispatchLoop(){…}
} …
}
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 {…}

Java supports shallow type checking


Answer: Maybe
Interfaces and classes
JL adds support for deep type checking

1/16/01
Supertypes are checked for required nested types
Java Layers Proposal
44
Deep Conformance

Deep Conformance supports stepwise refinement

Enforces structural conformance at all nesting depths

Subtypes can safely refer to nested types in their supertypes

Feature composition is enhanced by added type precision
1/16/01
Java Layers Proposal
45
Deep Conformance Example
class HideBritney<T extends Base deeply> extends deeply T {
static public class Client extends T.Client {…}
static public class Server extends T.Server {…} }

Type parameter T binds to classes that:




Extend Base
Contain a nested Client class that extends Base.Client
Contain a nested Server class that extends Base.Server
HideBritney contains all the public nested types of T

1/16/01
Compiler generates missing nested types if necessary
Java Layers Proposal
46
Deep Conformance Syntax


Deeply modifier for implements and extends clauses

Different meaning in constraint and inheritance clauses

Operates on public nested types by default
Propagate modifier for non-public nested types


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 DoubleNode
extends Node
{DoubleNode prev;}
class DoubleNode extends Node
{typedef Node as DoubleNode;
DoubleNode prev;}

In DoubleNode:

In DoubleNode:

next is type Node

next is type DoubleNode

prev is type DoubleNode

prev is type DoubleNode
[Thorup97]
1/16/01
Java Layers Proposal
48
Virtual Types


The automatic adaptation of types through inheritance.

Virtual types change through subtyping

A child class can change the type of its parent
Benefits of Virtual Typing

Greater type precision

Better type checking

Less manual typecasting

Genericity (Beta)
1/16/01
Java Layers Proposal
49
JL’s This Virtual Type

This pseudo-type is like the “type of this.”

Static binding


Used in parametric types only

Bound at instantiation time
Enhances JL’s expressiveness

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 class
classhierarchy
hierarchy
1/16/01
Java Layers Proposal
52
Evaluation


Evaluate JL vs. standard OO development

Build a family of related applications

Compare flexibility, usability and reusability
Evaluate domain-independence

Compare to Domain-Specific Languages

Analyze tradeoffs of each approach
1/16/01
Java Layers Proposal
53
GenVoca Implementations



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