Abstract

Block joinpoints allow programmers to explicitly mark regions of base code as “to be advised”, thus avoiding the need to extract the block into a method just for the sake of creating a joinpoint. Block joinpoints appear simple to define and implement. After all, regular block statements in Javalike languages are constructs well-known to the programmer and have simple control-flow and data-flow semantics. Our major insight is, however, that by exposing a block of code as a joinpoint, the code is no longer only called in its declaring static context but also from within aspect code. The block effectively becomes a closure, i.e., an anonymous function that may capture values from the enclosing lexical scope. We discuss research on closures that reveals several important design questions that any semantic definition of closures or block joinpoints must answer. In this paper we show that all existing proposals for block joinpoints answer these questions insufficiently, and hence exhibit a semantics either undefined or likely surprising to Java programmers. As a solution, we propose a syntax, semantics, and implementation of Closure Joinpoints, block joinpoints based on closures. As we show, our design decisions yield a semantics that follows the principle of least surprise.

Citations