2005 Oopsla Classboxj


Published on

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.

Published in: Business, Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

2005 Oopsla Classboxj

  1. 1. Classbox/J: Controlling the Scope of Change in Java Alexandre Bergel, Stéphane Ducasse and Oscar Nierstrasz bergel@iam.unibe.ch
  2. 2. 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
  3. 3. 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
  4. 4. Problem: Broken Inheritance in Swing java.awt Component Button Container Window Frame javax.swing JComponent JWindow JFrame JButton Alexandre Bergel 4
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. 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
  9. 9. Refining Classes (1 / 2) A classbox widgetsCB package widgetsCB; public class Component {