I returned to the Hilton (Continental Ballroom 4) to attend Jan Lahoda's (Oracle/NetBeans) Birds-of-a-Feather presentation "Custom Static Code Analysis." I have previously blogged on a subset of the functionality covered by Lahoda in the post Creating a NetBeans 7.1 Custom Hint. In that post, I looked at writing custom hints for NetBeans using the custom declarative refactoring language that Lahoda discussed in his presentation.
Lahoda explained that the Custom Declarative Refactorings Language was founded in 2000 to "improve IDEs and the way developers develop." NetBeans 6.0 (announcement) adopted its write model in 2006 and it was revived for NetBeans 7.1 with Project Jackpot 3.0. It is an AST-based custom Java-like DSL language that "allows to define refactorings (almost) declaratively." It can be used to "check for anti-patterns" and to "determine how many clients call a particular method for a specified context."
Jackpot can be run outside of the NetBeans IDE on the command line using the Jackpot Standalone tool. Lahoda stated that this standalone command line based tool can even apply NetBeans warnings.
Lahoda had several slides covering options and syntax for specifying the static code analysis rules. The information on many of these slides is available in the JavaDeclarativeHintsFormat Wiki page that Lahoda referenced. Lahoda also referenced online Jackpot 3.0 Examples.
Lahoda provided a template of how the declarative hints language works:
<source-pattern> :: <conditions> => <target-pattern> :: <conditions> => <target-pattern> :: <conditions> ;;
Lahoda stated that you can place "any number of such rules in a file" and then place the .hint file in META-INF/upgrade. See Geertjan Wielenga's post Oh No Vector! about this particular detail.
Patterns were another subject Lahoda covered in his presentation. He had a bullet stating that patterns can be applied to "Java expressions, statements, classes, and methods." He explained the significance of $, which in front of a pattern means substitution of one thing and with one at the end means multiple instances of that thing. Here is the rules using $ for patterns that he showed on his slide:
| Statement | $statement $statements$ |
| 0 or 1 | if ($cond) $then; else $else$ |
| Modifiers | $mods$ $type$ $variableName; |
| Multiple Catches | try {} $catches$ finally {} |
Lahoda covered conditions. He stated that there are three types of conditions: language (instanceof, otherwise), standard (predefined), and custom. A condition result can be negated (!) and && works on condition results.
Lahoda's example of using instanceof is shown next (evaluates to true if expression bound to $variable is of type <type>):
$variable instanceof <type>
The otherwise keyword is used when designating fixes and is true when no other fix is available for a particular rule.
Lahoda stated that "like method invocations" are of the form:
hasModifier($variable, PRIVATE)
Lahoda concluded by reminding the audience of situations in which this approach to custom static code analysis might be useful:
- NetBeans custom refactoring to check for antipatterns
- Checking for violations during continuous build
- Producing standard NetBeans warnings
When I wrote my post Creating a NetBeans 7.1 Custom Hint, one of the biggest challenges was finding documentation outside the sparse online NetBeans documentation regarding use of the custom rules language. Lahoda's presentation and the newer Wiki pages and other documentation he has been a major contributor to in recent months have helped to reduce this hurdle. This is one of several things I've seen or heard more about at JavaOne 2012 that I hope to blog on in the future.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}