Donnerstag, 6. Dezember 2007
Singleton in AspectJ
A general statement upfront: Singletons are often abused in Java as a simple accessor to a stateless tool-object. Mainly because most developer do not like to write Code like
new MyTool().doSomethingStateless();
which would create a new Instance of the tool. As they need only one instance they write:
MyTool().getInstance().doSomethingStateless();
There are several blogs entries and articles about the drawback resulting from this abuse of the singleton pattern, so I do not want to repeat them here. I strongly recommend not to use the aspect discussed on this blog entry for these purposes. I also recommend not to use AOP as a kind of code template tool. Please use it to improve and modularize the design of your application!

And even if you consider the original motivation for the singleton you are going to ask for problems on the java platform. One main reason is based on the fact, that you can have multiple classloaders in one JVM and each JVM can have its own singleton, so you normally have no (complete) control over the creation of exactly one entities of a singleton. Having said this, I found it still interesting to reason around the implementation details of a general singleton functionality in AspectJ.

Jan-Friedrich Mutter provided following solution
public aspect Singelton {
      private Object instance;

      pointcut create(): call(MySingelton.new(..));

      Object around(): create(){
           if (instance == null) {
                  instance = proceed();
           }
           return instance;
       }
}
on an mail thread of the Java User Group in Munich.
In this mail thread Andreas Wenger asked how to avoid writing the repetitive singleton code in an IDE.
Jan-Friedrich is right in his claim, that such a solution is asking for problems due to the invisibility of the added singleton property with the intention to avoid writing the repetitive singleton code.

So it is no wonder that this solution does only outline the way to go, but there are some shortcomings for practical code.

As mentioned above, simply use a singleton, if you want to control the number of the created object instances and not if you want to have a cheap access to a stateless worker object. If you REALLY want to control the number, you definitively have an additional crosscutting concern, which you should separate out of the original code base and aspects are really a good way for this task. And if you take the inherent requirement, that this aspect should be capable to add singleton functionality to a large number of classes, you will want to work with the well known pattern marker interface e.g. Singleton, or if you work with Java 5, you might use a kind of marker property. In both cases you end up with following code for the aspect:
public aspect Singleton{
	private HashMap instances=new HashMap();

	pointcut create(): call(SingeltonInterfaces+.new(..))
							||call((@SingletonType *).new(..));

	Object around(): create(){
		synchronized(this){
			Object key=thisJoinPointStaticPart.toString();
			Object instance=instances.get(key);
			if (instance == null) {
				instance=proceed();
				instances.put(key,instance);
			}
			return instance;
		}
	}
}
Now there is a hint in the code base, that the class is a singleton (either through inheritance) or through the property.

Please note also following interesting details in the codebase:
  • The synchronized statement inside the around advice, which is necessary to ensure that the singleton works also in a multithreaded application.
  • the thisJoinPointStaticPart.toString() call to distinguish, which singleton to create. A simple joinpoint can not be used here, because the constructor will be invoked from many places, and each place has a different source location so the static parts of the joinpoints are not equal, but their call destination is, and that’s all which is manifested in the string representation of the joinpoint.

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


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


Montag, 10. September 2007
The final program for the first Aspect Experience conference in Hersbruck is out.
Yes, the final program for the first Aspect Experience conference in Hersbruck (4/5th of october) is out.
I think the program is quite interesting. There is a really good introduction into AOP/AspectJ for the AOP newcomers, who like to code, in form of an code camp by Oliver Böhm. (The author of the only book in german over AspectJ) (Yes, it does last over the whole day)

For the people who like to discuss the concepts, there are at the same time several talks. (You should be able to flip between both tracks as much as you like):

  • First of all Stefans talk, where he discusses the concepts.
  • Then, we have Daniels talk, which discusses how to use AOP for productlines in embedded systems. I am personally convinced that AOP makes there more sense than OOP.
  • Then there is my talk where I will demonstrate the different general use cases, which I have seen over the time for the use of AOP. They go far beyond of the classical samples, which are patch and the classical crosscutting concerns (normally implemented by interceptions)
  • .
  • Then there is Jonas talk. He will demonstrate the power of AOP based products. (his presentation is based on Terracota, a fascinating system for high scalable systems, btw.) Even if you are only interested in clustering or Terracotta, it is a very good opportunity to meet him personally and ask him lots of questions.
  • Then, we will have some sound critical thoughts about AOP by Maximilian.
  • Then we have a podium discussion, where we will recapitulate all the important questions
  • .
  • And finally for day one, let`s enjoy the good local food (Schäufele), in a social event.
    (Btw. The famous Sausages (Bradwörschd like they are called here) are served during lunch for free)

And on day two, we will have a full day codecamp, concentrating on aspects to improve the quality of our system. We will discuss and write aspects to improve the quality of our systems out in production. Enjoy coding some aspects,

  • which provides some decent time out behaviour,
  • which might handle some overload conditions,
  • which free you with the task of doing resource management for youself,
  • etc. …

I hope you like the program. Let´s meet in Hersbruck.

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