The slides for my WODA talk are now available online.
Slides for WODA talk
Eric | July 19, 2011Nightly builds of Clara, Soot, JastAdd, Jasmin…
Eric | July 18, 2011
Thanks to my colleagues Marcel and Johannes I have now been able to set up nightly builds for Clara, Soot, JastAdd and the Soot version of Jasmin on our server in Darmstadt. Please help yourself!
Nightly builds of TamiFlex will follow.
If you want to build Clara yourself, please proceed as follows. Type:
svn co http://clara.googlecode.com/svn/trunk-with-deps clara-with-deps
This will checkout clara and all dependencies into clara-with-deps. To build Clara, open the directory build and then execute the ant script there. That should be all.
P.S. Note that we are not longer building Polyglot from scratch, as the polyglot-based frontend to Soot is deprecated now. It has been replaced by a frontend based on JastAdd.
Join Point Interfaces
Eric | July 5, 2011
Another paper to appear at the New Ideas track of ESEC/FSE:
While aspect-oriented programming supports the modular definition of crosscutting concerns, most approaches to aspect-oriented programming fail to improve, or even preserve, modular reasoning. The main problem is that aspects usually carry, through their pointcuts, explicit references to the base code. These dependencies make programs fragile. Changes in the base code can unwittingly break a pointcut definition, rendering the aspect ineffective or causing spurious matches. Conversely, a change in a pointcut definition may cause parts of the base code to be advised without notice. Therefore separate development of aspect-oriented programs is largely compromised, which in turns seriously hinders the adoption of aspect-oriented programming by practitioners.
We propose to separate base code and aspects using Join Point Interfaces, which are contracts between aspects and base code. Base code can define pointcuts that expose selected join points through a Join Point Interface. Conversely, an aspect can offer to advise join points that provide a given Join Point Interface. Crucially, however, aspect themselves cannot contain pointcuts, and hence cannot refer to base code elements. In addition, because a given join point can provide several Join Point Interfaces, and Join Point Interfaces can be organized in a subtype hierarchy, our approach supports join point polymorphism. We describe a novel advice dispatch mechanism that offers a flexible and type-safe approach to aspect reuse.
This is joint work with Milton Inostroza and Éric Tanter from the Pleiad group.
Stateful Breakpoints: A Practical Approach to Defining Parameterized Runtime Monitors
Eric | July 1, 2011
To appear at the New Ideas track of ESEC/FSE:
A runtime monitor checks a safety property during a program’s execution. A parameterized runtime monitor can monitor properties containing free variables, or parameters. For instance, a monitor for the regular expression “close(s)+ read(s)” will warn the user when reading from a stream s that has previously been closed. Parameterized runtime monitors are very expressive, and research on this topic has lately gained much traction in the Runtime Verification community. Existing monitoring algorithms are very efficient. Nevertheless, existing tools provide little support for actually defining runtime monitors, probably one reason for why few practitioners are using runtime monitoring so far.
In this work we propose the idea of allowing programmers to express parameterized runtime monitors through stateful breakpoints, temporal combinations of normal breakpoints, a concept well known to programmers. We show how we envision programmers to define runtime monitors through stateful breakpoints and parameter bindings through breakpoint expressions. Further, we explain how stateful break- points improve the debugging experience: they are more expressive than normal breakpoints, nevertheless can be evaluated more efficiently. Stateful breakpoints can be attached to bug reports for easy reproducibility: they often allow developers to run directly to the bug in one single step. Further, stateful breakpoints can potentially be inferred from a running debugging session or using property inference and fault localization tools.
