Recipe ReplaceAWTGetPeerMethod in Java 11 Migration

[ranuradh]

What's changed?

This PR contains recipe - org.openrewrite.java.migrate.ReplaceAWTGetPeerMethod
Rule:

What's your motivation?

This custom recipe replaces the use of getPeer() method in the java.awt.Component, java.awt.Font, and java.awt.MenuComponent classes and direct known subclasses. The occurrence of (component.getPeer() != null) { .. } is replaced with (component.isDisplayable()) and the occurrence of (component.getPeer() instanceof LightweightPeer) is replaced with (component.isLightweight()).

Anyone you would like to review specifically?

@timtebeek
@cjobinabo

Any additional context

Since I couldn't test the recipe I am attaching the rewrite.patch along with the Test that tests using similar invocations
rewrite.patch

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

[timtebeek]

Hi @ranuradh ! Thanks for yet another recipe. I'm working my way through and I'm wondering what IDE settings you're using. You had checked the box above that you applied the formatter, but when I do the same locally I still got quite a bit of changes, as seen in deb96c3 .

Additionally, I see quite a bit of warnings in my IDE about nullability handling & casts for instance:

Ideally we'd have none of those issues on recipes that we add to our catalog, such that any new issues in the future stand out when we maintain these recipes. Would you mind sharing and perhaps adjusting your settings? We use IntelliJ defaults where possible.

[ranuradh]

Hi @ranuradh ! Thanks for yet another recipe. I'm working my way through and I'm wondering what IDE settings you're using. You had checked the box above that you applied the formatter, but when I do the same locally I still got quite a bit of changes, as seen in deb96c3 .

Additionally, I see quite a bit of warnings in my IDE about nullability handling & casts for instance:

Ideally we'd have none of those issues on recipes that we add to our catalog, such that any new issues in the future stand out when we maintain these recipes. Would you mind sharing and perhaps adjusting your settings? We use IntelliJ defaults where possible.

I am not sure what is going on probably have to update my IntelliJ - I use the following -

I will recheck next time

[ranuradh]

Hi @timtebeek am taking a look at ur suggestions and will update the PR

[ranuradh]

Hi @timtebeek would like some clarification here:
For the cases where we don't have ControlParentheses. Here is the code snippet for before and after

            """
              class Test {
                  void foo() { 
                      Component1 y = new Component1(); 
                      boolean instance = y.getPeer() instanceof TestDummy;
                      if (instance){
                      }
                      boolean instance1 = y.getPeer() != null;
                      if (instance1){
                      }
                  }
              }
              """,
            """
              class Test {
                  void foo() {             
                      Component1 y = new Component1(); 
                      boolean instance = y.isLightweight();
                      if (instance){
                      }
                      boolean instance1 = isDisplayable();
                      if (instance1){
                      }
                  }
              }
              """
          )
  

In the above case neither visitBinary() nor visitInstantOf is called instead we need to override visitMethodDeclaration.
Also for changes when we find c.getPeer() != null not sure we want our recipe to work on when null != c.getPeer() this gives an LST error as well Here is the link to the - https://docs.oracle.com/en/java/javase/11/migrate/index.html#GUID-0C350BAB-F2C8-409E-AD3E-63831C684A55

[timtebeek]

Hi @ranuradh ; I've pushed a change that will have caused your overridden methods not to be called; now if you set a breakpoint in those other methods they will actually be triggered. As a reminder you are in complete control of the tree traversal, which includes calling super.visitXyz to visit nested elements.

[ranuradh]

Thanks @timtebeek taking a look now

[timtebeek]

Thanks again @ranuradh ; I've applied a last few finishing touches to expand what's matched, and reduce the code to maintain.

[ranuradh]

@timtebeek love how you have made the recipe more generic and removed duplications will remember for the next recipe. This recipe looks great and we should be able to merge it post Chuka taking a look There are still build errors though.

[timtebeek]

Thanks for the kind words! Indeed incremental improvements is what we're going for; glad you're still learning from my feedback.

The build issue should be fixed once this change rolls out to a new release.

• Tolerate weird class names, as seen in functionaljava rewrite#4401

[cjobinabo]

Thanks @timtebeek for working so closely with Anu on this.