Eliminating redundancies with a "composition with adaptation" meta-programming technique

Abstract

Redundant code obstructs program understanding and contributes to high maintenance costs. While most experts agree on that, opinions - on how serious the problem of redundancies really is and how to tackle it - differ. In this paper, we present the study of redundancies in the Java Buffer library, JDK 1.4.1, which was recently released by Sun. We found that at least 68% of code in the Buffer library is redundant in the sense that it recurs in many classes in the same or slightly modified form. We effectively eliminated that 68% of code at the meta-level using a technique based on "composition with adaptation" called XVCL. We argue that such a program solution is easier to maintain than buffer classes with redundant code. In this experiment, we have designed our meta-representation so that we could produce buffer classes in exactly the same form as they appear in the original Buffer library. While we have been tempted to re-design the buffer classes, we chose not to do so, in order to allow for the seamless integration of the XVCL solution into contemporary programming methodologies and systems. This decision has not affected the essential results reported in this paper.

"Cloning Considered Harmful" Considered Harmful

“…Tools and methodologies such as Linked Editing [29] should be used to ensure consistent changes are made to all duplicates. Another approach to managing these clones is to use generated code at build time [20], making the duplicate exist only when the source code is compiled. Long term issues.…”

“…Jarzabek et al [20] and Basit et al [6] performed case studies for reducing duplication in on the Java buffer classes and the STL. In their studies, they used a meta-language XVCL to reconstruct the code at compile time.…”

“…In their studies, they used a meta-language XVCL to reconstruct the code at compile time. In [20] many clones existed because of language limitations and were removed using templates. In [6] the STL made heavy use of generics to reduce redundant code but redundant code still existed in a form analogous to customization and boiler-plating patterns where operators were modified.…”

Managing Big Clones to Ease Evolution: Linux Kernel Example

“…However, less cloning happens in advanced Software Product Line (SPL) solutions [4] where reuse and evolution are aided by systematic variability management rather than by cloning. There is a large body of research on reasons why clones arise-both within and across system versions-and whether clones are good or bad [5][6] [7]. These studies show that designers may intentionally create certain clones to fulfill some design goals (e.g., for performance, readability, or yet other reasons) [5].…”

“…These studies show that designers may intentionally create certain clones to fulfill some design goals (e.g., for performance, readability, or yet other reasons) [5]. Other clones may result from careless design and can be refactored [6] [8], and yet others may not play any useful role, but cannot be eliminated using conventional design techniques [7]. Nevertheless, cloning is a reality and there is need to deal with it [9].…”