In his essay, Designed as Designer, Richard Gabriel suggests that artifacts are agents of their own design. Building on Gabriel’s position, this essay makes three observations (1) Code “speaks” to the programmer through code smells, and it talks about the shape it wants to take by signalling design principle violations. By “listening” to code, even a novice programmer can let the code itself signal its own emergent natural structure. (2) Seasoned programmers listen for code smells, but they hear in the language of design principles (3) Design patterns are emergent structures that naturally arise from designers listening to what the code is signaling and then responding to these signals through refactoring transformations. Rather than seeing design patterns as an educational destination, we see them as a vehicle for teaching the skill of listening. By showing novices the stories of listening to code and unfolding design patterns (starting from code smells, through refactorings, to arrive at principled structure), we can open up the possibility of listening for emergent design.

Debugging and analyzing a snapshot of a crashed program's memory is far more difficult than working with a live program, because debuggers can no longer execute code to help make sense of the program state. We present an architecture that supports the restricted execution of ordinary code starting from the snapshot, as if the dead objects within it had been restored, but without access to their original external environment. We demonstrate the feasibility of this approach via an implementation for Java that does not require a custom virtual machine, show that it performs competitively with live execution, and use it to diagnose an unresolved memory leak in a mature mainstream application.

The adoption of programming language innovation is impeded because all program processing tools in the tool chain must support any new or altered language features. Registration-based abstractions (RBAs) were proposed to address this difficulty by allowing the editor to transiently superimpose new language abstractions on existing code. Individual programmers can choose where and when to see a new language abstraction, while at all times the underlying code remains written in the original language. Prior work demonstrated the feasibility of RBAs, but left important questions unanswered regarding how users would interact with such an approach. We asked 50 undergraduate students to answer basic program comprehension questions with and without RBAs. Our results show that participants can quickly and easily understand new abstractions without additional training, and suggest that this will extend to the general programmer community. The results also support a comparison across RBAs, and an initial discussion of specific features that facilitate or confound understanding.

We present a novel approach to the problem of dynamic program analysis: writing analysis code directly into the program source, but evaluating it against a recording of the original program's execution. This approach allows developers to reason about their program in the familiar context of its actual source, and take full advantage of program semantics, data structures, and library functionality for understanding execution. It also gives them the advantage of hindsight, letting them easily analyze unexpected behavior after it has occurred. Our position is that writing offline analysis as retroactive aspects provides a unifying approach that developers will find natural and powerful.

When late-binding of advice is used for incremental development or configuration, implementing advice weaving using code rewriting external to the VM can cause performance problems during application startup. We present an interpreter-based (non-rewriting) weaver that uses a simple table and cache structure for matching pointcuts against dynamic join points together with a simple mechanism for calling the matched advice. An implementation of our approach in the Jikes RVM shows its feasibility. Internal micro-benchmarks show dynamic join point execution overhead of approximately 28% in the common case where no advice is applicable and that start-up performance is improved over VM-external weavers. The cache and table structures could be used during later (i.e. JIT time) per-method rewrite based weaving to reduce pointcut matching overhead. We conclude that it is worthwhile to develop and evaluate a complete in-VM hybrid implementation, comprising both non-rewriting and rewriting based advice weaving.

The non-local nature of advice applicability in AspectJ means that in many implementations small changes to aspects can require much of the program code to be scanned and possibly rewritten. This can slow down application startup, including the edit-compile-debug development cycle. Late binding of advice has been suggested to improve the situation, at the potential cost of runtime performance. We propose and evaluate two virtual machine (VM) internal late binding approaches, that operate at whole-class and whole-method granularity. Our evaluation shows that in VMs that allow bytecode mutation the preferred approach is to scan and rewrite methods the first time they are executed. In other VMs, whole-class scanning and rewriting at load time performs better. A separate interpreter based approach has startup performance similar to that of the whole-class approach; but micro-benchmarks suggest the latter out-performs the former over time.

Programming language innovation has been hindered by the difficulty of making changes to existing languages. A key source of difficulty is the tyrannical nature of existing approaches to realizing languages -- adding a new language construct means that any tool, document or programmer that works with the language must be prepared to deal with that construct. A registration-based approach makes it possible to define language constructs that are not tyrannical. They are instead transient -- the program appears to be written using the constructs only so long as a given programmer wants to see it that way. This approach may have the potential to greatly facilitate programming language innovation.

Advice weaving can be efficiently supported with only lightweight enhancements to existing Virtual Machines. Performing weaving at the Java bytecode (JBC) level while preserving appropriate metadata enables the VM to understand the AspectJ-specific semantics of the code and optimize it. This allows the overhead of advice weaving and performing non-local advice dispatch optimization to occur prior to runtime. It also allows the VM to perform optimizations that are unavailable to a bytecode level weaver. An experimental implementation shows that this approach can take advantage of previously known macro optimizations of expensive constructs, including cflow, as well as micro optimizations including those based on improved type analysis unavailable to JBC-based advice dispatch. A thorough benchmark evaluation confirms that the use of this architecture does not result in runtime performance overhead and benefits from the implemented optimizations.

Context plays a large role in our perspective on the world around us--people see things differently depending on background, role, task at hand, and many other variables.How do different contexts affect developer perspectives on software? What different ways do developers want to see a program? What different ways do they want to work with a program? How does a program mean different things to different people? How does context influence perspective? How do different contexts and perspectives interact? Can these interactions be reified, controlled, and parameterized?.A broad range of work has explored these questions, but many issues remain open. We lack a general understanding of the concepts and mechanisms that can support the changes in perspective we need. We lack the ability to handle context and perspective systematically, easily, and reliably throughout software development.Work is needed in a number of areas, from conceptual foundations to theory, languages, tools, and methods. A truly satisfying handle on these issues may even require a material expansion of the foundations of computation--or at the very least the foundations of programming languages.

Summary form only given. The idea that programs should clearly reflect the design decisions they embody has a long history. Higher-level languages, syntactic macros, domain-specific languages, and intentional programming are different approaches to this common goal. Recent work from several areas, including aspect-oriented programming, has significantly advanced our ability to make code expressive. At the same time, it forces us to reconsider a number of basic assumptions, including what is a program, what is a module, what is a language, and what is an editor.

This paper presents the initial results of our experiment using an aspect-oriented approach to simplify operating system code. The intuition behind this work is that complexity comes from crosscutting concerns. In this experiment, we re-implemented prefetching for page fault handling and file system read requests using a hypothetical language, AspectC – a variant of AspectJ for C – and hand-compiled the code to C. We believe that the aspect-oriented code is easier to understand, and in particular that it is easier to understand the interaction between the virtual memory and file system prefetching mechanisms.

Most approaches to programming language extensibility have worked by pairing syntactic extension with semantic extension. We present an approach that works through a combination of presentation extension and semantic extension. We also present an architecture for this approach, an Eclipse-based implementation targeting the Java programming language, and examples that show how presentation extension, both with and without semantic extension, can make programs more expressive.

To assess the scalability of AspectJ, we refactored concerns that crosscut over half of the plug-ins that comprise the Eclipse IDE. Eclipse is a suitable candidate for furthering other scalability studies of AspectJ because it is not only large, but also has an additional modularization mechanism typical of large systems that introduces new complexities for defining advice and aspects. We evaluated our AO refactored system quantitatively by examining changes in execution time and memory usage, as well as qualitatively by examining changes in scattering, coupling, and abstractions. We conclude that AspectJ scales well in that it can be used in large systems, but that the system may require modifications to the build and class loading procedures in order to cope with defining advice that cross system boundaries.

The primary implementations of AspectJ to date are based on a compile- or load-time weaving process that produces Java byte code. Although this implementation strategy has been crucial to the adoption of AspectJ, it faces inherent performance constraints that stem from a mismatch between Java byte code and AspectJ semantics. We discuss these mismatches and show their performance impact on advice dispatch, and we present a machine code model that can be targeted by virtual machine JIT compilers to alleviate this inefficiency. We also present an implementation based on the Jikes RVM which targets this machine code model. Performance evaluation with a set of micro benchmarks shows that our machine code model provides improved performance over translation of advice dispatch to Java byte code.

Aspect-Oriented Programming (AOP) and Aspect-Oriented Software Development (AOSD) endeavor to aid programmers in the separation of concerns, specifically crosscutting concerns, as an advance in modularization. AOP does so using primarily language changes, while AOSD uses a combination of language, environment, and methodology. But the concepts of obliviousness-not universally accepted as part of AOP-and parameterization appear to contradict the well-established principles of modularity and encapsulation that David Parnas and other greats of the past laid out and on which software engineering has depended for the last 40 years. Are we moving forward with better understandings of software engineering, modularity, and design/development principles, or are we losing our way? This debate is the postscript to Friedrich Steinmann's OOPSLA Essay, "The Paradoxical Success of Aspect-Oriented Programming.

We have found many programming problems for which neither procedural nor object-oriented programming techniques are sufficient to clearly capture some of the important design decisions the program must implement. This forces the implementation of those design decisions to be scattered throughout the code, resulting in "tangled" code that is excessively difficult to develop and maintain. We present an analysis of why certain design decisions have been so difficult to clearly capture in actual code. We call the properties these decisions address aspects, and show that the reason they have been hard to capture is that they cross-cut the system's basic functionality. We present the basis for a new programming technique, called aspect-oriented programming, that makes it possible to clearly express programs involving such aspects, including appropriate isolation, composition and reuse of the aspect code. The discussion is rooted in systems we have built using aspect-oriented programming.

I will present a prototype tool that enables Java annotations to serve as an extension point for making programs more visually expressive. Thus, programmers can view and edit code in a way that more closely resembles the intention of the code, rather than the raw text. Examples that we have applied the tool to are JDBC 4.0, getters, setters and constraints, JSR 181Webservices, AspectJ, and state charts.

How can the ultra large systems (ULS) of the future be built if they will have the complexity of trillions of lines of code, maintain continuous 24x7 operations with no downtime, and live in a hostile environment with unpredictably changing requirements? This panel will discuss and debate the challenges posed by ultra large systems in terms of their design, growth, deployment and dynamics.