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.

February 6, 2008

Automatic Change Inference

Filed under: evolution,refactoring — mohsenvakilian @ 12:12 am

The research question addressed in this paper is:

“Given two versions of a program, what changes occurred with respect to a particular vocabulary of changes?”

Of course, we are looking for higher level approaches for reporting changes than traditional diff tools which define a change vocabulary in terms of delete, add, and move line.

Miryung Kim et al., presented their approach for change inference in a paper titled “Automatic Inference of Structural Changes for Matching Across Program Versions“.

By the following example you can get a feel of how the output of their tool looks like:

for all x in chart.*Plot.get*Range()
except {chart.MarketPlot.getVerticalRange}
argAppend(x, [ValueAxis)

This change rule, means that all methods that match the chart.*Plot.get*Range() pattern take an additional ValueAxis argument, except the getVerticalRange method in the MarkerPlot class.

As shown in the above example, their approach represents structural changes as a set of high-level change rules, automatically infers likely change rules and determines method-level matches based on the rules.

The set of transformation that they support are (1) refactorings such as rename package/class/field/method, add parameter, … (2) other transformations such as change argument types, change return types, change input argument list, …

They did a good job of printing the change rules in a concise manner. As they mention, the except clause sometimes signals a bug arising from incomplete or inconsistent changes.

I think more types of transformations should be taken into account for better descriptions of changes. Besides, one might try to handle changes due to refactorings by just recording them while they are being performed rather than trying to infer them by comparing the two versions of program.

February 2, 2008

Subclipse Annotate View

Filed under: evolution — mohsenvakilian @ 5:26 pm

The SVN Annotate View is part of the SVN Repository Exploring Perspective and allows you to review the revision history for a specific file, right down to the individual line of code. As illustrated in the figure, The view is comprised of three distinct areas:

  1. The first pane shows a list of all the individuals that have changed this file along with the revision number and the total number of lines changed as part of that revision.Subclipse Annotate View
  2. The Eclipse text viewer showing the contents of the selected file at the head revision.
  3. The History View for the selected file.

The History View contains the list of all changes made to the selected file. For each change, the svn log and the list of all files affected in that commit are shown.

The History View and the view of the file contents are dynamically linked to the revision panel. Left clicking an entry in the revision pane will highlight all of the lines that were modified in the file in the text viewer. In the same way, when a line in the text viewer is selected, the revision author will be highlighted in the revision pane. The History View is automatically updated to provide the full details of each revision selected.

Subclipse Quick Diff

Filed under: evolution — mohsenvakilian @ 5:06 pm

Instead of using a compare editor, which will show changes between 2 or 3 files by showing each file side-by-side, you can enable quick diff support and see the changes within the text editor.

If you enable showing the differences in the overview ruler, you can, at a glance, get an idea of how many changes you have Subclipse Quick Diffmade to a file since your last commit. As shown in the figure, the overview ruler is segmented such that each segment corresponds to a change made by a developer. The darker a segment is the newer the change is. If you hover over a particular segment, the svn log of its corresponding commit will pop up.

Subclipse Compare

Filed under: evolution — mohsenvakilian @ 4:22 pm

Subclipse is an Eclipse Team Provider plug-in providing support for Subversion within the Eclipse IDE.
In the following posts, I’ll mention some features of Subclipse that I found interesting in investigating the history of changes made to a software code base.

The Subclipse Compare tool shows the differences among the selected files in two views: Java Source Compare and Java Structure Compare.Subclipse Compare
As show in the figure, the Java Source Compare pane is much like ordinary diff tools in the way it shows the differences by connecting a piece of code in the new version to the corresponding one in the old version.
The Java Structure Compare pane gives us an overall view of how the selected class has evolved. You can tell from the figure what methods have been added and removed from the class. I found the idea of showing changes in a high-level structural view interesting. However, I think more can be done in this regard to give the developer a better understanding of changes. Please feel free to leave your comments on how the Subclipse Compare tool can be enhanced.

Update: As Mark Phippard (the project lead for Subclipse) stated in his comment, the Compare Tool is part of Eclipse itself. I was merely explaining the kind of features one gets by installing the Subclipse plug-in for Eclipse. Therefore, I was careless about making distinctions between components provided by Eclipse and those provided by Subclipse.

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.

« Previous PageNext Page »

Blog at