Mohsen Vakilian's Blog

March 22, 2008

JunGL a Scripting Language for Refactoring

Filed under: evolution,refactoring — mohsenvakilian @ 12:45 pm

JunGL is a hybrid functional-logic language in the tradition of ML and Datalog. The main data structure manipulated by JunGL is a graph representation of the program. Edges can be added to the graph lazily

The following function in JunGL computes the control flow edges emanating from a conditional statement:

let IfStmtCFSucc(node)=
match (node.thenBranch,node.elseBranch) with
| (null, null) -> [DefaultCFSucc(node)]
| (t, null) -> [t; DefaultCFSucc(node)]
| (null, e) -> [DefaultCFSucc(node); e]
| (t, e) -> [t; e] ;;

In JunGL, one can use predicates in functions via a stream comprehension.

{ ?x | P(?x) }

will return a stream of all x that satisfy the predicate P.

Path queries are regular expressions that identify paths in the program graph.

? ==

In the above path query, components between square brackets are conditions on nodes, whereas parent and child match edge labels. The above predicate thus describes a path from a variable occurrence var to its declaration as a method parameter.

They implement Rename Variable and Extract Method refactorings in JunGL for a subset of C#. Some refactoings are complex and require various analysis. So, I didn’t expect their language for describing refactorings to be simple. However, it seems to me that they’ve made the process of defining refactorings easier by using features of both functional programming and logic programming. Actually, there are several systems for defining refactorings out there and one could evaluate them against real programmers and compare them.


March 16, 2008

Jackpot Rule Language

Filed under: evolution,refactoring,technology — mohsenvakilian @ 3:18 pm

Jackpot is a NetBeans module that lets you define custom transformations. Jackpot transformations can be specified in two ways:

  1. Using Jackpot rules matching program segments or
  2. Using Jackpot API to manipulate the AST.

The Jackpot API is still under development. The rule language has been designed by James Gosling. And, in the following we’re going to know more about the Jackpot rule language by explaining two examples.

The first rule, removes all unnecessary casts. In this rule, meta-variables such as $T and $a are used to match various program elements. As you see in this example, type matching facilities are supported in Jackpot as guard expressions after the “::” operator.

($T)$a => $a :: $a instanceof $T;

The second rule transforms a regular for-loop into an enhanced for-loop. This rule uses both meta-lists and built-in guards. The $stmts$ symbol is a meta-list which matches a list of statements. The expression referencedIn($i, $stmts$), is a built-in guard which checks if the meta-variable $i has ever been referenced in the meta-list $stmts$.

for(int $i; $i < $array.length; i++) {
$T $var = ($T)$array[$i];
} =>
for($T $var : $array) {
} :: !referencedIn($i, $stmts$);

Jackpot rules are readable and if somebody needs a more sophisticated transformation he/she can use the Jackpot API to programmatically perform the transformation. Jackpot seems to be suitable for cases when you want to migrate your client code to use a new API. However, it lacks constructs to specify the scope. So, it may not be appropriate for transforming the library itself.
In Jackpot, no flow analysis is done during execution of a rule file. And, in an interview with Tom Ball, the Jackpot team leader, he mentions that Jackpot cannot be used outside of the NetBeans IDE.

March 12, 2008

Google Gears Code Lab

Filed under: technology — mohsenvakilian @ 6:32 pm

On March 3rd, Google held a three hour long code lab on Google Gears at UIUC. The workshop had two parts: the first part consisted of a nice high-level presentation of Google Gears, its uses, architectural concerns, …

And, the second part consisted of a presentation on how to actually use Google Gears in our own code. Unfortunately, I couldn’t get Google Gears installed on my Ubuntu to follow the tutorial. However, I got a good idea of how Google Gears is used by following the slides. Indeed, it was a good opportunity for me to experience Javascript hacks for a couple of hours!

Continuous Integration in Open Source

Filed under: agile,evolution — mohsenvakilian @ 6:14 pm

Have open source projects increasingly been using continuous integration?

Dirk Riehle et. al. try to answer the above question in a paper entitled Continuous Integration in Open Source Software Development.

They considered 5122 open source projects from the database of the open source analytics firm

To come to the conclusion that continuous integration is being used in open source projects, they expect to see that the average size of code contributions, the individual check-in into a source code repository, would have gone down over the last ten years, and they would expect to see that the average frequency of such check-ins has gone up.

However, their analysis does not validate the hypothesis that open source software developers are practicing continuous integration. Their indicator, the average size of a commit, remained almost constant over the years with no significant trend or pattern.

One might argue that they should have categorized the projects based on the languages or the platforms they use as there might be some continuous integration tools available for one platform but not the other. Nevertheless, I think it gives enough evidence to prove the lack of continuous integration in open source software development.

So, why aren’t open source developers using continuous integration? Is it due to the lack of decent continuous integration tools for open source projects? Aren’t open source developers aware of the advantages of continuous integration? Is continuous integration useful for open source development at all?

The answer is not so clear to me. But, I assume we should give the community more time to adopt new technologies.

At the end, I’d like to emphasize the fact that one cannot conclude that a group is not agile for it’s not doing a particular agile practice. Kent Beck confirms my statement in an interview where he says:

“If somebody understood a bunch of practices and tried to do them, you could do agile development without being agile and it’s a disaster because you’re acting out of harmony with what you really believe when you do that.”

March 8, 2008

A Good Use of final

Filed under: design — mohsenvakilian @ 10:02 pm

The Template Method Pattern could be a case in which you might really want to use final methods.

“… They [Template methods] are particularly important in class libraries, because they are the means for factoring out common behavior in library classes.” [GoF]

In the template method pattern, it’s important to know which operations to override and which not. And, the final keyword in Java is a mechanism to achieve this.

Blog at