Creating a metric for a custom rule in Java

[NathanMacDiarmid]

I am wondering how you would go about creating a metric to be used in a custom rule. We currently have a way to detect and collect the data that we need, but we are having trouble adding the violation in the correct spot as PMD only parses the tree once.

Is there a way that we can collect all this data as a metric then call it statically within the custom rule? Or is there a way that we can force PMD to parse twice and take in these data points?

We are using a stripped down version for Java rules specifically that can be found here - https://github.com/pmd/pmd-examples/tree/main/custom-rules/maven-java

[jsotuyod]

No, PMD doesn't support this currently. We have some proposals in the backlog to tackle this eventually (#3920), but won't happen before PMD 7.0.0 at the earliest.

[NathanMacDiarmid]

Ok thanks! Are there any work arounds that we could do for now? As stated earlier, we have a way to measure but need to compare it. We are doing shotgun surgery from the textbook - Lanza. Object-Oriented Metrics in Practice and calculate changing methods (cm) and changing classes (cc).

[jsotuyod]

Hacks for sure. You can track data in the rule application, store it in a static variable (be careful with thread safety, rules are expected to be thread safe, usually by being stateless), and then creating your own Report implementation and do error reporting there (report classes can be included in plugins and used through fully qualified names when launching PMD). This however will fail with incremental analysis, so you won't be able to use it.

[NathanMacDiarmid]

Hi sorry for the late reply, we were able to find a way to track the metrics that we needed. We needed to keep track of methods that were called by other methods so we stored the ASTMethodDeclaration nodes in a hash map along with how many times they were called by other methods. Hopefully this helps for anyone looking to do the same thing.

[jsotuyod]

Glad to hear that, but I must warn you against keeping the AST node itself, as it will prevent garbage collection for the whole AST tree + the underlaying document for all analyzed files, so this is going to be very memory intensive and may produce issues with larger / more complex codebases. PMD 7 makes this significantly less dramatic than PMD 6 did, but nonetheless, if you can get away with keeping the method's fully qualified classname + signature that should be significantly better.