Posted by Dean Wampler Tue, 04 Sep 2007 22:55:00 GMT
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.
Posted by Dean Wampler Tue, 04 Sep 2007 15:51:00 GMT
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
Posted by Dean Wampler Thu, 23 Aug 2007 22:18:00 GMT
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!
Posted by Dean Wampler Wed, 21 Mar 2007 16:30:22 GMT
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!
Posted by Dean Wampler Mon, 05 Mar 2007 00:57:00 GMT
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!
Posted by Dean Wampler Fri, 02 Mar 2007 16:03:00 GMT
A Contract4J5 user reported performance problems using Groovy. After some investigation, it appears that using the Bean Scripting Framework (BSF) increases the overhead of script evaluation by a factor of 3 or so! The overhead for script evaluation is already very high (roughly a factor of 7-10 times slower compared to no contracts). Scripting is expensive if used heavily, as it is in C4J!!
I’m not sure why BSF’s overhead is so high, but I’m going to implement support for Groovy and JRuby that bypasses BSF. This may take a while to complete, as I have a busy few weeks ahead.
The older non-BSF integration with Jexl is still in the distribution (although it’s currently marked as deprecated). If you want to use it, put the following code in your main or similar initialization methods:
Contract4J c4j = Contract4J.getInstance();
ContractEnforcer ce = c4j.getContractEnforcer();
ce.setExpressionInterpreter (new JexlExpressionInterpreter());Correction: You can also use the properties file configurator or the Spring configuration file options to specify Jexl without the BSF wrapper.
You’ll get warnings that JexlExpressionInterpreter is deprecated. You can safely ignore them. I’ll remove that javadoc tag in the next minor update.
Longer term, I’m trying to improve the use of caching to further reduce the overhead of C4J.
Posted by Dean Wampler Sun, 25 Feb 2007 15:31:00 GMT
There was a recent post to the aspectj-users group from “Frustrated Newbie” who was trying to write adeclare error that would enforce the requirement that all classes implementing one interface, let’s call it Foo, also implement a second interface Bar. He tried something like the following:
declare error: within(*..Foo+) && !within(*..*Bar+):As an experiment (which he tried…), if you drop the second expression, leaving just within(*..Foo+) you get an error just on the Foo interface, not on any implementing classes or extending interfaces.
..foo and ..bar, respectively, the following does work:
declare error: within(*..foo.*+) && !within(*..foo.*) && !within(*..bar.*+): !within(*..foo.*) prevents errors on the interfaces in package foo itself.
This isn’t especially obvious and you may find it inconvenient to package your interfaces like this, but it does work. Actually, there’s a good case to be made for putting interfaces in separate packages like this, based on the Stable Abstractions Principle (PDF, see also here).
Posted by Dean Wampler Mon, 01 Jan 2007 00:38:00 GMT
I just released v0.7.0 of Contract4J5, which now supports Groovy and JRuby as alternative scripting languages, in addition to Jexl, the original language used. Along the way, I collected some performance numbers for the three alternatives.
The following discussion is adapted from the README for the v0.7.0 release.
I ran the JUnit test suite with all three languages. The numbers below show the performance when using binary weaving and load-time weaving (LTW) and also the performance using the JVMs in JDK 5 and JDK 6.
| JDK 5 (sec.) | JDK 6 (sec.) | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Jexl | Goovy | JRuby | Jexl | Goovy | JRuby | ||||||
| Binary | LTW | Binary | LTW | Binary | LTW | Binary | LTW | Binary | LTW | Binary | LTW |
| 21.7 | 98.6 | 54.9 | 324.4 | 79.6 | 189.4 | 17.7 | 62.9 | 44.8 | 133.5 | 63.2 | 108.4 |
These times are approximate “user times”, averaged over a few runs, measured on a ThinkPad T42 running Ubuntu Linux. There are slightly different build activities and I/O overhead involved in the LTW numbers, adding a few percentage points to the numbers. The tests do some different manipulations depending on which interpreter is used. Hence, the results are rough, at best. Most likely, the numbers reflect the relative amounts of overhead to load the interpreters and to set up the “environments” for evaluating the scripts, which happens frequently in the test suite. Since the scripts are always very small, evaluation is probably not a large percentage of the execution time. (However, this is speculation!) Your mileage may vary…
Note that the JDK 6 performance is significantly better. The code was compiled
with the JDK 5 javac and executed using the JDK 6 JVM. Ironically, the performance was slightly slower when compiled with the JDK 6 javac. (This is not reflected in the numbers)
The Jexl test runs are roughly twice as fast as the Groovy and JRuby runs, probably because Jexl is a more “minimalist” environment, incurring less startup and execution overhead.
While not shown, I observed that the memory requirements for Groovy and JRuby are also higher, as you would expect. I didn’t actually measure memory usage, but I observed this because it was necessary to increase the maximum heap size for the LTW JUnit run when using Groovy or JRuby. Also, when using JRuby, I had to increase the heap size for the binary-weaving JUnit runs in Eclipse.
The LTW test runs take significantly longer, but the results are somewhat hard to interpret. Under JDK 5, the Jexl and Groovy runs are five to six times longer, while the JRuby runs are only about 2.5 times longer. Under JDK 6, the Jexl and Groovy runs are a little more than three times longer, while the JRuby run is under twice as long. It is not clear why JRuby LTW configurations perform so much better under both JDKs. However, it is clear that, for all the interpreters, the startup byte-code instrumentation required for LTW is much better under JDK 6.
In general, the longer LTW times occur because a weaving step happens at the beginning of each TestCase, as the class is loaded. The JDK 6 speed-up is a good argument for running this VM, at least for your tests!
LTW is the most convenient way to adopt Contract4J5 (true for other aspects, as well), but if the startup time is too long for your needs, then binary weaving of compiled code provides better performance with only a modest change in your build process.
Posted by Dean Wampler Mon, 01 Jan 2007 00:19:00 GMT
I just released v0.7.0 of Contract4J5. This release adds support for using Groovy or JRuby instead of Jexl as the scripting engine for the test scripts embedded in annotations. In fact, Groovy is now the default.
The advantage of Groovy or JRuby is that they provide a richer environment for more sophisticated testing. They are also better suited for planned, long-term enhancements of Contract4J5 to support user-configurable annotations and behaviors, which will take the tool beyond Design by Contract support.
The only major disadvantage over Jexl is lower performance. I’ll blog about those results next. You can also find details in the README.
I was pleased to find that all but a few of the existing Jexl-based unit tests worked without modification for Groovy. With a few hacks, I got them to work for JRuby as well. The differences for Groovy include slight differences in how Goovy vs. Jexl handle protected access (private, protected, etc.). Also, Groovy does not force you to provide a public accessor to evaluate tests on member fields, which Jexl required.
For JRuby, I found that almost all Ruby vs. Java differences could be handled if I did a few simple replacements of the most common Java idioms in scripts with the corresponding Ruby idioms:
equals(...) with eql?(...)compareTo(...) with <=>(...)null with nilThat is, Contract4J5, when using JRuby, will make these substitutions in your test expressions so they work, most of the time, even though they are written in Java syntax. This tends to work because the test expressions tend to be relatively simple and they often consist of comparisons to null or calls to String comparison methods.
Posted by Dean Wampler Tue, 24 Oct 2006 13:43:00 GMT
I got sufficiently frustrated with Windows that I installed Kubuntu on my Thinkpad in a dual-boot configuration. (I’ll have to use Windows occasionally.) This will give me a real developer’s OS while I wait until I can justify buying a Powerbook. ;)
Linux as a desktop OS could really replace Windows, if it had the polish that Windows and OS X have. (Yea, I know that there are a lot of enterprise apps that aren’t compatible…) I still haven’t gotten my laptop to talk to my WiFi router that’s using WPA for security. Also, there are way too many configuration options and the out-of-the box “look and feel” is ugly, even while much more attractive options are a few (hundred?) clicks away. So, it’s still way beyond the capabilities of the average computer user to use Linux on the desktop, IMHO.
It’s been getting better, though, and the Ubuntu project, in particular, is promising. Hopefully, linux will still grow as a desktop OS, although I suspect that most companies and individuals who can drop Windows will chose OS X, instead.
