Dean Wampler's Blog

This is looong overdue, but you can now manage dependencies on Contract4J5 using Maven. The details are here. Also, I moved the code from a private subversion repository to GitHub.

Contract4J5 is my Design by Contract library for Java. I haven’t worked on it in a while, but I hope to return to it sometime this year to solve the one issue that keeps it from being practical for many teams: performance. Currently, the runtime overhead slows down tests considerably. It is already feature complete and stable.

The Maven bundle includes the all the sources and javadocs, as well as the runtime jar file. However, it is still built with Ant. If you want to work with the source code, clone or fork the GitHub repo.

I posted an extended version of the slides from my QCon San Francisco talk, Radical Simplification Through Polyglot and Poly-Paradigm Programming (PDF). The PDF includes some slides I skipped in the actual talk, for time’s sake.

InfoQ.com may offer a video of this talk. Stay tuned.

I created a new web site, "Polyglot Programming":http://www.polyglotprogramming.com, that is dedicated to the emerging trend of building applications with multiple languages and multiple "modularity paradigms" (e.g., object-oriented, aspect-oriented, and functional programming). There isn't much there yet. ;) Over time, I hope to add case studies, discussions of different languages, etc.

An Aquarium user asked recently if you can use after_raising advice to raise a different exception, e.g., to wrap the original exception. Now you can, with the commits I did today. (This change will appear in the forthcoming V0.4.2 release.) Actually, this feature was partially implemented already, but never finished (OOPS!)

The following made-up example illustrates what you can do. Imagine you are one of the handful of Ruby programmers who aren't using ActiveRecord ;) and you have an OracleDriver class that handles Oracle database transactions.

class OracleDriver
  class OracleDriverException < StandardException; ...; end
  class ConnectionError < OracleDriverException; ...; end
  def connect
    if try_to_connect == false
      raise ConnectionError 
    end
    ...
  end
  def find query_parameters
    ...
  end
end

In the application code that uses the OracleDriver you ignore any exceptions raised (because we will implement an exception handling strategy elsewhere...).

  ...
  def load_object oracle_driver, query_parameters
    oracle_driver.connect
    oracle_driver.find query_parameters
  end
  ...

Finally, you implement an application-wide exception handling strategy for any exceptions raised by the driver.

Aspect.new :after_raising => OracleDriverException, 
    :in_types => ... do |jp, object, *args|
  # Ruby needs a standard way to wrap one exception in another.
  original = jp.context.raised_exception
  app_exception = ApplicationException.new(original.message)
  app_exception.set_backtrace(original.backtrace)
  jp.context.raised_exception = app_exception
end

In other words, any exceptions raised by calls to OracleDriver are wrapped in an ApplicationException, which will be thrown by Aquarium when the advice block finishes.

This technique can also be used when handling exceptions in after advice.

By the way, in a similar way, you can also change the return value in after and after_returning advice. In this case, you assign a new value to jp.context.returned_value.

The new V0.4.0 release of Aquarium adds support for JRuby. Not only do the regular “pure Ruby” Aquarium specs run reliably under JRuby (V1.1RC2), but you can now write aspects for Java types with Aquarium! There are some limitations and issues. For details, see my "blog":http://blog.objectmentor.com/articles/2008/02/25/writing-java-aspects-with-jruby-and-aquarium at "Object Mentor":http://blog.objectmentor.com and the "JRuby":http://aquarium.rubyforge.org/jruby.html page at the Aquarium website.

I released V0.3.0 of Aquarium today. The most visible change is a new set of synonyms for many of the parameters passed to API methods, providing a more "English-like" feel. For example, previously, you might declare an aspect like this:

around :methods => :all, :types => [Foo, Bar], :advice => advice_proc

Now you can write the same aspect as follows:

around :calls_to => :all_methods, :within_types => [Foo, Bar], :use_advice => advice_proc

which reads more like English.

Similarly, attribute matching is simpler.

after :attribute => name, :attribute_options => [:readers], :objects => [foo, bar] ...

becomes

after :reading => name, :on_objects => [foo, bar] ...

There are many internal improvements to improve DRY'ness, robustness, and performance.

There should be no upgrade issues, so give it a try!

I'm reprising my CJUG West talk on Aspect-Oriented Programming and Software Design in Java and AspectJ for the downtown Chicago group on December 18th. I will briefly describe the problems that AOP addresses and how the principles of object-oriented design influence AOP and vice versa. If you're in the area, I hope to see you there.

Yesterday evening, I gave a talk on AOP at DePaul University called Aspect-Oriented Programming in Academia and Industry. Here's the PDF. This talk was a little different than the usual talks I give. Since this audience was mostly students and faculty, I wanted to show how groups in both industry and academia were looking at similar problems that led to the emergence of AOP, how they each contributed to AOP in different ways, and how they can continue complementing each other's work on emerging trends, like Language-Oriented Programming. Language-Oriented Programming is not a new idea, but it is getting renewed attention recently. I see it as a way of formalizing our understanding of how Domain-Specific Languages should be designed. I'm a little concerned that everyone will get so excited about crafting "elegant" DSLs that we'll end up with a Tower of Babel situation; lots of gratuitously-different ways of describing the same thing and no one getting much work done. Anyway, we'll see...

I've posted a PDF for the presentation I did last night on Aquarium at the Chicago Ruby Users Group (Chirb). I also posted a zip file with three exercises that are adapted from the examples on the aquarium web site.

This is primarily a bug-fix release. I labeled it "v0.1.5" instead of "v0.1.1", because a non-trivial API change was required; Aquarium no longer automatically adds methods to Object, due to collisions with Rails. This means that users of the "DSL methods" will need to require a new file or include a new module. See the "CHANGES" file in the distribution of "here":http://aquarium.rubyforge.org/changes.html for more information.

I'm giving a talk at the Chicago Java User's Group West meeting this Thursday at 6:30 PM. The topic is Aspect-Oriented Programming and Software Design in Java and AspectJ. I'll briefly describe the problems that AOP addresses and how the principles of object-oriented design influence AOP and vice versa. If you're in the area, I hope to see you there.

I'm doing a tutorial on aspect-oriented design principles with examples in Java and AspectJ at OOPSLA this year. You can find a description here

I am pleased to announce the first release of Aquarium, an Aspect-Oriented Programming toolkit for Ruby. I created Aquarium to address a few goals that aren't adequately addressed by other AOP toolkits for Ruby. Most of these goals reflect the issues you encounter when using sophisticated aspects in large systems. First, the most important feature of any AOP toolkit is the "pointcut" language it provides, which is how you succinctly specify the "join points" across a system where behavior changes are required to support the "cross-cutting concern" that the aspect implements. Most people assume that Ruby doesn't need an AOP framework because its built-in metaprogramming facilities make method interception and wrapping easy. This is the "advising" part of an AOP toolkit. However, the real value of AOP is the modularity capabilities provided by the pointcut language. One goal for Aquarium is to match and even exceed the power of the AspectJ pointcut language. I also hope to make it as user-friendly as possible. Next, Aquarium seeks to handle the issues that arise when multiple advices are applied to a single join point, including precedence control. Another goal is the ability to add and remove advice dynamically. For example, you might want to insert troubleshooting advice in a running system, then remove it later when the issue is resolved. The first release already implements this feature, with some limitations. Finally (for now), I want to use Aquarium as a vehicle for experimenting with DSL implementation ideas. For several years, there has been discussion (started by Ivar Jacobson) of the idea that aspects share an affinity with Use Cases (or User Stories), because both concepts cross-cut the application domain object boundaries, in one sense or another. So, if I define a DSL that directly represents a user story, can I map it quickly and efficiently to the implementation objects using aspects? We'll see. There is extensive documentation at the Aquarium site. Please give it a try and let me know what you think!

I've started a series of blogs on AOSD at Object Mentor. The first is a blog on the the AOSD 2007 Conference, which was last week. I'm planning subsequent blogs on where I think AOSD needs to go next, AOSD in dynamic languages, and principles of good aspect-oriented design. Please join me there!

I'm presenting a paper at AOSD 2007 called Aspect-Oriented Design Principles: Lessons from Object-Oriented Design (PDF on the AOSD 2007 Conference web site). AOSD won't succeed in the mainstream unless it can be used to build software with the essential characteristics expected of production code, e.g., agility, extensibility, maintainability, and of course, quality. It shouldn't be too surprising that principles of good OOSD apply to AOSD. Conversely, ignoring those principles is a recipe for failure. In fact, I argue that some of the early problems people have encountered with aspects and software "evolution" are really just cases of not applying these principles. In this paper, I review 11 Principles of Good Object-Oriented Design, cataloged by Robert Martin, and discuss how they apply to aspect-oriented design (AOD), how aspects help implement them (e.g., by making it easier to achieve separation of concerns), how aspects introduce nuances into the interpretations of these principles, and finally, extensions of these principles unique to aspects. My hope is that writers of aspects will be more successful if they apply these principles and that AOSD will prosper as a result. I should warn you that the paper is written in a somewhat academic style, but hopefully the practicality of the principles will be clear. I'd love to hear your feedback! As time permits, I'll try to blog about these principles here, in a less formal style ;) By the way, if you're really interested in AOSD, I hope to see you in Vancouver at the AOSD conference, March 12-16. I will be teaching a half-day tutorial on AOD. Please join me!