A Little Language
I have been getting some comments regarding the limits of Jackpot's rule language which suggest that Jackpot itself is not very powerful or useful. I must therefore be at fault for not making it clear that the rule language is a "little language"; it was never meant to be a complete transformation language for Java, but instead was designed to be an easier way to describe many of the more common types of transformations possible with Jackpot. Mark Grand, the author of Patterns in Java, Volume 1, A Catalog of Reusable Design Patterns Illustrated with UML, describes the Little Language design pattern this way:
While the Jackpot API can be used for all kinds of source transformations, the rule language was created to facilitate conversion of large sets of methods, such as updating projects that use deprecated methods in the Java core libraries. The general rule is that a programmer will do the same task several times, but will soon write a program to do it before he or she dies of boredom. The AWT alone has over a hundred deprecated methods, so multiple the writing of 10-20 lines of code for each method and you'll see why the task quickly lost its appeal! Using a table to map old to new methods was considered, but that idea was quickly discarded because frequently the method signatures were different (a simple example is converting "
So a little language was created which uses Java fragments along with meta-variables (wildcards) to transform statements, along with guard expressions to utilize the type information in the underlying model to restrict transformations safely. It may seem initially confusing since the language looks a lot like Java, but once all those dollar signs are explained, most Java developers immediately grasp its syntax. I hope any enhancements to this language keep the current simplicity.
Many people have asked why a pattern language such as XPath wasn't used. There are two reasons; the first is a minor one in that the rule language doesn't require new developers to learn a large set of tree node types
(the Tree API has forty-nine). The second reason is more important: Java isn't a single language, but a progressive set of languages with subtle (such as assert statements) and not-so-subtle (generics, enums, annotations, etc.) enhancements between versions. The "-source" flag your project passes to javac actually tells it what sort of syntax tree its parser should create, as those trees can be different for different source values. So an XPath expression will work fine for single tree fragments, but the more elements in your path, the greater the chance that your expression won't match as expected. Jackpot uses the project's source level when compiling the rule file, so potentially different compiled matchers will be applied to projects with different source levels.
So if the rule language has these limits, what good is it? If you have installed and run Jackpot, the answer is hiding in your home directory where a ".jackpot" directory has a cache of the Java and class files created when a rule file is compiled. If you browse the generated Java files, you will see that all the rules are combined into a single switch statement; this allows matching to be done in a single pass so rule files scale well for large rule sets and large projects. It saves a lot of coding, too: SimplifyBooleanExpressions.rules, for example, has 45 rules which generate to a 657 line Java file.
Based on feedback the language has grown to what it is today, and we encourage more feedback on how you think it can best be enhanced. And if you have a great idea for a transformation which the rule language doesn't support, don't give up! The Jackpot API lets you create it without rule file limits, as these examples demonstrate. Plus, it's a whole lot easier to code-review a rule than its equivalent compiled code.