Add AddCommentToClass

[SiBorea]

What's changed?

Add a new recipe AddCommentToClass, similar to AddCommentToMethod

Checklist

• I've added unit tests to cover both positive and negative cases
• I've read and applied the recipe conventions and best practices
• I've used the IntelliJ IDEA auto-formatter on affected files

[sambsnyd]

What about JavaDoc comments?

[MBoegers]

To be fair, AddCommentToMethod does not support JavaDoc ;) But I 100% get your motivation.

[sambsnyd]

There are many different criteria one might wish to use to target comments. Path to the file, type being in use, something on the classpath, only for test sources, etc.

The recipe could try to support parameters for all of these or it could leave it up to Preconditions. For this specific case org.openrewrite.java.search.FindImplementations can be used.

[MBoegers]

Cool idea! But it's not that simple when inner types are involved. Concidder:

import java.util.HashMap;
                  
public class Example extends HashMap implements Runnable {
    @Override
    public void run() { }
    public class Inner { }
}

With a recipe like:

type: specs.openrewrite.org/v1beta/recipe
# ...
preconditions:
    - org.openrewrite.java.search.FindImplementations:
       typeName: java.util.HashMap
recipeList:
    - org.openrewrite.java.AddCommentToClass:
      comment: " Short comment to add"
      isMultiline: false

The result is unexpeted as the precondition is evaluated on CompilationUnit level.

    public void run() { }
-    public class Inner { }
+    // Short comment to add
+   public class Inner { }
 }

[MBoegers]

Adding a superclass and className to the existing solution and checking the implements, extends and type of the class declaration would be a good fit here. Plus, migrating from a String to a TypeMatcher is beneficial too.

[MBoegers]

Hi @SiBorea I have to request a few changes.

1. Have what if I want to match the Class by its FQN? For instance, add a Comment to all classes within a package or with a Suffix?
2. Have you thought about the handling of inner classes? They should not get the same comment if their containing class is matched.

To overcome these I suggest

• Use TypeMatcher instead of a String comparesion to check if it is the desired type
• Add superClass and className as options to enable advanced matching capabilities
• seems a little duplicated but opt out of a visitClassDeclaration if not all type options are meet (like preconditions).