A Bytecode Translator for Distributed Execution of “ Legacy ” Java Software

A Bytecode Translator for Distributed Execution of “Legacy” Java Software Michiaki Tatsubori*, Toshiyuki Sasaki*, Shigeru Chiba**, and Kozo Itano* * University of Tsukuba, Japan ** Tokyo Institute of Technology, Japan ECOOP 2001, Budapest, Hungary

Developmentof Distributed Java Software • An example scenario • “Wehave already got nice software.” • “But we want to display GUI of the software on a remote host.” • Run GUI components on a remote host, and run others on a local host ECOOP 2001, Budapest, Hungary

Two Approaches • Use X Window • No need to edit a program • Rewrite a program by hand • Using Java RMI or CORBA ECOOP 2001, Budapest, Hungary

X Window • Distribution by the XlibLibrary • Bad response time if GUI is complex • High communication overhead “A mouse moved” “A mouse-button pushed” Xlib “A mouse-button released” UserProgram “Draw a line” ECOOP 2001, Budapest, Hungary

Rewrite a Program by Hand • Good response time • The programmer can tune the code. • Low communication overheads. Higher-level commands ORB Library A click in a window UserProgram UserProgram Show an internal-window ECOOP 2001, Budapest, Hungary

Automation vs. Efficiency • X Window • Fully automated, but • Slow • By hand • Many man-hours, though • Fast Xlib UserProgram GUIModule UserProgram ECOOP 2001, Budapest, Hungary

Automation vs. Efficiency • X Window • Decomposition atthe library layer • For better performance,complex decomposition isnecessary. Xlib UserProgram GUIModule UserProgram ECOOP 2001, Budapest, Hungary

Addistant– Our Solution • A Java program translator • Translating a non-distributed program to a distributed one • Decomposing at anywhere • The user can specify the decomposition with a policy file. Policy file UserProgram GUIModule ECOOP 2001, Budapest, Hungary

Addistant is a Practical Tool! • Bytecode translation by a class-loader • Using Javassist[Chiba00]. • No source code, no custom JVM. • Addistant can process real applications. • It can migrate Swing components to a remote host. Standard library for rich GUI ECOOP 2001, Budapest, Hungary

Decomposition is Not Easy… • A simple proxy-master implementation NEVER works. • Proxy-master – a typical implementation technique for remote references MethodInvocation Proxy Master Network Communications ECOOP 2001, Budapest, Hungary

class WidgetProxy implements Widget { … } interface Widget { … } JavaRMI’s Way Doesn’t Work • To be remotely accessible, • We must translate … If WidgetImpl is a system class,we cannot modify the class declaration! The JVM prohibits it. class WidgetImpl { … } implements Widget { ECOOP 2001, Budapest, Hungary

In a Policy File of Addistant • Users choose one of four implementation techniques for each class. • Those techniques modify code in different ways. • But they have different limitations in use. • Some techniquesdo not modify an original class, so they can be used for system classes. ECOOP 2001, Budapest, Hungary

Distributed Swing Application • A policy file <policy> <importproxy="rename" from="display"> subclass@java.awt.-　subclass@javax.swing.-　.. </import> <importproxy="rename" from="application"> exactsubclass@java.io.[InputStream|OutputStream|..] exactsubclass@javax.swing.filechooser.* </import> <importproxy="subclass"> subclass@java.util.[AbstractCollection|..] </import> <importproxy="writeBackCopy"> array@- </import> <importproxy="replace" from="application"> user@- </import> <importproxy="copy"> - </import> </policy> ECOOP 2001, Budapest, Hungary

Widget WidgetProxy show() show() .. Show .. .. Send .. “Rename” technique(e.g. for java.awt.Window) • It does not modify the original class. • But local and remote references cannot coexist on the same host. Caller-side Class declaration Widget w = new Widget(); w.show(); WidgetProxy w = new WidgetProxy(); w.show(); ECOOP 2001, Budapest, Hungary

Widget WidgetProxy show() show() .. Show .. .. Send .. Local reference Remote reference “Subclass” technique(e.g. for java.util.Vector) • Local and remote references can coexist on the same host. • But the original class must not be final. • If final, it must be modifiable. Caller-side Class declaration Widget w = new Widget(); w.show(); ECOOP 2001, Budapest, Hungary

Experiment: Response time • “Click” to “Pop-up a Window” • Application Host • Sparc 440MHz • GUI Host • PentiumII 500MHz • Network • 10Base-T Half • 100Base-TX Full ECOOP 2001, Budapest, Hungary

IBM’s awt-compatible library for remote GUI Results of Experiments • Addistant showed good results. • Response Time (sec.) 10base-t / 100base-tx • Transferred data size (kb) ECOOP 2001, Budapest, Hungary

Concluding Remarks • Addistant – an adapter of “legacy” Java programs for their distributed execution on multiple hosts • A translator (automation) approach for complex decomposition of a program • A practical technology which can handles Swing • Other Contribution • A case-study of the usefulness of Javassist[Chiba00] ECOOP 2001, Budapest, Hungary

Question or Suggestion? ECOOP 2001, Budapest, Hungary

System Classes • For implementing remote references, different way for a different class is used. Scopes of the required code modification are different in each implementation • Choosing implementation method avoiding any modification of system classes • “It’s no use kicking against bricks” • Declarative specification in a policy file • “Replace”, “Rename”, “Subclass”, “Copy” ECOOP 2001, Budapest, Hungary

Widget Widget show() show() .. Show .. .. Send .. “Replace” Approach(e.g. user classes) • Replaces the master class declaration with a proxy version • When the target class is modifiable Only one version exists on a single JVM. Widget w = new Widget(); w.show(); Make it distributed Replace all ECOOP 2001, Budapest, Hungary

“Copy” Approach(e.g. java.lang.String) • Does not create any proxy class, but transfers serialized objects to remote host at RMI • Shallow copy • A Variation – “Write-back Copy”Approach • For arrays byte[] buf = …;istream.read(buf); ECOOP 2001, Budapest, Hungary

Automating Development of Distributed Ver. of “Legacy” Soft • Less Developing Costs by Automation • Reusing “Legacy”, Existing, Software • Ordinary Environments (Auto Remote GUI) • X Window System、VNC、Rawt[IBM Haifa 98] • Ordinary Tools for (Semi-Auto) Distribution • JavaRMI, ObjectSpace, Corba-compliant ORB… • ”remotenew”[Nagaratnam 96] , JavaParty[Philippen 99]、… ECOOP 2001, Budapest, Hungary

Distributed Execution of Software For example,Separating GUI from application logic • Reduces administration costs, and • Makes use of ubiquitous client-machines • “Zero Administration” • “Thin Client” ECOOP 2001, Budapest, Hungary

A Bytecode Translator for Distributed Execution of “ Legacy ” Java Software