Mohsen Vakilian's Blog

October 29, 2007

iXj: A Language for Interactive Transformation of Java Programs

Filed under: refactoring — mohsenvakilian @ 1:00 am

At first, I suggest you to watch a demo of iXj. There is no publicly available version of the tool, but the demo will give you a feeling of how iXj works. It’s great, isn’t it?

I read Marat’s PhD dissertation to find out the ways the tool can be improved. In the following, some properties of iXj and some ideas for its improvement are explained.

I believe the best improvement to iXj is making the patterns reusable. Currently, iXj has been developed with one-time use of patterns. By making the transformations reusable, it might be possible to capture all the transformations of source code concisely. Making the transformations reusable is a step forward to defining custom refactorings.

We know that the power of regular expressions is limited. If we want to use regular expressions as building blocks for refactorings, this limitation would become a major problem. Here is the author’s explanation about the power of iXj:

Clearly there are TXL and refactoring transformations that are not expressible in iXj. Notably, those transformations that require control- and data-flow information, such as the Extract Method refactoring, are not supported.

Now, let’s consider the idea of making the tool language independent more closely. In page 57, the author says:

Our experience suggests that designing custom models on a case-by-case basis is the right approach for building language-based tools. However, extracting model instances from source code text and maintaining the correspondence between various models is a topic for another dissertation.

This statement and other parts of the dissertation made me somehow skeptical about the language independence approach. By being language independent, one might only rely on text based transformations which is obviously not adequate for safe transformation of source codes. One solution to solve this problem might be to perform the transformation in two phases. The first phase would be language independent and the second phase would check for language specific features. In this way, the first phase could be reused to implement the transformation tool for different languages.

Several developers participated in evaluation of iXj. One interesting point that the participants made was that the best existing tool for doing their maintenance tasks is javac (the Java compiler). They say:

The Java compiler is the most ubiquitous for its ability to locate places in source code that are semantically or syntactically inconsistent after a change.

I think this statement emphasizes the importance of semantic analysis in such tools. Semantic checks are not so easy to apply to a specific language. Thus, considering a language independent approach would make semantic checks much more harder.

In iXj, patterns are composed of several boxes representing different elements of source code. Each box has a concept name which determines the structural role of each element such as package, method, type, …
I think these names can be inferred automatically from a grammar-like specification file. So, there is a possibility to make the tool language-independent in this regards.

However, there were subtle issues in iXj in using concept names for arguments of a method. In iXj, arguments are numbered respectively. But, I think it might be better to use the formal parameter names for the concept names as they give the developer a better clue.

Although iXj has been developed with a high emphasis on usability issues, there are still some opportunities to improve the ease of its use. For example, as it’s mentioned in the dissertation, users are not always sure whether they have used the right number of wild-cards. Users should have a way to find out if their pattern is general enough. One way to remedy this problem is to let the developer refine the pattern by example. That is, to let the developer add or remove matching instances so that the tool can automatically make the pattern more general or more specific accordingly.

In iXj, the developer can use demarcation for capturing groups in regular expressions. Demarcating in regular expression languages is provided by using “\( … \)”. These captured groups don’t have any specific name and they can be referenced according to their placement in the pattern (“\1”, “\2”, …). I think one of the reasons that makes regular expression hard to understand is the use of group capturing. Group capturing clutters the expression and the developer should look up the relative position of the group inside the pattern to refer to it. My suggestion is to let the developer draw boxes with names instead of using a special syntax. Boxes will make the pattern more visual and it conforms better with the whole model of iXj.

At the end, there are some minor issues that can be fixed easily. Effective use of coloring is an example of such improvements.


October 2, 2007

Expander—A New OO Construct

Filed under: design — mohsenvakilian @ 5:28 pm

Expanders introduced in a paper by Wart et al, are new constructs for Java to support object adaptation.

The idea of expanders was not so new to me for I’ve seen similar and simpler mechanisms in Ruby.
I think the exploratory study of Eclipse was quite promising. Although this study shows some shortcomings of eJava (Java + Expanders), it proves the usefulness of expanders in a large software which has extensibility as one of its most important goals of its architecture. Eclipse architecture has done a great job of incorporating all that extensibility. Eclipse architects would have had an easier job if they had eJava in hands!

Expanders are complex. As a proof, here are some rules about expanders:

  • “A method in an expander cannot override an ordinary method of the associated class.”, p. 3.
  • “We disallow overriding expanders from declaring members that are not declared in the top expander.”

However, ordinary developers don’t need to deal with expanders so much. Probably, those developers dealing with writing libraries and plug-in get the most benefit out of it.

The most important difference between expanders and regular methods of implementing the adapter design pattern is that in adapter design pattern the adapter introduces a completely new interface using an adaptee object. However, using expanders one just expands (i.e. adds methods, attributes, …) to adaptee. So, the adapter still supports the adaptee interface. And, this support of adaptee in the adapter might not be what the developer means when he says I’m using the adapter design pattern.

One might be interested to improve their work by adding the support of generics to eJava. Also, one might be willing to investigate if other constructs can be added for other design patterns.

My question is whether or not Dependency Injection frameworks such as Spring and Guice can do the job of expanders.

Blog at