Relational Aspects as Tracematches

Eric | February 10, 2008

image You might remember my previous post (or that one) about relational aspects. As I mentioned there, relational aspects allow you to associate certain objects with an aspect and execute pieces of advice in this aspect in the context of these objects.

We have now published the final camera ready version of our AOSD 2008 submission. There we show in particular how relational aspects can be implemented using tracematches. Further, we show you what relational tracematches are, and we give examples of how use both, relational aspects and tracematches, such as caching or the observer pattern. You can grab the AOSD paper directly from here. Or, in case you are interested in all the nifty details, grab our updated and extended technical report version. Also, in case you have any comments on this work, please let me know!

Comments
Comments Off on Relational Aspects as Tracematches
Categories
Research
Tags
AOP, Java, Relational aspects

New TR: Static Analysis Techniques for Evaluating Runtime Monitoring Properties Ahead-of-Time

Eric | November 23, 2007

imageToday I am proud to present our brand new Technical Report in which Patrick Lam, Laurie Hendren and me present how you can use static analysis to evaluate runtime monitoring properties ahead-of-time, i.e. at compile time opposed to at runtime.

We have been working on this topic for about a year now, with different approaches and it actually took us until some weeks ago to get it actually all worked out. The coolest thing is that the approach we found in the end is really surprisingly simple, yet very effective. All it needs is a good static abstraction and super-precise pointer analysis. That’s it. The problem that we had before was that we were tying to make things more complicated than they were.

Read the rest of this entry »

Java and generics: handle with care – part 2

Eric | November 23, 2007

This is a follow-up to my earlier posting in which I was ranting about Java generics. Subject of the post were these two pieces of Java code:

Set<String> stringSet = new HashSet<String>();
Set<String> otherStringSet = new HashSet<String>();
otherStringSet.add((String) stringSet);
Set<List> listSet = new HashSet<List>();
Set<List> otherListSet = new HashSet<List>();
otherListSet.add((List) listSet);

The first one gives a static type error in line 3 because obviously one cannot cast a Set to a String. What confused me was that the second piece of code is (statically) well-typed. You will get a runtime error on the cast (List) listSet, but no compile time error. Why is that?

Read the rest of this entry »

Comments
Comments Off on Java and generics: handle with care – part 2
Categories
Research
Tags
Java, Programming

How relational aspects could have helped Princeton win the DARPA challenge

Eric | November 18, 2007

image Bryan Cattle recently explained why their autonomous car developed for the DARPA urban challenge did not make it: They simply had a memory leak in their C# code, filling up their entire heap space after about 28 minutes which made the computer crash. It’s important to note that this is not at all any flaw in C#. As C# is now, it was the programmers’ fault: In their code they kept around a list of obstacles which the car passed by. Obstacles that came out of sight were deleted… but not quite. Because the obstacles were registered as event listeners somewhere else in the code they were reachable and hence could not be garbage collected. Too bad, but how could such a problem have been avoided?

Read the rest of this entry »

Comments
Comments Off on How relational aspects could have helped Princeton win the DARPA challenge
Categories
Research
Tags
Bug finding, Coding, DARPA challenge, Java

How delegates impose contracts on their wrappers

Eric | November 15, 2007

This week I was working a lot on our new PLDI submission, which we just submitted (more about that later). During this work I came around an interesting subtlety with respect to delegates and Design By Contract (DBC) . We wanted to validate the fulfillment of a contract for the Iterator interface: When using an iterator i you are only allowed to call i.next() if before that you have checked whether i.hasNext() holds. For PLDI we developed a static analysis approach (using tracematches) that allows you to flag potential violations of this contract. Here is one that we found in Jython, a Python implementation for the Java Virtual Machine and part of the DaCapo benchmark suite:

Read the rest of this entry »

Comments
Comments Off on How delegates impose contracts on their wrappers
Categories
Research
Tags
Bug finding, Java, Programming