2005 Oopsla Classboxj
Upcoming SlideShare
Loading in...5
×
 

2005 Oopsla Classboxj

on

  • 2,678 views

Unanticipated changes to complex software systems can introduce anomalies such as duplicated code, suboptimal inheritance relationships and a proliferation of run-time downcasts. Refactoring to ...

Unanticipated changes to complex software systems can introduce anomalies such as duplicated code, suboptimal inheritance relationships and a proliferation of run-time downcasts. Refactoring to eliminate these anomalies may not be an option, at least in certain stages of software evolution. Classboxes are modules that restrict the visibility of changes to selected clients only, thereby offering more freedom in the way unanticipated changes may be implemented, and thus reducing the need for convoluted design anomalies. In this paper we demonstrate how classboxes can be implemented in statically-typed languages like Java. We also present an extended case study of Swing, a Java GUI package built on top of AWT, and we document the ensuing anomalies that Swing introduces. We show how Classbox/J, a prototype implementation of classboxes for Java, is used to provide a cleaner implementation of Swing using local refinement rather than subclassing.

Statistics

Views

Total Views
2,678
Views on SlideShare
2,575
Embed Views
103

Actions

Likes
0
Downloads
7
Comments
0

4 Embeds 103

http://bergel.eu 60
http://www.bergel.eu 41
http://209.85.135.104 1
http://translate.googleusercontent.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

2005 Oopsla Classboxj 2005 Oopsla Classboxj Presentation Transcript

  • Classbox/J: Controlling the Scope of Change in Java Alexandre Bergel, Stéphane Ducasse and Oscar Nierstrasz bergel@iam.unibe.ch
  • Outline 1. AWT and Swing Anomalies 2. Classbox/J 3. Properties of Classboxes 4. Swing as a Classbox 5. Implementation 6. Conclusion Alexandre Bergel 2
  • Presentation of AWT java.awt Component Button Container Window Frame In the AWT framework: • – Widgets are components (i.e., inherit from Component) – A frame is a window (Frame is a subclass of Window) Alexandre Bergel 3
  • Problem: Broken Inheritance in Swing java.awt Component Button Container Window Frame javax.swing JComponent JWindow JFrame JButton Alexandre Bergel 4
  • Problem: Code Duplication Code Duplication java.awt Component Button Container Window Frame javax.swing JComponent JWindow JFrame accessibleCont accessibleContext accessibleContext JButton ext update() rootPane rootPane update() update() setLayout() setLayout() ... ... Alexandre Bergel 5
  • Problem: Explicit Type Checks and Casts public class Container extends Component { Component components[] = new Component [0]; public Component add (Component comp) {...} } public class JComponent extends Container { public void paintChildren (Graphics g) { for (; i>=0 ; i--) { Component comp = getComponent (i); isJComponent = (comp instanceof JComponent); ... ((JComponent) comp).getBounds(); } }} Alexandre Bergel 6
  • We need to Support Unanticipated Changes AWT couldn’t be enhanced without risk of breaking • existing code. Swing is, therefore, built on the top of AWT using • subclassing. As a result, Swing is a big mess internally! • We need a mechanism to support unanticipated changes. • Alexandre Bergel 7
  • Classbox/J Module system for Java allowing classes to be refined • without breaking former clients. A classbox is like a package where: • – a class defined or imported within a classbox p can be imported by another classbox (transitive import). – class members can be added or redefined on an imported class with the keyword refine. – a refined method can access its original behavior using the original keyword Alexandre Bergel 8
  • Refining Classes (1 / 2) A classbox widgetsCB package widgetsCB; public class Component { public void update() {this.paint();} public void paint () {/*Old code*/} } public class Button extends Component { ... } Alexandre Bergel 9
  • Refining Classes (2 / 2) Widget enhancements defined in NewWidgetsCB: package NewWidgetsCB; import widgetsCB.Component; import widgetsCB.Button; refine Component { Variable addition */ /* private ComponentUI lookAndFeel; /* Redefinition of paint() */ public void paint() { /* Code that uses lookAndFeel*/ } } Alexandre Bergel 10
  • Multiple Versions of Classes Import class refinement C widgetsCB NewWidgetsCB Component Component lookAndFeel paint() update() paint() Button Button new Button(“Ok”).update() new Button(“Ok”).update() Alexandre Bergel 11
  • Import over Inheritance Import class refinement C widgetsCB NewWidgetsCB Component Component lookAndFeel paint() update() 4 3 paint() Button Button 2 1 new Button(“Ok”).update() new Button(“Ok”).update() Lookup of the update() method triggered within 1 enhWidgetsCB. Alexandre Bergel 12
  • But update() calls paint() Import class refinement C widgetsCB NewWidgetsCB Component Component lookAndFeel paint() update() paint() 3 Button Button 2 1 new Button(“Ok”).update() new Button(“Ok”).update() Lookup of the paint() method triggered within 1 enhWidgetsCB Alexandre Bergel 13
  • Old and New Clients at the Same Time Import class refinement C widgetsCB NewWidgetsCB Component Component lookAndFeel paint() update() paint() Button Button NewGUIAppCB OldGUIAppCB Button NewGUIApp Button OldGUIApp Alexandre Bergel 14
  • Properties of Classboxes Minimal extension of the Java syntax (transitive import, • refine and original keywords). Refinements are confined to the classbox that define them • and to classboxes that import refined classes. Method redefinitions have precedence over previous • definitions. Classes can be refined without risk of breaking former • clients. Alexandre Bergel 15
  • Swing Refactored as a Classbox AwtCB Component Container Button Window Frame SwingCB Component Window accessibleContext Frame component rootPane Button update() setLayout() add(Component) setRootPane() remove(Component) setContentPane() ... Alexandre Bergel 16
  • Swing Refactoring 6500 lines of code refactored over 4 classes. • Inheritance defined in AwtCB is fully preserved in • SwingCB: – In SwingCB, every widget is a component (i.e., inherits from the extended AWT Component). – The property “a frame is a window” is true in SwingCB. Removed duplicated code: the refined Frame is 29 % • smaller than the original JFrame. • Explicit type checks like obj instanceof JComponent and (JComponent)obj are avoided. Alexandre Bergel 17
  • Naive Implementation Based on source code manipulation. • The method call stack is introspected to determine the • right version of a method to be triggered. No cost for method additions, however slowdown of 1000 • times when calling a redefined method. However, much better results were obtained in Smalltalk. • 5 byte-codes are added to redefined methods (see our previous work). Alexandre Bergel 18
  • Conclusion Classboxes delimit visibility of a change and avoid impacting • clients that should not be affected. Java is extended with two new keywords and transitive • import. Large case study showing how classboxes can be more • powerful than inheritance to support unanticipated changes. Performance could be improved by modifying the VM. • Alexandre Bergel 19
  • We need an alternative to inheritance to support unanticipated changes! Alexandre Bergel: bergel@iam.unibe.ch google “classboxes” Alexandre Bergel 20
  • END Alexandre Bergel 21
  • A JWidget is not necessary a JComponent java.awt Component Button Container Window Frame javax.swing JComponent JWindow JFrame JButton Are not subclasses of JComponent Alexandre Bergel 22
  • A JFrame is not a JWindow java.awt Component Button Container Window Frame javax.swing JComponent JWindow JFrame JButton Missing inheritance link between JFrame and JWindow Alexandre Bergel 23
  • AWT and Swing Anomalies Features defined in JWindow are duplicated in JFrame (half • of JWindow code is in JFrame). The Swing design breaks the AWT inheritance relation: • – AWT: a Window is a Component – Swing: a JWindow is not a JComponent Need of explicit type checks and casts in Swing: • – For instance a JWindow needs to check if its elements are issued from Swing or not before rendering them – 82 type checks (instanceof) and 151 cast to (JComponent) Alexandre Bergel 24
  • Method Call Stack Introspected NewWidgetsCB and WidgetsCB define the paint method: package WidgetsCB; public class Component { public void paint() { if (ClassboxInfo.methodVisible ( “NewWidgetsCB”, “Component”, “paint”)){ //Enhanced paint } if (ClassboxInfo.methodVisible ( “WidgetsCB”, “Component”, “paint”)){ //Original paint }}} Alexandre Bergel 25