Freitag, 12. Oktober 2007
Aspects of Models
Some time ago I spoke on the MDD&PL conference in Leipzig for Senacor. The conference was going around Model driven Development and product lines. Interesting and a very mature topic.

Don’t get me wrong I haven’t converted into an MDD or even worse MDA zealot. I am convinced that MDD and maybe even MDA is an important tool in the tool chest of any good software craftsman and should be used wherever appropriate. I have used these modelling and generation techniques in the past and found them very useful. ON the other side I have witnessed several projects, where they simply didn’t fit. Simply use the right tool for the right job.

There is a great article titled MDSD and AOSD (in the format of a pattern language) in slightly different versions out there from Markus Völter, where he describes great usages of Aspect Oriented techniques in the viewpoint of MDD in the context of product lines. The articles are at least two years old and demonstrate significant value which AO can bring to the MDD communities. Markus is a great guy and normally some years ahead of the crowd, so I was not sure, if these usages were at then time “mainstream” in the MDSD/MDD world.
For me it seems that these techniques are now best practices, as most of the speakers recommended roughly the same usage scenarios of AO in the context of MDD as Markus.

The recommended usages were:

  • Using an AOP language constructs like advice in the transformation template language
  • Using MDD as “a poor mans replacement for AOP”, where there is a cure AOP platform not available or not suitable.
  • Using an AOP platform as a higher level platform and therefore simplifying the transformation
  • Using an AOP to simplify the transformation development process
  • Using some kind of multi dimensional modelling, and using some equivalent to pointcuts to bind the different modelling dimensions together

Nice, that these practices are nowadays considered best practices. Let’s wait till the idea to use AOSD to create a more composeable architecture for product lines get there also.

... link (0 Kommentare)   ... comment


Dienstag, 13. März 2007
The pig-farm metaphor again
Grandma Beck: "If it smells, fix it."
She is right. But, if you do not smell the smell anymore, how do you know, that you have to fix it?
Imagine you move to a pig farm (or close too). The first day you think it smells incredibly, the second day, you only recognize that it smells, ...
and after some weeks you do not recognize the smell anymore. If somebody comes to visit you and he says "It smells incredibly, you sniff twice, "Yes you are right", and continue.
Exactly this happens in code. I recognized this fact in the 90ties.
Knowing that fact I never got used to smelly code, which finally brought me very early in the AOSD community and was the root cause for my very early adoption of AOSD in commercial projects.

I presented this nice little metaphor in my talk at AOSD 2002 in Twente, at that time I wanted to express, that we need AOP to fix smells in the code, and that most developer doesn’t recognize the smells again.

Yes you are right, this is all old stuff, but I recently recognized that this apply in the same way, to a lot of other important disciplines in software development as well.
•Non Agile software development is one,
•to project planing and to software architecture are others.,
•incomplete testing might be the most popular one nowadays.
I currently wonder which problem we have to tackle first?

... link (0 Kommentare)   ... comment


Dienstag, 23. Januar 2007
Eliminating Awful API calls
Some days ago, I witnessed again a large bug caused by the use of the String.toByte() and new String(byte[]) . These methods belong to the sets of methods, which I believe should have never been part of the core APIs. Why?
Ok, they are fine for most hacks. Ok, they are most often acceptable for some server code, which gets called from an equivalently configured JVM running on the same machine. But they cause normally great trouble, when they get called from a different application, which uses for some obscure reason a different default codeset than you. Unfortunately, you might not even notice it, because you might not test with some of these characters, even if you are outside of the English speaking world. E.g. your tester might always use his personal name and his personal address as input in the customer field and unfortunately his name and address does not contain any of these critical characters. Even worse, you test, everything works fine, and three weeks later you discover the big issue, your client has changed the codeset silently, maybe he didn’t even notice it. Now you have to write cleanup code, which cleans up parts of the database, etc. …
You do not believe me. Ok simply try, running following short codefragments:
private void foo() throws UnsupportedEncodingException {
    String initial="ä";
    byte[] initialbyte=initial.getBytes();
    System.out.println(new String(initialbyte,"UTF-8"));
    System.out.println(new String(initialbyte,"ISO_8859_1"));
    System.out.println(new String(initialbyte));
		byte[] correctbytes=initial.getBytes("UTF-8");
    System.out.println(new String(correctbytes,"UTF-8"));
    System.out.println(new String(correctbytes,"ISO_8859_1"));
}

I prefer to avoid these issues. I insist therefore on using explicitly correctly defined encoding, and I like to be informed whenever someone from my team does use the shortpath of avoiding setting the correct encoding. However, I do not like to scan the complete codebase after this issue. Please compiler inform me. Thanks, AspectJ does help me here, more than one.

I simply define a simple aspect, which generates some warnings whenever the toString(bytes[]) or .getBytes() method is called. Following classical aspect does this for me.
public aspect EncodingWarner {
	declare warning:
		call(public String.new(byte[]))||
		call(public byte[] String.getBytes()):"Please use the encoded versions, for more details visit http://arno.blogger.de/stories/672953";
}
I normally have a lot of these simple enforcement aspects lurking around in my code. On some projects I suggest not even to use warnings, simply use errors. It is sometimes necessary to force some of the developers to produce high quality code and avoid sloopy fast-paths in the API, which are dangerous in the context of your applications, but which may be fine in other.
This is my simple way, to ensure that no critical APIs are called.

... link (0 Kommentare)   ... comment


Freitag, 15. Dezember 2006
Throwing Exceptions unchecked
I like brain teaser, especially programming brain teaser, throwing checked Java Exceptions from a method which does not declare them is one. In other words, have a java method, which throws an exception without declaring it. How is this possible? Exception declaration is only enforced by the Java language and not by the virtual machine. The JVM does not guarantee anything in this respect.

Yes you are right, such a kind of code is very dirty, it is very smelly. I normally refuse to think about such smelly code, except there is an even stronger justification for exactly that kind of code. This week I ran in such a justification, I was writing some small classes for the Nürnberger Fremdsprachenschule (http://www.nuernberger-fremdsprachenschule.de) and I wanted to set up some regression test scenarios for them.
You can guess, as an old AOSD man, I wrote a small AspectJ aspect to capture the data for the regression test, and I wrote a second one for the replay of the captured data and the mocked objects. Here I had to write an around advice, which captures some method execution, and throws a checked exception (e.g. SQLException).

Advice are just methods, (another theme for another blog at some other day), and like any method an AspectJ-advice has to declare all checked exceptions, which it may throw. Unfortunatly this exception list has to match with the declared exception list of all joinpoints, where this advice will be bound to. (This is IMHO a design flaw in the AspectJ language)

In other words:
If you have an advice, which declares to throw a checked exception (e.g. SQLException), you can bind this advice only to places where the Java language can accept the checked exception. (e.g. at call-joinpoints, where a method is called which might throw SQLException). However this advice can not be bound to places, where only “SomeOtherCheckedException” is handled correctly.

For specific aspects, which are closely bound to the domain logic, this behaviour is fine. You should only throw exceptions, which can happen at this join point anyway. (A kind of AOP-Liskov substituion principle.)

However when you often write infrastructure aspects, like I do, you will run often in scenarios, where you catch some generic exception, (You do not care, which type of exception it is), then dosomething with the caught exception, and finally you want to rethrow the exception.) These scenarios are really very common in infrastructure aspects and interceptors. The logic of the advice and the aspect binding mechanism ensures that only a legal exception may be thrown.

However it is very hard to write such an aspect reusable in AspectJ. You have following choices:
  1. declare the advice to throw an instance of Exception or even Throwable. However this approach has one central drawback. You can apply this aspect only to places in the codebase which do declare to throw an instance of the class Exception. Or you have to work heavily with declare soft.
  2. Duplicate the aspect/advice for all relevant exceptions. This approach is creating a duplicate code nightmare.
  3. Use a common exception base class through the project. I advocate this approach anyway, but it is normally not applicable to legacy code bases and these aspects can not be reused between different projects/ customers.
  4. Find a well defined localised and modularized hack, which cheats the AspectJ compiler, Not the ideal way, but IMHO the best option.
Knowing one solution of the puzzle, it is easy to write a little testcase and implement the solution, hide it behind a library method and have now a clean solution for further reusable library aspect methods.

Oh, you are interested after the solution. I will not tell you the complete solution here in my blog, because I am convinced, that if you want to invoke such a “dirty” method, you should have a clean motivation to do so or you must know what you are doing. In either case it is reasonable to ask to invest some brain in the valid solution or look up the solution in the great book “Java Puzzlers” by Joshua Bloch and Neal Gafter.
However, here is one hint for one possible solution approach:
Use Reflection (And here is a more detailed hint : Class.newInstance() can throw any exception) alternatively you may have a look in Blochs Java Puzzlers

Lesson learned for new AOP language designer:
If you design an AOP language for the Java platform, do not insist on the strict exception checking rule of the Java language in the method bodies of advices. Please find a more lenient one.

... link (0 Kommentare)   ... comment