Felipe Gaucho's Blog

March 2006 Archives

A trip to Nancy/FR

Life is a movement experience... and one more time the destiny gives me a rare privilege of knowing other countries, other cultures. In the next few months I will live in Nancy / France. My wife received a PhD schoolarship for six months at University Nancy and we are moving to there on April, 1.

Despite Google Earth and other web sites about Nancy, I know almost nothing about that city and less yet about its technological scenario. It will be a new challenge: to observe how french people live, including sports, food, music, etc. And also observe the Java presence over there.

Since I can't get a working visa, I will enjoy this vacation-like period to learn the new trends in Java - such as EJB 3.0, Glassfish, SOA and other topics. It will be a great chance to read a lot, to learn a lot, and asap I will post my new apprentice here.

That's it, I'm going to take a plane now... ;)

Creating Eclipse Warnings with AspectJ

Debugging with println is an ancient habit in programming - even the novice developers know about how fragile is such strategy facing the robust debugging tools provided by the most common IDEs. Despite that, everybody sometimes includes some commands like System.out.println("step #1"), or System.out.println("remember to remove this...") . The code smell gets unveiled when a client observes his console printing friendly words like this is just a test or even worst when a system administrator opens a server log and finds hundreds of debug lines printed with undeciphered numbers and letters. The most common strategy to avoid such programming deviation is to use guard tools like Checkstyle and PMD. These tools are excellent vigilants on the best practices of the code-style and patterns usage - but they seem weak facing non-Java concerns like the disabling println policy.

On the Cejug-Classifieds Project, we have made some experiments with the creation of an Eclipse Warning to detect the usage of the println into the code. Every time a developer type System.out.prinltn(...) the warning icon appears beside his code - and we are very proud about the zero-warning status of our code. One can ask why do not simply require the developers to adopt the project code-style?. The answer is simple: it doesn't work, never worked and I don't believe a human being is able to obey such non intuitive rules whithout an ubiquitous advisor. The code-style maintenance can be a very boring task and every time a developer becomes tired he will try to get past the rules. An IDE guard can be (and must be) a good friend of the developers. The image below shows an example of warning generated when the developer types println anywhere on the code:

Image 1: The Eclipse Problems View

Creating an Eclipse Wrning with AspectJ

The decision about using a pure Java implementation, based on annotations, or about using an external tool like AspectJ is very controversial (1, 2, 3, 4, ...). I will leave this discussion to a further blog entry - for now I will simply enumerate the steps required to create a new warning on the Eclipse IDE.

• Download and install your preferred flavor of the Eclipe 3.1.+ (I'm using the WTP 0.7).
• Use the Help/Software Update feature to be sure you have the AspectJ installed in your Eclipse.
• Create a Java Project.
• Right Click on the project name and choose Convert to AspectJ Project.
• Done! You are ready to start to write the aspects definitions.

A demonstration Project

For a demonstration, I created a simple project with just one class and one aspect definition. The project can be downloaded here. Just download the demo and use the Import feature for assembling the project into your Eclipse. A tip: after installing the project on the eclipse, type some println commands on the test class, and observe the behaviour of the IDE.

Below is the aspect code used in the example project. Note the call(* *.println(..))) - this command indicates that every println command executed by the JVM will be intercepted by the aspect definition. Other interesting code fragment is the warning definition, which declares a warning guard for the Eclipse View.

	package net.java.dev.aop;

	public aspect Test {
		/** Everything outside the aspect package. */
		pointcut not_aspect(): !within(net.java.dev.blogger.aop..*);

		/** Pointcut to get any 'println' occurence (except in aspects). */
		pointcut all_print_not_aspect():
			(call(* *.println(..))) && not_aspect();

		/** A warning definition. */
		declare warning : all_print_not_aspect() :
				 "Sorry, we can't use println in our project";
	}

Simple, isn't it? Not that much, the above example is just a bit of AOP. More sophisticated controls over the code, including complete use cases implementations are deeply discussed for a while by the software community. The aim of this blog entry is just registering an approach we are adopting in our project to try a better code-style and to evaluate its impact on the day by day of developers. Cejug-Classifieds has a lot of aspect definitions right now, and we would like to invite you to visit our project and to test by yourself - your feedback is very important to us.

This work is licensed under a Creative Commons License.