Enhancing Source-Level Programming Tools with An Awareness of ...

the changes in data values and code location. A significantamount of research aims at the problem of debugging optimizedcode [20, 21, 7, 27, 16, 9, 18]. The proposed solutionsenable source-level debuggers to display the informationabout an optimized program, as if the original (unoptimized)version of the code was being debugged.The techniques for debugging optimized code deal withthe challenges arising as a result of optimizing compilerstransforming intermediate code to improve performance.While these transformations can be quite extensive, theyare usually confined to method bodies and do not alterthe debugged program’s semantics. By contrast, structuralenhancement aims at larger-scale program transformationsthat can add new classes and interfaces to a program. Thus,source level debugging of structurally enhanced programsrequires different debugging techniques such as the presentedsymbolic undo.Debugging for AOP. Aspect-Oriented Programming(AOP) [24] can be viewed as an enhancement technology,and several approaches aim at debugging support forAOP [14, 34, 22]. However, debugging aspect-oriented programsis different from debugging transparently enhancedprograms. AOP provides a domain-specific language forprogramming enhancements such as AspectJ [23], and anAOP debugger traces the bytecode generated by AspectJ toits aspect source file. By contrast, transparent bytecode enhancementshave no source code representation. Thus, theapproaches to debugging AOP software cannot be applied todebugging transparently enhanced programs.In addition, AspectJ as a language cannot express all thestructural enhancement transformations. For example, it isimpossible to express in AspectJ that the name of a programconstruct (e.g., class, field, or method) be changed. AspectJdoes not provide facilities for removing a program construct,something that program enhancers need to do on a regularbasis. For example, the split class enhancement movesfields from a class to another class, thus removing them fromthe original class. Finally, program enhancers often generatenew classes and interfaces and reference them in the enhancedprogram. AspectJ is not designed for expressing howto generate a new class, whose structure is based on some existingprogram construct. Thus, we could not have used AspectJinstead of SER to represent structural enhancements.5.2 Program Transformation LanguagesSER is a domain-specific language for expressing how bytecodeis enhanced structurally. Other domains also featuredomain-specific languages for expressing program transformations.JunGL [48], a domain-specific language for refactoring,combines functional and logic query language idioms.JunGL represents programs as graphs and manipulates refactoringsvia graph transformations. The language providespredicates to facilitate the querying of graph structures.JunGL uses demand-driven evaluation to prevent scriptsfrom becoming prohibitively complex.Sittampalam et al. [39] specify program transformationsdeclaratively and generate executable program transformersfrom specifications. The Prolog language is augmented withfacilities for incremental evaluation of regular path queries.The augmented language is used to specify program transformationsby expressing a program and its transformedcounterpart. The transformations can be combined with astrategy script, based on Stratego [49], to specify the traversalsof a program and the order of the transformations.Whitfield and Soffa’s code-improving transformationframework consists of a case tool and a specification language[50]. The specification language, called Gospel, declaresprogram transformations; the case tool, called Genesis,generates a program transformer given a Gospel specification.A Gospel script consists of a declaration section,containing variables declarations, a precondition section,containing code pattern descriptions and control dependenceconditions, and an action section, containing a set of transformationoperations.The Coccinelle [41] tool introduces the SmPL languagefor locating and automatically fixing bugs. SmPL programsspecify how in response to some runtime condition, a programshould be transformed to fix a bug and log the changes.FSMLs [10] is a domain specific modeling language fordescribing the framework-provided knowledge, includingframework instantiation, procedures for implementing interfaces,and proper usage of framework services. FSMLsbears similarity to our approach in its ability to provide a bidirectionalmapping between framework features and theirabstract representation.JAVACOP [1] introduces a declarative rule languagefor expressing programmer-defined types, called pluggabletypes. The types are described as user-defined rules, whichJAVACOP uses for transforming the abstract syntax tree of aprogram.Because these program transformation languages weredesigned specifically for their respective domains, we couldnot have used any of them for our purposes. The main designgoal of our SER language was to be able to expressstructural enhancements used by bytecode enhancers declarativelyand to provide special constructs for domain-specifictransformations such as adding getter/setter methods.5.3 Program DifferencingSER scripts describe generalized structural program differences.Program differencing is an active research area andseveral new differencing algorithms have been proposed recently.Previtali et al.’s technique [35] generates version differencesof a class at bytecode level. Their algorithm producesthe information on added, removed, or modified classes.Dmitriev incorporates program change history into a Javamake utility that selectively recompiles dependent sourceAccepted to OOPSLA 2009 14 2009/5/14