A Case For. Binary Component Adaptation. Motivation. The Integration Problem. Talk Outline. Using Wrapper Classes. The Interface Evolution Problem

Transcription

1 Case For inary Modifying s On The Fly Urs Hölzle and Ralph Keller Department of Computer Science University of California, Santa arbara Motivation OOP vision: Pervasive component reuse Large-scale component market Programs are built mostly of existing components Unfortunately: Combining independently developed components is hard inary makes integration easier! inary 2 inary The Integration Problem oth components provide functionality for printing Goal: Integrate and in list: ut: Interface mismatch No common supertype class desired type hierarchy inary 3 inary 4 Using Wrapper Classes interface Wrapper output() implements Wrapper Disadvantages: dditional programming effort Overhead (wrapping and unwrapping) Redundant type hierarchy Difficult subtyping problems [Hölzle, ECOOP 93] The Interface Problem Enumeration interface 1 lastelement implements Enumeration List Set HashTable... 2 lastelement 2 lastelement 2 lastelement inary 5 inary 6 1

2 Interface Problem Interface change must be reflected immediately by all classes Default implementation for each class: Object lastelement() { Object o = null; while (()) o = (); return o; ut: Generally: no source code Open set of classes (dynamic linking) Problem Summary Minor incompatibilities prevent pervasive reuse Each re-user may have different requirements Source code modifications are not practical not available needs recompile before executing need to keep track of different compiled versions tracking new releases is tedious inary 7 inary 8 What We Want Easy-to-use, flexible adaptation mechanism No source code required In place changes of type (no wrappers) utomatic integration with future releases Motivation: Problems with component-based programming inary inary 9 inary 10 pplication Specification compiler C Overview End User Class loader Modifying s On The Fly class: super: Object 2 implements: 1 Loader : add 1 2 implements : implements Interpreter JIT Runtime System Interpreter/ JIT print print inary 11 inary 12 2

3 inary Directly modifies component Uses type information in compiled component Requires no source code Works even on third-party components Keeps changes separately from components No changed components delivered to client Performs component modification during class loading for Integration Problem delta { 1 add method void { output(system.out); 2 add implements ; delta class { 3 add implements ; interface implements class 2 implements 3 implements 1 inary 13 inary 14 for Problem delta interface Enumeration { 1 add method Object lastelement(); delta implements Enumeration { 2 add method Object lastelement() { while(() Enumeration 1 lastelement inary implements Enumeration List Set HashTable 2 lastelement 2 lastelement 2 lastelement inary 15 inary 16 What Modifications re Possible? Limited by amount of symbolic information For Java: can change almost everything dd fields, methods dd implemented interfaces Delete fields, methods Rewrite byte codes ut: inary compatibility must be preserved inary Compatibility Goal: is valid on any future release of pplication () ( ) inary 17 inary 18 3

4 inary Compatible Modifications Very flexible even with binary compatibility restriction: dd fields & methods Rename classes, fields & methods Reimplement (wrap) methods dd interface Plus: handles open systems Rename classes or class members Extend interfaces One Little Complication... Problem: Changes between and may lead to name conflicts pplication Name conflict inary 19 inary 20 Solution: Mark Class Files Mark class files compiled against adapted class Resolve conflicts by renaming Textual Delta File Compilation delta add { output(system.out); add implements pplication class C :. class D : none. class D : none. class C :. inary compiler : add add implements Type information ytecodes Object.class System.class.class inary 21 inary 22 Compiling gainst dapted Classes p = () new (); p.;... Parser Code Generator javac Class Loader.class original byte stream C System 1) add 3: invokevirtual.output 2) implements inary.class file.delta inary 23 inary 24 4

5 Overhead Introduced by modifier at load-time ut code executes at full speed Class loader C model Performance Sun JDK no modifications C Execution Times (UltraSparc 200MHz) C with modifications 6 Our implementation: Easy to integrate into JDK Independent of VM data structures C loader JDK loader Extra Class Loader Current implementation SunCC Pizza JLex CUP JDK No Changes makevector addprint rename inary 25 inary 26 Status and Future Work Implemented: C-aware virtual machine compiler C-modified javac Freely available for SPRC/Solaris: Future: Type checker for delta files More modifications (such as refactorings) C Vs. Source Code Modification Just as many kinds of possible changes Guarantees binary compatibility Handles open systems and unknown, dynamically loaded classes Rename classes or class members Extend interfaces Etc. More flexible than source code! inary 27 inary 28 Conclusions inary Modifies components in place (type identity) Uses type information in compiled component Requires no source code Works on any component Guarantees release-to-release compatibility Is efficient enough to be performed at load-time C can significantly improve reusability of components Case For inary Modifying s On The Fly Urs Hölzle and Ralph Keller Department of Computer Science University of California, Santa arbara inary 29 5