Skip to main content

Recipes by Tag

This doc contains all recipe tags and the recipes that are tagged with them.

Total tags: 197

5to6​

7 recipes

activation​

2 recipes

ai​

1 recipe

annotation​

3 recipes

annotations​

1 recipe

apache​

16 recipes

application​

6 recipes

arquillian​

1 recipe

assertj​

10 recipes

authentication​

2 recipes

authorization​

2 recipes

AWS​

54 recipes

Azure​

49 recipes

batch​

7 recipes

batchXML​

1 recipe

bean validation​

1 recipe

beans​

2 recipes

best practices​

1 recipe

  • Jackson best practices - Apply best practices for using Jackson library, including upgrade to Jackson 2.x and removing redundant annotations.

bindings​

1 recipe

boot​

50 recipes

  • Comment deprecated methods in Spring 3.4 - Spring Boot 3.4 deprecates methods that are not commonly used or need manual interaction.
  • Downgrade Jakarta Servlet API to 5.0 when using Jetty - Jetty does not yet support Servlet 6.0. This recipe will detect the presence of the spring-boot-starter-jetty as a first-order dependency and will add the maven property jakarta-servlet.version setting it's value to 5.0.0. This will downgrade the jakarta-servlet artifact if the pom's parent extends from the spring-boot-parent.
  • Find patterns that require updating for Spring Boot 2.5 - Looks for a series of patterns that have not yet had auto-remediation recipes developed for.
  • Find projects affected by changes to the default error view message attribute - As of Spring Boot 2.5 the message attribute in the default error view was removed rather than blanked when it is not shown. spring-webmvc or spring-webflux projects that parse the error response JSON may need to deal with the missing item (release notes). You can still use the server.error.include-message property if you want messages to be included.
  • Migrate Enabled to Access Spring Boot Properties - Migrate properties found in application.properties and application.yml, specifically converting 'enabled' to 'access'
  • Migrate SAP cloud foundry logging support to Spring Boot 3.x - Migrate SAP cloud foundry logging support from cf-java-logging-support-servlet to cf-java-logging-support-servlet-jakarta, to use Jakarta with Spring Boot 3.
  • Migrate Spring Boot 2.x projects to JUnit 5 from JUnit 4 - This recipe will migrate a Spring Boot application's tests from JUnit 4 to JUnit 5. This spring-specific migration includes conversion of Spring Test runners to Spring Test extensions and awareness of the composable Spring Test annotations.
  • Migrate Spring Boot 3.5 deprecated classes and methods - Migrate deprecated classes and methods that have been marked for removal in Spring Boot 3.5.
  • Migrate Spring Boot properties to 2.0 - Migrate properties found in application.properties and application.yml.
  • Migrate Spring Boot properties to 2.1 - Migrate properties found in application.properties and application.yml.
  • Migrate Spring Boot properties to 2.2 - Migrate properties found in application.properties and application.yml.
  • Migrate Spring Boot properties to 2.3 - Migrate properties found in application.properties and application.yml.
  • Migrate Spring Boot properties to 2.4 - Migrate properties found in application.properties and application.yml.
  • Migrate Spring Boot properties to 2.5 - Migrate properties found in application.properties and application.yml.
  • Migrate Spring Boot properties to 2.6 - Migrate properties found in application.properties and application.yml.
  • Migrate Spring Boot properties to 2.7 - Migrate properties found in application.properties and application.yml.
  • Migrate Spring Boot properties to 3.0 - Migrate properties found in application.properties and application.yml.
  • Migrate Spring Boot properties to 3.1 - Migrate properties found in application.properties and application.yml.
  • Migrate Spring Boot properties to 3.2 - Migrate properties found in application.properties and application.yml.
  • Migrate Spring Boot properties to 3.3 - Migrate properties found in application.properties and application.yml.
  • Migrate Spring Boot properties to 3.4 - Migrate properties found in application.properties and application.yml.
  • Migrate Spring Boot properties to 3.5 - Migrate properties found in application.properties and application.yml.
  • Migrate Spring Boot properties to 4.0 - Migrate properties found in application.properties and application.yml.
  • Migrate Spring to Spring Boot - Migrate non Spring Boot applications to the latest compatible Spring Boot release. This recipe will modify an application's build files introducing Maven dependency management for Spring Boot, or adding the Gradle Spring Boot build plugin.
  • Migrate @Endpoint Security properties to 3.4 - Migrate the settings for Spring Boot Management Endpoint Security from true|false to read-only|none.
  • Migrate dropWizard dependencies to Spring Boot 3.x - Migrate dropWizard dependencies to the new artifactId, since these are changed with Spring Boot 3.
  • Migrate from Spring Boot 1.x to 2.0 - Migrate Spring Boot 1.x applications to the latest Spring Boot 2.0 release. This recipe will modify an application's build files, make changes to deprecated/preferred APIs, and migrate configuration settings that have changes between versions. This recipe will also chain additional framework migrations (Spring Framework, Spring Data, etc) that are required as part of the migration to Spring Boot 2.0.
  • Migrate thymeleaf dependencies to Spring Boot 3.x - Migrate thymeleaf dependencies to the new artifactId, since these are changed with Spring Boot 3.
  • Migrate to Spring Boot 2.1 - Migrate applications to the latest Spring Boot 2.1 release. This recipe will modify an application's build files, make changes to deprecated/preferred APIs, and migrate configuration settings that have changes between versions. This recipe will also chain additional framework migrations (Spring Framework, Spring Data, etc) that are required as part of the migration to Spring Boot 2.1.
  • Migrate to Spring Boot 2.2 - Migrate applications to the latest Spring Boot 2.2 release. This recipe will modify an application's build files, make changes to deprecated/preferred APIs, and migrate configuration settings that have changes between versions. This recipe will also chain additional framework migrations (Spring Framework, Spring Data, etc) that are required as part of the migration to Spring Boot 2.2.
  • Migrate to Spring Boot 2.3 - Migrate applications to the latest Spring Boot 2.3 release. This recipe will modify an application's build files, make changes to deprecated/preferred APIs, and migrate configuration settings that have changes between versions. This recipe will also chain additional framework migrations (Spring Framework, Spring Data, etc) that are required as part of the migration to Spring Boot 2.3.
  • Migrate to Spring Boot 2.4 - Migrate applications to the latest Spring Boot 2.4 release. This recipe will modify an application's build files, make changes to deprecated/preferred APIs, and migrate configuration settings that have changes between versions. This recipe will also chain additional framework migrations (Spring Framework, Spring Data, etc) that are required as part of the migration to Spring Boot 2.4.
  • Migrate to Spring Boot 2.6 - Migrate applications to the latest Spring Boot 2.6 release. This recipe will modify an application's build files, make changes to deprecated/preferred APIs, and migrate configuration settings that have changes between versions. This recipe will also chain additional framework migrations (Spring Framework, Spring Data, etc) that are required as part of the migration to Spring Boot 2.6.
  • Migrate to Spring Boot 3.0 - Migrate applications to the latest Spring Boot 3.0 release. This recipe will modify an application's build files, make changes to deprecated/preferred APIs, and migrate configuration settings that have changes between versions. This recipe will also chain additional framework migrations (Spring Framework, Spring Data, etc) that are required as part of the migration to Spring Boot 2.7.
  • Migrate to Spring Boot 3.1 - Migrate applications to the latest Spring Boot 3.1 release. This recipe will modify an application's build files, make changes to deprecated/preferred APIs, and migrate configuration settings that have changes between versions. This recipe will also chain additional framework migrations (Spring Framework, Spring Data, etc) that are required as part of the migration to Spring Boot 3.0.
  • Migrate to Spring Boot 3.2 - Migrate applications to the latest Spring Boot 3.2 release. This recipe will modify an application's build files, make changes to deprecated/preferred APIs, and migrate configuration settings that have changes between versions. This recipe will also chain additional framework migrations (Spring Framework, Spring Data, etc) that are required as part of the migration to Spring Boot 3.1.
  • Migrate to Spring Boot 3.3 - Migrate applications to the latest Spring Boot 3.3 release. This recipe will modify an application's build files, make changes to deprecated/preferred APIs, and migrate configuration settings that have changes between versions. This recipe will also chain additional framework migrations (Spring Framework, Spring Data, etc) that are required as part of the migration to Spring Boot 3.2.
  • Migrate to Spring Boot 3.4 - Migrate applications to the latest Spring Boot 3.4 release. This recipe will modify an application's build files, make changes to deprecated/preferred APIs, and migrate configuration settings that have changes between versions. This recipe will also chain additional framework migrations (Spring Framework, Spring Data, etc) that are required as part of the migration to Spring Boot 3.4.
  • Migrate to Spring Boot 3.4 - Migrate applications to the latest Spring Boot 3.4 release. This recipe will modify an application's build files, make changes to deprecated/preferred APIs.
  • Migrate to Spring Boot 3.5 - Migrate applications to the latest Spring Boot 3.5 release. This recipe will modify an application's build files, make changes to deprecated/preferred APIs, and migrate configuration settings that have changes between versions. This recipe will also chain additional framework migrations (Spring Framework, Spring Data, etc) that are required as part of the migration to Spring Boot 3.5.
  • Remove the deprecated properties additional-keys-to-sanitize from the configprops and env end points - Spring Boot 3.0 removed the key-based sanitization mechanism used in Spring Boot 2.x in favor of a unified approach. See https://github.com/openrewrite/rewrite-spring/issues/228
  • Rename server.max-http-header-size to server.max-http-request-header-size - Previously, the server.max-http-header-size was treated inconsistently across the four supported embedded web servers. When using Jetty, Netty, or Undertow it would configure the max HTTP request header size. When using Tomcat it would configure the max HTTP request and response header sizes. The renamed property is used to configure the http request header size in Spring Boot 3.0. To limit the max header size of an HTTP response on Tomcat or Jetty (the only two servers that support such a setting), use a WebServerFactoryCustomizer.
  • Spring Boot 2.x best practices - Applies best practices to Spring Boot 2 applications.
  • Spring Boot 3.3 best practices - Applies best practices to Spring Boot 3 applications.
  • Spring Boot 3.3 best practices (only) - Applies best practices to Spring Boot 3 applications, without chaining in upgrades to Spring Boot.
  • Spring Boot 3.5 best practices - Applies best practices to Spring Boot 3.5+ applications.
  • Update OpenTelemetry resource attributes - The service.group resource attribute has been deprecated for OpenTelemetry in Spring Boot 3.5. Consider using alternative attributes or remove the deprecated attribute.
  • Upgrade Gradle 8 to 8.4+ for Spring Boot 3.4 - Spring Boot 3.4 requires Gradle 8.4+.
  • Upgrade Gradle to 7.6.4+ for Spring Boot 3.4 - Spring Boot 3.4 requires Gradle 7.6.4.
  • Use bean name applicationTaskExecutor instead of taskExecutor - Spring Boot 3.5 removed the bean name taskExecutor. Where this bean name is used, the recipe replaces the bean name to applicationTaskExecutor. This also includes instances where the developer provided their own bean named taskExecutor. This also includes scenarios where JSR-250's @Resource annotation is used.

bouncycastle​

2 recipes

cacheManager​

1 recipe

cdi​

2 recipes

CKV​

110 recipes

CKV2​

1 recipe

cloud​

15 recipes

cloudfoundry​

1 recipe

cobertura​

1 recipe

codemods​

103 recipes

collections​

2 recipes

commons​

13 recipes

compiler​

2 recipes

connector​

2 recipes

connectors​

1 recipe

core​

1 recipe

cucumber​

5 recipes

CVE​

3 recipes

  • Find text-direction changes - Finds unicode control characters which can change the direction text is displayed in. These control characters can alter how source code is presented to a human reader without affecting its interpretation by tools like compilers. So a malicious patch could pass code review while introducing vulnerabilities. Note that text direction-changing unicode control characters aren't inherently malicious. These characters can appear for legitimate reasons in code written in or dealing with right-to-left languages. See: https://trojansource.codes/ for more information.
  • Secure Spring service exporters - The default Java deserialization mechanism is available via ObjectInputStream class. This mechanism is known to be vulnerable. If an attacker can make an application deserialize malicious data, it may result in arbitrary code execution. Spring’s RemoteInvocationSerializingExporter uses the default Java deserialization mechanism to parse data. As a result, all classes that extend it are vulnerable to deserialization attacks. The Spring Framework contains at least HttpInvokerServiceExporter and SimpleHttpInvokerServiceExporter that extend RemoteInvocationSerializingExporter. These exporters parse data from the HTTP body using the unsafe Java deserialization mechanism. See the full blog post by Artem Smotrakov on CVE-2016-1000027 from which the above description is excerpted.
  • Upgrade Log4j 2.x dependency version - Upgrades the Log4j 2.x dependencies to the latest 2.x version. Mitigates the Log4Shell and other Log4j2-related vulnerabilities.

CWE​

16 recipes

  • Enable CSRF attack prevention - Cross-Site Request Forgery (CSRF) is a type of attack that occurs when a malicious web site, email, blog, instant message, or program causes a user's web browser to perform an unwanted action on a trusted site when the user is authenticated. See the full OWASP cheatsheet.
  • Fix CWE-338 with SecureRandom - Use a cryptographically strong pseudo-random number generator (PRNG).
  • Improper privilege management - Marking code as privileged enables a piece of trusted code to temporarily enable access to more resources than are available directly to the code that called it.
  • Insecure JMS deserialization - JMS Object messages depend on Java Serialization for marshalling/unmarshalling of the message payload when ObjectMessage#getObject is called. Deserialization of untrusted data can lead to security flaws.
  • Insecure cookies - Check for use of insecure cookies. Cookies should be marked as secure. This ensures that the cookie is sent only over HTTPS to prevent cross-site scripting attacks.
  • Migrates deprecated DefaultHttpClient - Since DefaultHttpClient is deprecated, we need to change it to the CloseableHttpClient. It only covers the default scenario with no custom HttpParams or ConnectionManager. Of note: the DefaultHttpClient does not support TLS 1.2. References: - Find Sec Bugs - IBM Support Pages
  • Partial path traversal vulnerability - Replaces dir.getCanonicalPath().startsWith(parent.getCanonicalPath(), which is vulnerable to partial path traversal attacks, with the more secure dir.getCanonicalFile().toPath().startsWith(parent.getCanonicalFile().toPath()). To demonstrate this vulnerability, consider "/usr/outnot".startsWith("/usr/out"). The check is bypassed although /outnot is not under the /out directory. It's important to understand that the terminating slash may be removed when using various String representations of the File object. For example, on Linux, println(new File("/var")) will print /var, but println(new File("/var", "/") will print /var/; however, println(new File("/var", "/").getCanonicalPath()) will print /var.
  • Prevent clickjacking - The frame-ancestors directive can be used in a Content-Security-Policy HTTP response header to indicate whether or not a browser should be allowed to render a page in a <frame> or <iframe>. Sites can use this to avoid Clickjacking attacks by ensuring that their content is not embedded into other sites.
  • Replace catch(Exception) with specific declared exceptions thrown in the try block - Replaces catch(Exception e) blocks with a multi-catch block (catch (SpecificException1 | SpecificException2 e)) containing only the exceptions declared thrown by method or constructor invocations within the try block that are not already caught by more specific catch clauses.
  • Secure the use of Jackson default typing - See the blog post on this subject.
  • Secure the use of SnakeYAML's constructor - See the paper on this subject.
  • Use HTTPS for repositories - Use HTTPS for repository URLs.
  • Use Files#createTempDirectory - Use Files#createTempDirectory when the sequence File#createTempFile(..)->File#delete()->File#mkdir() is used for creating a temp directory.
  • Use secure temporary file creation - java.io.File.createTempFile() has exploitable default file permissions. This recipe migrates to the more secure java.nio.file.Files.createTempFile().
  • XML parser XXE vulnerability - Avoid exposing dangerous features of the XML parser by updating certain factory settings.
  • Zip slip - Zip slip is an arbitrary file overwrite critical vulnerability, which typically results in remote command execution. A fuller description of this vulnerability is available in the Snyk documentation on it.

CycloneDX​

1 recipe

  • Software bill of materials - Produces a software bill of materials (SBOM) for a project. An SBOM is a complete list of all dependencies used in a project, including transitive dependencies. The produced SBOM is in the CycloneDX XML format. Supports Gradle and Maven. Places a file named sbom.xml adjacent to the Gradle or Maven build file.

dbrider​

1 recipe

default​

1 recipe

demo​

2 recipes

dependabot​

3 recipes

dependencies​

5 recipes

deployment​

2 recipes

deprecated​

17 recipes

deprecation​

4 recipes

  • Remove Security AccessController - The Security Manager API is unsupported in Java 24. This recipe will remove the usage of java.security.AccessController.
  • Remove Security Policy - The Security Manager API is unsupported in Java 24. This recipe will remove the use of java.security.Policy.
  • Remove Security SecurityManager - The Security Manager API is unsupported in Java 24. This recipe will remove the usage of java.security.SecurityManager.
  • Replace System.getSecurityManager() with null - The Security Manager API is unsupported in Java 24. This recipe will replace System.getSecurityManager() with null to make its behavior more obvious and try to simplify execution paths afterwards.

descriptors​

2 recipes

dropwizard​

1 recipe

easymock​

1 recipe

ejb​

7 recipes

epoll​

1 recipe

ESLint​

190 recipes

examples​

5 recipes

faces​

29 recipes

flyway​

5 recipes

GCP​

15 recipes

github​

7 recipes

glassfish​

3 recipes

  • Add explicit JAX-WS dependencies - This recipe will add explicit dependencies for Jakarta EE 8 when a Java 8 application is using JAX-WS. Any existing dependencies will be upgraded to the latest version of Jakarta EE 8. The artifacts are moved to Jakarta EE 8 but the application can continue to use the javax.xml.bind namespace.
  • Add explicit JAXB API dependencies and runtime - This recipe will add explicit dependencies for Jakarta EE 8 when a Java 8 application is using JAXB. Any existing dependencies will be upgraded to the latest version of Jakarta EE 8. The artifacts are moved to Jakarta EE 8 version 2.x which allows for the continued use of the javax.xml.bind namespace. Running a full javax to Jakarta migration using org.openrewrite.java.migrate.jakarta.JavaxMigrationToJakarta will update to versions greater than 3.x which necessitates the package change as well.
  • Use latest JAXB API and runtime for Jakarta EE 8 - Update build files to use the latest JAXB runtime from Jakarta EE 8 to maintain compatibility with Java version 11 or greater. The recipe will add a JAXB run-time, in Gradle compileOnly+testImplementation and Maven provided scope, to any project that has a transitive dependency on the JAXB API. The resulting dependencies still use the javax namespace, despite the move to the Jakarta artifact.

gradle​

4 recipes

guava​

47 recipes

hamcrest​

6 recipes

handler​

1 recipe

hibernate​

3 recipes

httpclient​

4 recipes

inject​

3 recipes

intellij​

1 recipe

jackson​

3 recipes

jacoco​

1 recipe

  • Upgrade JaCoCo - This recipe will upgrade JaCoCo to the latest patch version, which traditionally advertises full backwards compatibility for older Java versions.

jakarta​

100 recipes

jakartaee​

6 recipes

java​

10 recipes

java10​

1 recipe

  • Use local variable type inference - Apply local variable type inference (var) for primitives and objects. These recipes can cause unused imports, be advised to run `org.openrewrite.java.RemoveUnusedImports afterwards.

java11​

28 recipes

  • Add explicit Common Annotations dependencies - Add the necessary annotation-api dependency from Jakarta EE 8 to maintain compatibility with Java version 11 or greater.
  • Add explicit Inject dependencies - Add the necessary inject-api dependency from Jakarta EE 8 to maintain compatibility with Java version 11 or greater.
  • Add explicit JAX-WS dependencies - This recipe will add explicit dependencies for Jakarta EE 8 when a Java 8 application is using JAX-WS. Any existing dependencies will be upgraded to the latest version of Jakarta EE 8. The artifacts are moved to Jakarta EE 8 but the application can continue to use the javax.xml.bind namespace.
  • Add explicit JAXB API dependencies - This recipe will add explicit API dependencies for Jakarta EE 8 when a Java 8 application is using JAXB. Any existing dependencies will be upgraded to the latest version of Jakarta EE 8. The artifacts are moved to Jakarta EE 8 version 2.x which allows for the continued use of the javax.xml.bind namespace. Running a full javax to Jakarta migration using org.openrewrite.java.migrate.jakarta.JavaxMigrationToJakarta will update to versions greater than 3.x which necessitates the package change as well.
  • Add explicit JAXB API dependencies and remove runtimes - This recipe will add explicit API dependencies without runtime dependencies for Jakarta EE 8 when a Java 8 application is using JAXB. Any existing API dependencies will be upgraded to the latest version of Jakarta EE 8. The artifacts are moved to Jakarta EE 8 version 2.x which allows for the continued use of the javax.xml.bind namespace. All JAXB runtime implementation dependencies are removed.
  • Add explicit JAXB API dependencies and runtime - This recipe will add explicit dependencies for Jakarta EE 8 when a Java 8 application is using JAXB. Any existing dependencies will be upgraded to the latest version of Jakarta EE 8. The artifacts are moved to Jakarta EE 8 version 2.x which allows for the continued use of the javax.xml.bind namespace. Running a full javax to Jakarta migration using org.openrewrite.java.migrate.jakarta.JavaxMigrationToJakarta will update to versions greater than 3.x which necessitates the package change as well.
  • Do not package java.xml.bind and java.activation modules in WebSphere Liberty applications - The java.xml.bind and java.activation modules were removed in Java11. Websphere Liberty provides its own implementation of the modules, which can be used by specifying the jaxb-2.2 feature in the server.xml file. This recipe updates the javax.xml.bind and javax.activation dependencies to use the provided scope to avoid class loading issues.
  • Do not package java.xml.ws module in WebSphere Liberty applications - The java.xml.ws module was removed in Java11. Websphere Liberty provides its own implementation of the module, which can be used by specifying the jaxws-2.2 feature in the server.xml file. This recipe updates the javax.xml.ws dependency to use the provided scope to avoid class loading issues.
  • Migrate Lombok to a Java 11 compatible version - Update Lombok dependency to a version that is compatible with Java 11 and migrate experimental Lombok types that have been promoted.
  • Migrate from IBM Runtimes to Oracle Runtimes - This recipe will apply changes commonly needed when upgrading Java versions. The solutions provided in this list are solutions necessary for migrating from IBM Runtimes to Oracle Runtimes.
  • Migrate to IBM Semeru Runtimes - This recipe will apply changes commonly needed when upgrading Java versions. The solutions provided in this list are solutions only available in IBM Semeru Runtimes.
  • Migrate to Java 11 - This recipe will apply changes commonly needed when upgrading to Java 11. Specifically, for those applications that are built on Java 8, this recipe will update and add dependencies on J2EE libraries that are no longer directly bundled with the JDK. This recipe will also replace deprecated API with equivalents when there is a clear migration strategy. Build files will also be updated to use Java 11 as the target/source and plugins will be also be upgraded to versions that are compatible with Java 11.
  • Prefer java.util.Objects#requireNonNullElse - Prefer java.util.Objects#requireNonNullElse instead of using com.google.common.base.MoreObjects#firstNonNull.
  • Prefer the Java 11 standard library instead of Guava - Guava filled in important gaps in the Java standard library and still does. But at least some of Guava's API surface area is covered by the Java standard library now, and some projects may be able to remove Guava altogether if they migrate to standard library for these functions.
  • Remove Cobertura Maven plugin - This recipe will remove Cobertura, as it is not compatible with Java 11.
  • Remove Thread.destroy() and Thread.stop(Throwable) - The java.lang.Thread.destroy() method was never implemented, and the java.lang.Thread.stop(java.lang.Throwable) method has been unusable since Java SE 8. This recipe removes any usage of these methods from your application.
  • Replace Paths.get with Path.of - The java.nio.file.Paths.get method was introduced in Java SE 7. The java.nio.file.Path.of method was introduced in Java SE 11. This recipe replaces all usages of Paths.get with Path.of for consistency.
  • Replace javax.security.auth.Policy with java.security.Policy - The javax.security.auth.Policy class is not available from Java SE 11 onwards.
  • Upgrade build to Java 11 - Updates build files to use Java 11 as the target/source.
  • Upgrade plugins to Java 11 compatible versions - Updates plugins to version compatible with Java 11.
  • Use com.ibm.jsse2 instead of com.sun.net.ssl.internal.ssl - Do not use the com.sun.net.ssl.internal.ssl.Provider class.
  • Use com.ibm.net.ssl.www2.protocol.https.Handler instead of com.sun.net.ssl.internal.www.protocol.https.Handler - Do not use the com.sun.net.ssl.internal.www.protocol.https.Handler class.
  • Use com.ibm.net.ssl.www2.protocol instead of com.sun.net.ssl.internal.www.protocol - Do not use the com.sun.net.ssl.internal.www.protocol package.
  • Use com.sun.security.auth.module.Krb5LoginModule instead of com.ibm.security.auth.module.Krb5LoginModule - Do not use the com.ibm.security.auth.module.Krb5LoginModule class.
  • Use com.sun.xml.bind.* instead of com.sun.xml.internal.bind.* - Do not use APIs from com.sun.xml.internal.bind.* packages.
  • Use javax.net.ssl instead of com.sun.net.ssl - Do not use APIs from com.sun.net.ssl packages.
  • Use latest JAXB API and runtime for Jakarta EE 8 - Update build files to use the latest JAXB runtime from Jakarta EE 8 to maintain compatibility with Java version 11 or greater. The recipe will add a JAXB run-time, in Gradle compileOnly+testImplementation and Maven provided scope, to any project that has a transitive dependency on the JAXB API. The resulting dependencies still use the javax namespace, despite the move to the Jakarta artifact.
  • Use the latest JAX-WS API and runtime for Jakarta EE 8 - Update build files to use the latest JAX-WS runtime from Jakarta EE 8 to maintain compatibility with Java version 11 or greater. The recipe will add a JAX-WS run-time, in Gradle compileOnly+testImplementation and Maven provided scope, to any project that has a transitive dependency on the JAX-WS API. The resulting dependencies still use the javax namespace, despite the move to the Jakarta artifact.

java17​

23 recipes

java21​

11 recipes

  • Adopt SequencedCollection - Replace older code patterns with SequencedCollection methods, as per https://openjdk.org/jeps/431.
  • [Adopt javax.security.auth.Subject.current() and javax.security.auth.Subject.callAs() methods](/recipes/java/migrate/removedsubjectmethods.md) - _Replaces the javax.security.auth.Subject.getSubject()andjavax.security.auth.Subject.doAs()methods withjavax.security.auth.Subject.current()andjavax.security.auth.Subject.callAs()`._
  • Adopt switch pattern matching (JEP 441) - JEP 441 describes how some switch statements can be improved with pattern matching. This recipe applies some of those improvements where applicable.
  • Avoid using the deprecated empty finalize() method in java.desktop - The java.desktop module had a few implementations of finalize() that did nothing and have been removed. This recipe will remove these methods.
  • Find Virtual Thread opportunities - Find opportunities to convert existing code to use Virtual Threads.
  • Find non-virtual ExecutorService creation - Find all places where static java.util.concurrent.Executors method creates a non-virtual java.util.concurrent.ExecutorService. This recipe can be used to search fro ExecutorService that can be replaced by Virtual Thread executor.
  • Migrate to Java 21 - This recipe will apply changes commonly needed when migrating to Java 21. This recipe will also replace deprecated API with equivalents when there is a clear migration strategy. Build files will also be updated to use Java 21 as the target/source and plugins will be also be upgraded to versions that are compatible with Java 21.
  • Prefer Math#clamp - Prefer java.lang.Math#clamp instead of using com.google.common.primitives.*#constrainToRange.
  • Prefer the Java 21 standard library instead of Guava - Guava filled in important gaps in the Java standard library and still does. But at least some of Guava's API surface area is covered by the Java standard library now, and some projects may be able to remove Guava altogether if they migrate to standard library for these functions.
  • Upgrade build to Java 21 - Updates build files to use Java 21 as the target/source.
  • Upgrade plugins to Java 21 compatible versions - Updates plugins and dependencies to version compatible with Java 21.

java25​

6 recipes

  • Migrate to Java 25 - This recipe will apply changes commonly needed when migrating to Java 25. This recipe will also replace deprecated API with equivalents when there is a clear migration strategy. Build files will also be updated to use Java 25 as the target/source and plugins will be also be upgraded to versions that are compatible with Java 25.
  • Remove Security AccessController - The Security Manager API is unsupported in Java 24. This recipe will remove the usage of java.security.AccessController.
  • Remove Security Policy - The Security Manager API is unsupported in Java 24. This recipe will remove the use of java.security.Policy.
  • Remove Security SecurityManager - The Security Manager API is unsupported in Java 24. This recipe will remove the usage of java.security.SecurityManager.
  • Replace System.getSecurityManager() with null - The Security Manager API is unsupported in Java 24. This recipe will replace System.getSecurityManager() with null to make its behavior more obvious and try to simplify execution paths afterwards.
  • Upgrade build to Java 25 - Updates build files to use Java 25 as the target/source.

java6​

1 recipe

  • Migrate to Java 6 - This recipe will apply changes commonly needed when upgrading to Java 6. This recipe will also replace deprecated API with equivalents when there is a clear migration strategy.

java7​

1 recipe

  • Migrate to Java 7 - This recipe will apply changes commonly needed when upgrading to Java 7. This recipe will also replace deprecated API with equivalents when there is a clear migration strategy.

java8​

1 recipe

  • Migrate to Java 8 - This recipe will apply changes commonly needed when upgrading to Java 8. This recipe will also replace deprecated API with equivalents when there is a clear migration strategy.

javaee​

2 recipes

  • Use latest JAXB API and runtime for Jakarta EE 8 - Update build files to use the latest JAXB runtime from Jakarta EE 8 to maintain compatibility with Java version 11 or greater. The recipe will add a JAXB run-time, in Gradle compileOnly+testImplementation and Maven provided scope, to any project that has a transitive dependency on the JAXB API. The resulting dependencies still use the javax namespace, despite the move to the Jakarta artifact.
  • Use the latest JAX-WS API and runtime for Jakarta EE 8 - Update build files to use the latest JAX-WS runtime from Jakarta EE 8 to maintain compatibility with Java version 11 or greater. The recipe will add a JAX-WS run-time, in Gradle compileOnly+testImplementation and Maven provided scope, to any project that has a transitive dependency on the JAX-WS API. The resulting dependencies still use the javax namespace, despite the move to the Jakarta artifact.

javaee6​

1 recipe

  • Migrate to JavaEE6 - These recipes help with the Migration to Java EE 6, flagging and updating deprecated methods.

javaee7​

2 recipes

javaee8​

1 recipe

  • Migrate to JavaEE8 - These recipes help with the Migration to Java EE 8, flagging and updating deprecated methods.

javax​

36 recipes

jaxb​

11 recipes

  • Add explicit JAX-WS dependencies - This recipe will add explicit dependencies for Jakarta EE 8 when a Java 8 application is using JAX-WS. Any existing dependencies will be upgraded to the latest version of Jakarta EE 8. The artifacts are moved to Jakarta EE 8 but the application can continue to use the javax.xml.bind namespace.
  • Add explicit JAXB API dependencies - This recipe will add explicit API dependencies for Jakarta EE 8 when a Java 8 application is using JAXB. Any existing dependencies will be upgraded to the latest version of Jakarta EE 8. The artifacts are moved to Jakarta EE 8 version 2.x which allows for the continued use of the javax.xml.bind namespace. Running a full javax to Jakarta migration using org.openrewrite.java.migrate.jakarta.JavaxMigrationToJakarta will update to versions greater than 3.x which necessitates the package change as well.
  • Add explicit JAXB API dependencies and remove runtimes - This recipe will add explicit API dependencies without runtime dependencies for Jakarta EE 8 when a Java 8 application is using JAXB. Any existing API dependencies will be upgraded to the latest version of Jakarta EE 8. The artifacts are moved to Jakarta EE 8 version 2.x which allows for the continued use of the javax.xml.bind namespace. All JAXB runtime implementation dependencies are removed.
  • Add explicit JAXB API dependencies and runtime - This recipe will add explicit dependencies for Jakarta EE 8 when a Java 8 application is using JAXB. Any existing dependencies will be upgraded to the latest version of Jakarta EE 8. The artifacts are moved to Jakarta EE 8 version 2.x which allows for the continued use of the javax.xml.bind namespace. Running a full javax to Jakarta migration using org.openrewrite.java.migrate.jakarta.JavaxMigrationToJakarta will update to versions greater than 3.x which necessitates the package change as well.
  • Migrate XJC Bindings to Jakata XML - Java EE has been rebranded to Jakarta EE, migrates the namespace and version in XJC bindings.
  • Migrate deprecated javax.xml.bind packages to jakarta.xml.bind - Java EE has been rebranded to Jakarta EE, necessitating a package relocation.
  • Migrate deprecated javax.xml.bind packages to jakarta.xml.bind - Java EE has been rebranded to Jakarta EE, necessitating a package relocation.
  • Migrate to Jakarta EE 9 - Jakarta EE 9 is the first version of Jakarta EE that uses the new jakarta namespace.
  • Migrate to Java 11 - This recipe will apply changes commonly needed when upgrading to Java 11. Specifically, for those applications that are built on Java 8, this recipe will update and add dependencies on J2EE libraries that are no longer directly bundled with the JDK. This recipe will also replace deprecated API with equivalents when there is a clear migration strategy. Build files will also be updated to use Java 11 as the target/source and plugins will be also be upgraded to versions that are compatible with Java 11.
  • Migrate xmlns entries in *.xjb files. - Java EE has been rebranded to Jakarta EE, necessitating an XML namespace relocation.
  • Use latest JAXB API and runtime for Jakarta EE 8 - Update build files to use the latest JAXB runtime from Jakarta EE 8 to maintain compatibility with Java version 11 or greater. The recipe will add a JAXB run-time, in Gradle compileOnly+testImplementation and Maven provided scope, to any project that has a transitive dependency on the JAXB API. The resulting dependencies still use the javax namespace, despite the move to the Jakarta artifact.

jaxws​

5 recipes

  • Migrate deprecated javax.xml.ws packages to jakarta.xml.ws - Java EE has been rebranded to Jakarta EE, necessitating a package relocation.
  • Migrate deprecated javax.xml.ws packages to jakarta.xml.ws - Java EE has been rebranded to Jakarta EE, necessitating a package relocation.
  • Migrate to Jakarta EE 9 - Jakarta EE 9 is the first version of Jakarta EE that uses the new jakarta namespace.
  • Migrate to Java 11 - This recipe will apply changes commonly needed when upgrading to Java 11. Specifically, for those applications that are built on Java 8, this recipe will update and add dependencies on J2EE libraries that are no longer directly bundled with the JDK. This recipe will also replace deprecated API with equivalents when there is a clear migration strategy. Build files will also be updated to use Java 11 as the target/source and plugins will be also be upgraded to versions that are compatible with Java 11.
  • Use the latest JAX-WS API and runtime for Jakarta EE 8 - Update build files to use the latest JAX-WS runtime from Jakarta EE 8 to maintain compatibility with Java version 11 or greater. The recipe will add a JAX-WS run-time, in Gradle compileOnly+testImplementation and Maven provided scope, to any project that has a transitive dependency on the JAX-WS API. The resulting dependencies still use the javax namespace, despite the move to the Jakarta artifact.

jboss​

2 recipes

jdbc​

2 recipes

JDK​

1 recipe

Jest​

17 recipes

jetbrains​

1 recipe

jetty​

1 recipe

  • Downgrade Jakarta Servlet API to 5.0 when using Jetty - Jetty does not yet support Servlet 6.0. This recipe will detect the presence of the spring-boot-starter-jetty as a first-order dependency and will add the maven property jakarta-servlet.version setting it's value to 5.0.0. This will downgrade the jakarta-servlet artifact if the pom's parent extends from the spring-boot-parent.

jmockit​

1 recipe

jms​

3 recipes

jobXML​

1 recipe

joda​

1 recipe

  • Prefer the Java standard library instead of Joda-Time - Before Java 8, Java lacked a robust date and time library, leading to the widespread use of Joda-Time to fill this gap. With the release of Java 8, the java.time package was introduced, incorporating most of Joda-Time's concepts. Features deemed too specialized or bulky for java.time were included in the ThreeTen-Extra library. This recipe migrates Joda-Time types to java.time and threeten-extra types.

jsf​

29 recipes

jsp​

1 recipe

jsptaglibrary​

1 recipe

jsr250​

1 recipe

JtaTransactionManager​

1 recipe

junit​

16 recipes

jupiter​

2 recipes

kafka​

2 recipes

kubernetes​

24 recipes

  • Ensure CPU limits are set - A system without managed quotas could eventually collapse due to inadequate resources for the tasks it bares.
  • Ensure CPU request is set - If a container is created in a namespace that has a default CPU limit, and the container does not specify its own CPU limit, then the container is assigned the default CPU limit.
  • Ensure image pull policy is Always - Ensures the latest version of a tag is deployed each time.
  • Ensure lifecycle rule on StorageBucket - When defining a rule, you can specify any set of conditions for any action. The following configuration defines a rule to delete all objects older than 7 days in a bucket.
  • Ensure liveness probe is configured - The kubelet uses liveness probes to know when to schedule restarts for containers. Restarting a container in a deadlock state can help to make the application more available, despite bugs.
  • Ensure memory limits are set - With no limit set, kubectl allocates more and more memory to the container until it runs out.
  • Ensure memory request is set - A container is guaranteed to have as much memory as it requests, but is not allowed to use more memory than the limit set. This configuration may save resources and prevent an attack on an exploited container.
  • Ensure readiness probe is configured - Using the Readiness Probe ensures teams define what actions need to be taken to prevent failure and ensure recovery in case of unexpected errors.
  • Kubernetes best practices - Applies best practices to Kubernetes manifests.
  • Limit root capabilities in a container - Limiting the admission of containers with capabilities ensures that only a small number of containers have extended capabilities outside the default range.
  • Migrate to Kubernetes API v1.16 - This recipe will apply changes commonly needed when migrating to Kubernetes API v1.16.
  • Migrate to Kubernetes API v1.22 - This recipe will apply changes commonly needed when migrating to Kubernetes API v1.22.
  • Migrate to Kubernetes API v1.25 - This recipe will apply changes commonly needed when migrating to Kubernetes API v1.25.
  • Migrate to Kubernetes API v1.26 - This recipe will apply changes commonly needed when migrating to Kubernetes API v1.26.
  • Migrate to Kubernetes API v1.27 - This recipe will apply changes commonly needed when migrating to Kubernetes API v1.27.
  • Migrate to Kubernetes API v1.29 - This recipe will apply changes commonly needed when migrating to Kubernetes API v1.29.
  • Migrate to Kubernetes API v1.32 - This recipe will apply changes commonly needed when migrating to Kubernetes API v1.32.
  • No host IPC sharing - Preventing sharing of host PID/IPC namespace, networking, and ports ensures proper isolation between Docker containers and the underlying host.
  • No host network sharing - When using the host network mode for a container, that container’s network stack is not isolated from the Docker host, so the container shares the host’s networking namespace and does not get its own IP-address allocation.
  • No host process ID sharing - Sharing the host process ID namespace breaks the isolation between container images and can make processes visible to other containers in the pod. This includes all information in the /proc directory, which can sometimes include passwords or keys, passed as environment variables.
  • No privilege escalation - Does not allow a process to gain more privileges than its parent process.
  • No privileged containers - Privileged containers are containers that have all of the root capabilities of a host machine, allowing access to resources that are not accessible in ordinary containers.
  • No root containers - Containers that run as root frequently have more permissions than their workload requires which, in case of compromise, could help an attacker further their exploits.
  • Read-only root filesystem - Using an immutable root filesystem and a verified boot mechanism prevents against attackers from "owning" the machine through permanent local changes.

lang​

1 recipe

LoadTimeWeaver​

1 recipe

local​

1 recipe

lodash​

4 recipes

log4j​

10 recipes

log4shell​

1 recipe

logback​

1 recipe

  • Migrate Log4j 2.x to Logback - Migrates usage of Apache Log4j 2.x to using logback as an SLF4J implementation directly. Note, this currently does not modify log4j.properties files.

logging​

21 recipes

lombok​

6 recipes

material​

78 recipes

math​

1 recipe

  • Migrates to Apache Commons Math 3.x - Migrate applications to the latest Apache Commons Math 3.x release. This recipe modifies application's build files, make changes to deprecated/preferred APIs, and migrates configuration settings that have changes between versions.

micrometer​

3 recipes

migration​

2 recipes

mockito​

7 recipes

mui​

78 recipes

mvc​

1 recipe

myfaces​

5 recipes

mysql​

1 recipe

namespaces​

1 recipe

netty​

5 recipes

networking​

1 recipe

nextjs​

12 recipes

  • Add React imports - Transforms files that do not import React to include the import in order for the new React JSX transform to work.
  • Migrate ImageResponse imports - This codemod moves transforms imports from next/server to next/og for usage of Dynamic OG Image Generation.
  • Migrate to the New Image Component - Dangerously migrates from next/legacy/image to the new next/image by adding inline styles and removing unused props.
  • Next.js Codemods for API Updates - Next.js provides Codemod transformations to help upgrade your Next.js codebase when an API is updated or deprecated.
  • Remove <a> Tags From Link Components - Remove <a> tags inside Link Components or add a legacyBehavior prop to Links that cannot be auto-fixed.
  • Rename Next Image Imports - Safely renames next/image imports in existing Next.js 10 11 or 12 applications to next/legacy/image in Next.js 13. Also renames next/future/image to next/image.
  • Rename Next Image Imports - Safely renames next/image imports in existing Next.js 10 11 or 12 applications to next/legacy/image in Next.js 13. Also renames next/future/image to next/image.
  • Transform AMP HOC into page config - Transforms the withAmp HOC into Next.js 9 page configuration.
  • Transform Anonymous Components into Named Components - Transforms anonymous components into named components to make sure they work with Fast Refresh. The component will have a camel-cased name based on the name of the file, and it also works with arrow functions.
  • Use Built-in Font - This codemod uninstalls the @next/font package and transforms @next/font imports into the built-in next/font.
  • Use viewport export - This codemod migrates certain viewport metadata to viewport export.
  • Use withRouter - Transforms the deprecated automatically injected url property on top-level pages to using withRouter and the router property it injects. Read more here.

nio​

1 recipe

non​

1 recipe

observability​

1 recipe

  • Update OpenTelemetry resource attributes - The service.group resource attribute has been deprecated for OpenTelemetry in Spring Boot 3.5. Consider using alternative attributes or remove the deprecated attribute.

okhttp​

1 recipe

omnifaces​

6 recipes

openapi​

10 recipes

opentelemetry​

1 recipe

  • Update OpenTelemetry resource attributes - The service.group resource attribute has been deprecated for OpenTelemetry in Spring Boot 3.5. Consider using alternative attributes or remove the deprecated attribute.

oracle​

1 recipe

orm​

2 recipes

oss​

1 recipe

  • Add ASLv2 license header - Adds the Apache Software License Version 2.0 to Java source files which are missing a license header.

permissions​

1 recipe

persistence​

5 recipes

petclinic​

2 recipes

plain text​

1 recipe

  • Change text - Completely replaces the contents of the text file with other text. Use together with a FindSourceFiles precondition to limit which files are changed.

poi​

1 recipe

  • Migrates to Apache POI 3.17 - Migrates to the last Apache POI 3.x release. This recipe modifies build files and makes changes to deprecated/preferred APIs that have changed between versions.

postgresql​

1 recipe

primefaces​

4 recipes

pubsub​

2 recipes

ra​

3 recipes

rdbms​

2 recipes

reactor​

2 recipes

refactoring​

1 recipe

  • Use local variable type inference - Apply local variable type inference (var) for primitives and objects. These recipes can cause unused imports, be advised to run `org.openrewrite.java.RemoveUnusedImports afterwards.

resource​

2 recipes

RSPEC​

169 recipes

  • 'Collection.toArray()' should be passed an array of the proper type - Using Collection.toArray() without parameters returns an Object[], which requires casting. It is more efficient and clearer to use Collection.toArray(new T[0]) instead.
  • Add serialVersionUID to a Serializable class when missing - A serialVersionUID field is strongly recommended in all Serializable classes. If this is not defined on a Serializable class, the compiler will generate this value. If a change is later made to the class, the generated value will change and attempts to deserialize the class will fail.
  • Add missing @Override to overriding and implementing methods - Adds @Override to methods overriding superclass methods or implementing interface methods. Annotating methods improves readability by showing the author's intent to override. Additionally, when annotated, the compiler will emit an error when a signature of the overridden method does not match the superclass method.
  • Assertion arguments should be passed in the correct order - Assertions such as org.junit.Assert.assertEquals expect the first argument to be the expected value and the second argument to be the actual value; for org.testng.Assert, it’s the other way around. This recipe detects J.Literal, J.NewArray, and java.util.Iterable arguments swapping them if necessary so that the error messages won't be confusing.
  • Atomic Boolean, Integer, and Long equality checks compare their values - AtomicBoolean#equals(Object), AtomicInteger#equals(Object) and AtomicLong#equals(Object) are only equal to their instance. This recipe converts a.equals(b) to a.get() == b.get().
  • Avoid boxed boolean expressions - Under certain conditions the java.lang.Boolean type is used as an expression, and it may throw a NullPointerException if the value is null.
  • Boolean checks should not be inverted - Ensures that boolean checks are not unnecessarily inverted. Also fixes double negative boolean expressions.
  • Call to Mockito method "verify", "when" or "given" should be simplified - Fixes Sonar issue java:S6068: Call to Mockito method "verify", "when" or "given" should be simplified.
  • CaseInsensitive comparisons do not alter case - Remove String#toLowerCase() or String#toUpperCase() from String#equalsIgnoreCase(..) comparisons.
  • Catch clause should do more than just rethrow - A catch clause that only rethrows the caught exception is unnecessary. Letting the exception bubble up as normal achieves the same result with less code.
  • Change StringBuilder and StringBuffer character constructor argument to String - Instantiating a StringBuilder or a StringBuffer with a Character results in the int representation of the character being used for the initial size.
  • Combine semantically equal catch blocks - Combine catches in a try that contain semantically equivalent blocks. No change will be made when a caught exception exists if combining catches may change application behavior or type attribution is missing.
  • Constructors of an abstract class should not be declared public - Constructors of abstract classes can only be called in constructors of their subclasses. Therefore the visibility of public constructors are reduced to protected.
  • Control flow statement indentation - Program flow control statements like if, while, and for can omit curly braces when they apply to only a single statement. This recipe ensures that any statements which follow that statement are correctly indented to show they are not part of the flow control statement.
  • Covariant equals - Checks that classes and records which define a covariant equals() method also override method equals(Object). Covariant equals() means a method that is similar to equals(Object), but with a covariant parameter type (any subtype of Object).
  • Default comes last - Ensure the default case comes last after all the cases in a switch statement.
  • End files with a single newline - Some tools work better when files end with an empty line.
  • Enum values should be compared with "==" - Replaces Enum equals(java.lang.Object) with Enum == java.lang.Object. An !Enum equals(java.lang.Object) will change to !=.
  • Equals avoids null - Checks that any combination of String literals is on the left side of an equals() comparison. Also checks for String literals assigned to some field (such as someString.equals(anotherString = "text")).
  • Explicit initialization - Checks if any class or object member is explicitly initialized to default for its type value: - null for object references - zero for numeric types and char - and false for boolean Removes explicit initializations where they aren't necessary.
  • Fall through - Checks for fall-through in switch statements, adding break statements in locations where a case contains Java code but does not have a break, return, throw, or continue statement.
  • Finalize classes with private constructors - Adds the final modifier to classes that expose no public or package-private constructors.
  • Find empty classes - Find empty classes without annotations that do not implement an interface or extend a class.
  • Find methods with empty bodies - Find methods with empty bodies and single public no arg constructors.
  • Fix String#format and String#formatted expressions - Fix String#format and String#formatted expressions by replacing \n newline characters with %n and removing any unused arguments. Note this recipe is scoped to only transform format expressions which do not specify the argument index.
  • Fix missing braces - Adds missing braces around code such as single-line if, for, while, and do-while block bodies.
  • Hidden field - Refactor local variables or parameters which shadow a field defined in the same class.
  • Hide utility class constructor - Ensures utility classes (classes containing only static methods or fields in their API) do not have a public constructor.
  • Include an assertion in tests - For tests not having any assertions, wrap the statements with JUnit Jupiter's Assertions#assertDoesNotThrow(..).
  • Inline variable - Inline variables when they are immediately used to return or throw. Supports both variable declarations and assignments to local variables.
  • JUnit 5 inner test classes should be annotated with @Nested - Adds @Nested to inner classes that contain JUnit 5 tests.
  • Jump statements should not be redundant - Jump statements such as return and continue let you change the default flow of program execution, but jump statements that direct the control flow to the original direction are just a waste of keystrokes.
  • Loggers should be named for their enclosing classes - Ensure LoggerFactory#getLogger(Class) is called with the enclosing class as argument.
  • Modifier order - Modifiers should be declared in the correct order as recommended by the JLS.
  • Nested enums are not static - Remove static modifier from nested enum types since they are implicitly static.
  • No C-style array declarations - Change C-Style array declarations int i[]; to int[] i;.
  • No double brace initialization - Replace List, Map, and Set double brace initialization with an initialization block.
  • No multiple variable declarations - Places each variable declaration in its own statement and on its own line. Using one variable declaration per line encourages commenting and can increase readability.
  • No primitive wrappers for #toString() or #compareTo(..) - Primitive wrappers should not be instantiated only for #toString() or #compareTo(..) invocations.
  • Order POM elements - Order POM elements according to the recommended order.
  • Parameterize SLF4J's logging statements - Use SLF4J's parameterized logging, which can significantly boost performance for messages that otherwise would be assembled with String concatenation. Particularly impactful when the log level is not enabled, as no work is done to assemble the message.
  • Parameterize logging statements - Transform logging statements using concatenation for messages and variables into a parameterized format. For example, logger.info("hi " + userName) becomes logger.info("hi {}", userName). This can significantly boost performance for messages that otherwise would be assembled with String concatenation. Particularly impactful when the log level is not enabled, as no work is done to assemble the message.
  • Prefer Files#createTempDirectory() - Replaces Guava Files#createTempDir() with Java Files#createTempDirectory(..). Transformations are limited to scopes throwing or catching java.io.IOException.
  • Prefer Files#createTempFile(String, String, FileAttribute[]) over alternatives that create files with more liberal permissions - Note that File#createTempFile treats the given prefix as a path, and ignores all but its file name. That is, the actual prefix used is derived from all characters following the final file separator (if any). This is not the case with Files#createTempFile, which will instead throw an IllegalArgumentException if the prefix contains any file separators.
  • Prefer java.util.Optional#or(Supplier<T extends java.util.Optional<T>>) - Prefer java.util.Optional#or(Supplier<T extends java.util.Optional<T>>) over `com.google.common.base.Optional#or(com.google.common.base.Optional).
  • Prefer java.util.Optional#orElse(null) over com.google.common.base.Optional#orNull() - Replaces com.google.common.base.Optional#orNull() with java.util.Optional#orElse(null).
  • Prefer java.util.Optional - Prefer java.util.Optional instead of using com.google.common.base.Optional.
  • Prefer java.util.function.Function - Prefer java.util.function.Function instead of using com.google.common.base.Function.
  • Prefer java.util.function.Predicate - Prefer java.util.function.Predicate instead of using com.google.common.base.Predicate.
  • Prefer java.util.function.Supplier - Prefer java.util.function.Supplier instead of using com.google.common.base.Supplier.
  • Prefer while over for loops - When only the condition expression is defined in a for loop, and the initialization and increment expressions are missing, a while loop should be used instead to increase readability.
  • Properly use declaration-site type variance for well-known types - When using a method parameter like Function<IN, OUT>, it should rather be Function<? super IN, ? extends OUT>. This recipe checks for method parameters of well-known types.
  • Refaster template AssortedRules.LogicalImplication - Don't unnecessarily repeat boolean expressions.
  • Refaster template BigDecimalRules.BigDecimalValueOf - Prefer BigDecimal#valueOf(double) over the associated constructor.
  • Refaster template CharSequenceRules.CharSequenceIsEmpty - Prefer CharSequence#isEmpty() over alternatives that consult the char sequence's length.
  • Refaster template CollectionRules.CollectionIsEmpty - Prefer Collection#isEmpty() over alternatives that consult the collection's size or are otherwise more contrived.
  • Refaster template DoubleStreamRules.DoubleStreamAnyMatch - Prefer DoubleStream#anyMatch(DoublePredicate) over more contrived alternatives.
  • Refaster template EqualityRules.DoubleNegation - Avoid double negations; this is not Javascript.
  • Refaster template EqualityRules.IndirectDoubleNegation - Don't negate an inequality test or use the ternary operator to compare two booleans; directly test for equality instead.
  • Refaster template EqualityRules.Negation - Don't negate an equality test or use the ternary operator to compare two booleans; directly test for inequality instead.
  • Refaster template ImmutableMapRules.ImmutableMapOf4 - Prefer ImmutableMap#of(Object, Object, Object, Object, Object, Object, Object, Object) over alternatives that don't communicate the immutability of the resulting map at the type level.
  • Refaster template ImmutableMapRules.ImmutableMapOf5 - Prefer ImmutableMap#of(Object, Object, Object, Object, Object, Object, Object, Object, Object, Object) over alternatives that don't communicate the immutability of the resulting map at the type level.
  • Refaster template IntStreamRules.IntStreamAnyMatch - Prefer IntStream#anyMatch(IntPredicate) over more contrived alternatives.
  • Refaster template LongStreamRules.LongStreamAnyMatch - Prefer LongStream#anyMatch(LongPredicate) over more contrived alternatives.
  • Refaster template OptionalRules.OptionalOrElseThrow - Prefer Optional#orElseThrow() over the less explicit Optional#get().
  • Refaster template PrimitiveRules.GreaterThanOrEqualTo - Avoid contrived ways of expressing the "greater than or equal to" relationship.
  • Refaster template PrimitiveRules.GreaterThan - Avoid contrived ways of expressing the "greater than" relationship.
  • Refaster template PrimitiveRules.LessThanOrEqualTo - Avoid contrived ways of expressing the "less than or equal to" relationship.
  • Refaster template PrimitiveRules.LessThan - Avoid contrived ways of expressing the "less than" relationship.
  • Refaster template ReactorRules.FluxThenEmpty - Avoid vacuous invocations of Flux#ignoreElements().
  • Refaster template ReactorRules.FluxThenMono - Avoid vacuous invocations of Flux#ignoreElements().
  • Refaster template ReactorRules.FluxThen - Avoid vacuous invocations of Flux#ignoreElements().
  • Refaster template ReactorRules.MonoIdentity - Don't unnecessarily transform a Mono to an equivalent instance.
  • Refaster template ReactorRules.MonoThenEmpty - Avoid vacuous invocations of Mono#ignoreElement().
  • Refaster template ReactorRules.MonoThenMono - Avoid vacuous operations prior to invocation of Mono#then(Mono).
  • Refaster template ReactorRules.MonoThen - Prefer direct invocation of Mono#then()} over more contrived alternatives.
  • Refaster template RxJava2AdapterRules.CompletableToMono - Use the fluent API style when using RxJava2Adapter#completableToMono.
  • Refaster template StreamRules.StreamCount - Recipe created for the following Refaster template: java static final class StreamCount<T> { @BeforeTemplate @SuppressWarnings(value = "java:S4266") long before(Stream<T> stream) { return stream.collect(counting()); } @AfterTemplate long after(Stream<T> stream) { return stream.count(); } } .
  • Refaster template StreamRules.StreamMapCollect - Recipe created for the following Refaster template: java static final class StreamMapCollect<T, U, R> { @BeforeTemplate @SuppressWarnings(value = "java:S4266") R before(Stream<T> stream, Function<? super T, ? extends U> mapper, Collector<? super U, ?, R> collector) { return stream.collect(mapping(mapper, collector)); } @AfterTemplate R after(Stream<T> stream, Function<? super T, ? extends U> mapper, Collector<? super U, ?, R> collector) { return stream.map(mapper).collect(collector); } } .
  • Refaster template StreamRules.StreamMax - Recipe created for the following Refaster template: java static final class StreamMax<T> { @BeforeTemplate @SuppressWarnings(value = "java:S4266") Optional<T> before(Stream<T> stream, Comparator<? super T> comparator) { return Refaster.anyOf(stream.min(comparator.reversed()), Streams.findLast(stream.sorted(comparator)), stream.collect(maxBy(comparator))); } @AfterTemplate Optional<T> after(Stream<T> stream, Comparator<? super T> comparator) { return stream.max(comparator); } } .
  • Refaster template StreamRules.StreamMin - Recipe created for the following Refaster template: java static final class StreamMin<T> { @BeforeTemplate @SuppressWarnings(value = "java:S4266") Optional<T> before(Stream<T> stream, Comparator<? super T> comparator) { return Refaster.anyOf(stream.max(comparator.reversed()), stream.sorted(comparator).findFirst(), stream.collect(minBy(comparator))); } @AfterTemplate Optional<T> after(Stream<T> stream, Comparator<? super T> comparator) { return stream.min(comparator); } } .
  • Refaster template StreamRules.StreamReduceWithIdentity - Recipe created for the following Refaster template: java static final class StreamReduceWithIdentity<T> { @BeforeTemplate @SuppressWarnings(value = "java:S4266") T before(Stream<T> stream, T identity, BinaryOperator<T> accumulator) { return stream.collect(reducing(identity, accumulator)); } @AfterTemplate T after(Stream<T> stream, T identity, BinaryOperator<T> accumulator) { return stream.reduce(identity, accumulator); } } .
  • Refaster template StreamRules.StreamReduce - Recipe created for the following Refaster template: java static final class StreamReduce<T> { @BeforeTemplate @SuppressWarnings(value = "java:S4266") Optional<T> before(Stream<T> stream, BinaryOperator<T> accumulator) { return stream.collect(reducing(accumulator)); } @AfterTemplate Optional<T> after(Stream<T> stream, BinaryOperator<T> accumulator) { return stream.reduce(accumulator); } } .
  • Refaster template StringRules.EmptyString - Avoid unnecessary creation of new empty String objects; use the empty string literal instead.
  • Refaster template StringRules.StringIdentity - Avoid unnecessary creation of new String objects.
  • Refaster template StringRules.StringIndexOfChar - Prefer String#indexOf(int, int) over less efficient alternatives.
  • Refaster template StringRules.StringIndexOfString - Prefer String#indexOf(String, int) over less efficient alternatives.
  • Refaster template StringRules.StringIsEmpty - Prefer String#isEmpty() over alternatives that consult the string's length.
  • Refaster template StringRules.StringLastIndexOfChar - Prefer String#lastIndexOf(int, int) over less efficient alternatives.
  • Refaster template StringRules.StringLastIndexOfString - Prefer String#lastIndexOf(String, int) over less efficient alternatives.
  • Refaster template StringRules.StringStartsWith - Prefer String#startsWith(String, int) over less efficient alternatives.
  • Refaster template TestNGToAssertJRules.AssertEqualWithMessage - Recipe created for the following Refaster template: java @SuppressWarnings(value = "java:S1448") static final class AssertEqualWithMessage { @BeforeTemplate void before(boolean actual, String message, boolean expected) { assertEquals(actual, expected, message); } @BeforeTemplate void before(boolean actual, String message, Boolean expected) { assertEquals(actual, expected, message); } @BeforeTemplate void before(Boolean actual, String message, boolean expected) { assertEquals(actual, expected, message); } @BeforeTemplate void before(Boolean actual, String message, Boolean expected) { assertEquals(actual, expected, message); } @BeforeTemplate void before(byte actual, String message, byte expected) { assertEquals(actual, expected, message); } @BeforeTemplate void before(byte actual, String message, Byte expected) { assertEquals(actual, expected, message); } @BeforeTemplate void before(Byte actual, String message, byte expected) { assertEquals(actual, expected, message); } @BeforeTemplate void before(Byte actual, String message, Byte expected) { assertEquals(actual, expected, message); } @BeforeTemplate void before(char actual, String message, char expected) { assertEquals(actual, expected, message); } @BeforeTemplate void before(char actual, String message, Character expected) { assertEquals(actual, expected, message); } @BeforeTemplate void before(Character actual, String message, char expected) { assertEquals(actual, expected, message); } @BeforeTemplate void before(Character actual, String message, Character expected) { assertEquals(actual, expected, message); } @BeforeTemplate void before(short actual, String message, short expected) { assertEquals(actual, expected, message); } @BeforeTemplate void before(short actual, String message, Short expected) { assertEquals(actual, expected, message); } @BeforeTemplate void before(Short actual, String message, short expected) { assertEquals(actual, expected, message); } @BeforeTemplate void before(Short actual, String message, Short expected) { assertEquals(actual, expected, message); } @BeforeTemplate void before(int actual, String message, int expected) { assertEquals(actual, expected, message); } @BeforeTemplate void before(int actual, String message, Integer expected) { assertEquals(actual, expected, message); } @BeforeTemplate void before(Integer actual, String message, int expected) { assertEquals(actual, expected, message); } @BeforeTemplate void before(Integer actual, String message, Integer expected) { assertEquals(actual, expected, message); } @BeforeTemplate void before(long actual, String message, long expected) { assertEquals(actual, expected, message); } @BeforeTemplate void before(long actual, String message, Long expected) { assertEquals(actual, expected, message); } @BeforeTemplate void before(Long actual, String message, long expected) { assertEquals(actual, expected, message); } @BeforeTemplate void before(Long actual, String message, Long expected) { assertEquals(actual, expected, message); } @BeforeTemplate void before(float actual, String message, float expected) { assertEquals(actual, expected, message); } @BeforeTemplate void before(float actual, String message, Float expected) { assertEquals(actual, expected, message); } @BeforeTemplate void before(Float actual, String message, float expected) { assertEquals(actual, expected, message); } @BeforeTemplate void before(Float actual, String message, Float expected) { assertEquals(actual, expected, message); } @BeforeTemplate void before(double actual, String message, double expected) { assertEquals(actual, expected, message); } @BeforeTemplate void before(double actual, String message, Double expected) { assertEquals(actual, expected, message); } @BeforeTemplate void before(Double actual, String message, double expected) { assertEquals(actual, expected, message); } @BeforeTemplate void before(Double actual, String message, Double expected) { assertEquals(actual, expected, message); } @BeforeTemplate void before(Object actual, String message, Object expected) { assertEquals(actual, expected, message); } @BeforeTemplate void before(String actual, String message, String expected) { assertEquals(actual, expected, message); } @BeforeTemplate void before(Map<?, ?> actual, String message, Map<?, ?> expected) { assertEquals(actual, expected, message); } @AfterTemplate @UseImportPolicy(value = STATIC_IMPORT_ALWAYS) void after(Object actual, String message, Object expected) { assertThat(actual).withFailMessage(message).isEqualTo(expected); } } .
  • Refaster template TestNGToAssertJRules.AssertEqual - Recipe created for the following Refaster template: java @SuppressWarnings(value = "java:S1448") static final class AssertEqual { @BeforeTemplate void before(boolean actual, boolean expected) { assertEquals(actual, expected); } @BeforeTemplate void before(boolean actual, Boolean expected) { assertEquals(actual, expected); } @BeforeTemplate void before(Boolean actual, boolean expected) { assertEquals(actual, expected); } @BeforeTemplate void before(Boolean actual, Boolean expected) { assertEquals(actual, expected); } @BeforeTemplate void before(byte actual, byte expected) { assertEquals(actual, expected); } @BeforeTemplate void before(byte actual, Byte expected) { assertEquals(actual, expected); } @BeforeTemplate void before(Byte actual, byte expected) { assertEquals(actual, expected); } @BeforeTemplate void before(Byte actual, Byte expected) { assertEquals(actual, expected); } @BeforeTemplate void before(char actual, char expected) { assertEquals(actual, expected); } @BeforeTemplate void before(char actual, Character expected) { assertEquals(actual, expected); } @BeforeTemplate void before(Character actual, char expected) { assertEquals(actual, expected); } @BeforeTemplate void before(Character actual, Character expected) { assertEquals(actual, expected); } @BeforeTemplate void before(short actual, short expected) { assertEquals(actual, expected); } @BeforeTemplate void before(short actual, Short expected) { assertEquals(actual, expected); } @BeforeTemplate void before(Short actual, short expected) { assertEquals(actual, expected); } @BeforeTemplate void before(Short actual, Short expected) { assertEquals(actual, expected); } @BeforeTemplate void before(int actual, int expected) { assertEquals(actual, expected); } @BeforeTemplate void before(int actual, Integer expected) { assertEquals(actual, expected); } @BeforeTemplate void before(Integer actual, int expected) { assertEquals(actual, expected); } @BeforeTemplate void before(Integer actual, Integer expected) { assertEquals(actual, expected); } @BeforeTemplate void before(long actual, long expected) { assertEquals(actual, expected); } @BeforeTemplate void before(long actual, Long expected) { assertEquals(actual, expected); } @BeforeTemplate void before(Long actual, long expected) { assertEquals(actual, expected); } @BeforeTemplate void before(Long actual, Long expected) { assertEquals(actual, expected); } @BeforeTemplate void before(float actual, float expected) { assertEquals(actual, expected); } @BeforeTemplate void before(float actual, Float expected) { assertEquals(actual, expected); } @BeforeTemplate void before(Float actual, float expected) { assertEquals(actual, expected); } @BeforeTemplate void before(Float actual, Float expected) { assertEquals(actual, expected); } @BeforeTemplate void before(double actual, double expected) { assertEquals(actual, expected); } @BeforeTemplate void before(double actual, Double expected) { assertEquals(actual, expected); } @BeforeTemplate void before(Double actual, double expected) { assertEquals(actual, expected); } @BeforeTemplate void before(Double actual, Double expected) { assertEquals(actual, expected); } @BeforeTemplate void before(Object actual, Object expected) { assertEquals(actual, expected); } @BeforeTemplate void before(String actual, String expected) { assertEquals(actual, expected); } @BeforeTemplate void before(Map<?, ?> actual, Map<?, ?> expected) { assertEquals(actual, expected); } @AfterTemplate @UseImportPolicy(value = STATIC_IMPORT_ALWAYS) void after(Object actual, Object expected) { assertThat(actual).isEqualTo(expected); } } .
  • Reformat local variable names to camelCase - Reformat local variable and method parameter names to camelCase to comply with Java naming convention. The recipe will not rename variables declared in for loop controls or catches with a single character. The first character is set to lower case and existing capital letters are preserved. Special characters that are allowed in java field names $ and _ are removed (unless the name starts with one). If a special character is removed the next valid alphanumeric will be capitalized. Currently, does not support renaming members of classes. The recipe will not rename a variable if the result already exists in the class, conflicts with a java reserved keyword, or the result is blank.
  • Reformat private field names to camelCase - Reformat private field names to camelCase to comply with Java naming convention. The recipe will not rename fields with default, protected or public access modifiers. The recipe will not rename private constants. The first character is set to lower case and existing capital letters are preserved. Special characters that are allowed in java field names $ and _ are removed. If a special character is removed the next valid alphanumeric will be capitalized. The recipe will not rename a field if the result already exists in the class, conflicts with a java reserved keyword, or the result is blank.
  • Remove @Nullable and @CheckForNull annotations from primitives - Primitives can't be null anyway, so these annotations are not useful in this context.
  • Remove @RequestMapping annotations - Replace method declaration @RequestMapping annotations with @GetMapping, @PostMapping, etc. when possible.
  • Remove Object.finalize() invocations - Remove calls to Object.finalize(). This method is called during garbage collection and calling it manually is misleading.
  • Remove com.google.common.base.Optional#toJavaUtil() - Remove calls to com.google.common.base.Optional#toJavaUtil().
  • Remove finalize() method - Finalizers are deprecated. Use of finalize() can lead to performance issues, deadlocks, hangs, and other undesirable behavior.
  • Remove public visibility of JUnit 5 tests - Remove public and optionally protected modifiers from methods with @Test, @ParameterizedTest, @RepeatedTest, @TestFactory, @BeforeEach, @AfterEach, @BeforeAll, or @AfterAll. They no longer have to be public visibility to be usable by JUnit 5.
  • Remove toString() calls on arrays - The result from toString() calls on arrays is largely useless. The output does not actually reflect the contents of the array. Arrays.toString(array) should be used instead as it gives the contents of the array.
  • Remove empty blocks - Remove empty blocks that effectively do nothing.
  • Remove empty tests without comments - Removes empty methods with a @Test annotation if the body does not have comments.
  • Remove extra semicolons - Removes not needed semicolons. Semicolons are considered not needed: * Optional semicolons at the end of try-with-resources, * after the last enum value if no field or method is defined, * no statement between two semicolon.
  • Remove garbage collection invocations - Removes calls to System.gc() and Runtime.gc(). When to invoke garbage collection is best left to the JVM.
  • Remove redundant casts - Removes unnecessary type casts. Does not currently check casts in lambdas and class constructors.
  • Remove redundant null checks before instanceof - Removes redundant null checks before instanceof operations since instanceof returns false for null.
  • Remove unnecessary parentheses - Removes unnecessary parentheses from code where extra parentheses pairs are redundant.
  • Remove unused imports - Remove imports for types that are not referenced. As a precaution against incorrect changes no imports will be removed from any source where unknown types are referenced. The most common cause of unknown types is the use of annotation processors not supported by OpenRewrite, such as lombok.
  • Remove unused local variables - If a local variable is declared but not used, it is dead code and should be removed.
  • Remove unused private fields - If a private field is declared but not used in the program, it can be considered dead code and should therefore be removed.
  • Remove unused private methods - private methods that are never executed are dead code and should be removed.
  • Rename methods named hashcode, equal, or tostring - Methods should not be named hashcode, equal, or tostring. Any of these are confusing as they appear to be intended as overridden methods from the Object base class, despite being case-insensitive.
  • Rename packages to lowercase - By convention all Java package names should contain only lowercase letters, numbers, and dashes. This recipe converts any uppercase letters in package names to be lowercase.
  • Replace A.class.isInstance(a) with a instanceof A - There should be no A.class.isInstance(a), it should be replaced by a instanceof A.
  • Replace Stream.collect(Collectors.toUnmodifiableList()) with Stream.toList() - Replace Stream.collect(Collectors.toUnmodifiableList()) with Java 16+ Stream.toList(). Also replaces Stream.collect(Collectors.toList()) if convertToList is set to true.
  • Replace catch(Exception) with specific declared exceptions thrown in the try block - Replaces catch(Exception e) blocks with a multi-catch block (catch (SpecificException1 | SpecificException2 e)) containing only the exceptions declared thrown by method or constructor invocations within the try block that are not already caught by more specific catch clauses.
  • Replace com.google.common.base.Optional#fromJavaUtil(java.util.Optional) with argument - Replaces com.google.common.base.Optional#fromJavaUtil(java.util.Optional) with argument.
  • Replace fail() in try-catch blocks with Assertions.assertDoesNotThrow(() -> { ... }) - Replace try-catch blocks where catch merely contains a fail() for fail(String) statement with Assertions.assertDoesNotThrow(() -> { ... }).
  • Replace calls to Thread.run() with Thread.start() - Thread.run() should not be called directly.
  • Replace duplicate String literals - Replaces String literals with a length of 5 or greater repeated a minimum of 3 times. Qualified String literals include final Strings, method invocations, and new class invocations. Adds a new private static final String or uses an existing equivalent class field. A new variable name will be generated based on the literal value if an existing field does not exist. The generated name will append a numeric value to the variable name if a name already exists in the compilation unit.
  • Replace referential equality operators with Object equals method invocations when the operands both override Object.equals(Object obj) - Using == or != compares object references, not the equality of two objects. This modifies code where both sides of a binary operation (== or !=) override Object.equals(Object obj) except when the comparison is within an overridden Object.equals(Object obj) method declaration itself. The resulting transformation must be carefully reviewed since any modifications change the program's semantics.
  • Replaces Object.notify() with Object.notifyAll() - Object.notifyAll() and Object.notify() both wake up sleeping threads, but Object.notify() only rouses one while Object.notifyAll() rouses all of them. Since Object.notify() might not wake up the right thread, Object.notifyAll() should be used instead. See this for more information.
  • Secure random - Use cryptographically secure Pseudo Random Number Generation in the "main" source set. Replaces instantiation of java.util.Random with java.security.SecureRandom.
  • SecureRandom seeds are not constant or predictable - Remove SecureRandom#setSeed(*) method invocations having constant or predictable arguments.
  • Simplify AssertJ chained assertions - Many AssertJ chained assertions have dedicated assertions that function the same. It is best to use the dedicated assertions.
  • Simplify Arrays.asList(..) with varargs - Simplifies Arrays.asList() method calls that use explicit array creation to use varargs instead. For example, Arrays.asList(new String[]{"a", "b", "c"}) becomes Arrays.asList("a", "b", "c").
  • Simplify boolean expression - Checks for overly complicated boolean expressions, such as if (b == true), b || true, !false, etc.
  • Simplify boolean expressions using De Morgan's laws - Applies De Morgan's laws to simplify boolean expressions with negation. Transforms !(a && b) to !a || !b and !(a || b) to !a && !b.
  • Simplify boolean return - Simplifies Boolean expressions by removing redundancies. For example, a && true simplifies to a.
  • Standardize method name casing - Fixes method names that do not follow standard naming conventions. For example, String getFoo_bar() would be adjusted to String getFooBar() and int DoSomething() would be adjusted to int doSomething().
  • Static methods need not be final - Static methods do not need to be declared final because they cannot be overridden.
  • Structural equality tests should use == or != - In Kotlin, == means structural equality and != structural inequality and both map to the left-side term’s equals() function. It is, therefore, redundant to call equals() as a function. Also, == and != are more general than equals() and !equals() because it allows either of both operands to be null. Developers using equals() instead of == or != is often the result of adapting styles from other languages like Java, where == means reference equality and != means reference inequality. The == and != operators are a more concise and elegant way to test structural equality than calling a function.
  • Ternary operators should not be nested - Nested ternary operators can be hard to read quickly. Prefer simpler constructs for improved readability. If supported, this recipe will try to replace nested ternaries with switch expressions.
  • URL Equals - Uses of equals() cause java.net.URL to make blocking internet connections. Instead, use java.net.URI.
  • URL Equals and Hash Code - Uses of equals() and hashCode() cause java.net.URL to make blocking internet connections. Instead, use java.net.URI.
  • URL Hash Code - Uses of hashCode() cause java.net.URL to make blocking internet connections. Instead, use java.net.URI.
  • Unnecessary String#toString - Remove unnecessary String#toString invocations on objects which are already a string.
  • Unnecessary String#valueOf(..) - Replace unnecessary String#valueOf(..) method invocations with the argument directly. This occurs when the argument to String#valueOf(arg) is a string literal, such as String.valueOf("example"). Or, when the String#valueOf(..) invocation is used in a concatenation, such as "example" + String.valueOf("example").
  • Unnecessary close in try-with-resources - Remove unnecessary AutoCloseable#close() statements in try-with-resources.
  • Unnecessary throws - Remove unnecessary throws declarations. This recipe will only remove unused, checked exceptions if: - The declaring class or the method declaration is final. - The method declaration is static or private. - The method overrides a method declaration in a super class and the super class does not throw the exception. - The method is public or protected and the exception is not documented via a JavaDoc as a @throws tag.
  • Upper case literal suffixes - Using upper case literal suffixes for declaring literals is less ambiguous, e.g., 1l versus 1L.
  • Use Collection#isEmpty() instead of comparing size() - Also check for not isEmpty() when testing for not equal to zero size.
  • Use Collection interfaces - Use Deque, List, Map, ConcurrentMap, Queue, and Set instead of implemented collections. Replaces the return type of public method declarations and the variable type public variable declarations.
  • Use Collections#emptyList(), emptyMap(), and emptySet() - Replaces Collections#EMPTY_... with methods that return generic types.
  • Use Files#createTempDirectory - Use Files#createTempDirectory when the sequence File#createTempFile(..)->File#delete()->File#mkdir() is used for creating a temp directory.
  • Use String.equals() on String literals - String.equals() should be used when checking value equality on String literals. Using == or != compares object references, not the actual value of the Strings. This only modifies code where at least one side of the binary operation (== or !=) is a String literal, such as "someString" == someVariable;. This is to prevent inadvertently changing code where referential equality is the user's intent.
  • Use String::replace() when first parameter is not a real regular expression - When String::replaceAll is used, the first argument should be a real regular expression. If it’s not the case, String::replace does exactly the same thing as String::replaceAll without the performance drawback of the regex.
  • Use indexOf(String, int) - Replaces indexOf(String) in binary operations if the compared value is an int and not less than 1.
  • Use comparison rather than equality checks in for conditions - Testing for loop termination using an equality operator (== and !=) is dangerous, because it could set up an infinite loop. Using a relational operator instead makes it harder to accidentally write an infinite loop.
  • Use explicit types on lambda arguments - Adds explicit types on lambda arguments, which are otherwise optional. This can make the code clearer and easier to read. This does not add explicit types on arguments when the lambda has one or two parameters and does not have a block body, as things are considered more readable in those cases. For example, stream.map((a, b) -> a.length); will not have explicit types added.
  • Use lambda expressions instead of anonymous classes - Instead of anonymous class declarations, use a lambda where possible. Using lambdas to replace anonymous classes can lead to more expressive and maintainable code, improve code readability, reduce code duplication, and achieve better performance in some cases.
  • Use method references in lambda - Replaces the single statement lambdas o -> o instanceOf X, o -> (A) o, o -> System.out.println(o), o -> o != null, o -> o == null with the equivalent method reference.
  • Use primitive wrapper valueOf method - The constructor of all primitive types has been deprecated in favor of using the static factory method valueOf available for each of the primitive type wrappers.
  • Use the diamond operator - The diamond operator (<>) should be used. Java 7 introduced the diamond operator to reduce the verbosity of generics code. For instance, instead of having to declare a List's type in both its declaration and its constructor, you can now simplify the constructor declaration with <>, and the compiler will infer the type.
  • Week Year (YYYY) should not be used for date formatting - For most dates Week Year (YYYY) and Year (yyyy) yield the same results. However, on the last week of December and the first week of January, Week Year could produce unexpected results.
  • Wrapping and braces - Format line wraps and braces in Java code.
  • Write octal values as decimal - Developers may not recognize octal values as such, mistaking them instead for decimal values.
  • BigDecimal rounding constants to RoundingMode enums - Convert BigDecimal rounding constants to the equivalent RoundingMode enum.
  • Externalizable classes have no-arguments constructor - Externalizable classes handle both serialization and deserialization and must have a no-args constructor for the deserialization process.
  • finalize() calls super - Overrides of Object#finalize() should call super.
  • for loop counters incremented in update - The increment should be moved to the loop's increment clause if possible.
  • hashCode() should not be called on array instances - Replace hashCode() calls on arrays with Arrays.hashCode() because the results from hashCode() are not helpful.
  • indexOf() replaceable by contains() - Checking if a value is included in a String or List using indexOf(value)>-1 or indexOf(value)>=0 can be replaced with contains(value).
  • indexOf should not compare greater than zero - Replaces String#indexOf(String) > 0 and List#indexOf(Object) > 0 with >=1. Checking indexOf against >0 ignores the first element, whereas >-1 is inclusive of the first element. For clarity, >=1 is used, because >0 and >=1 are semantically equal. Using >0 may appear to be a mistake with the intent of including all elements. If the intent is to check whether a value in included in a String or List, the String#contains(String) or List#contains(Object) methods may be better options altogether.
  • it shouldn't be used as a lambda parameter name - it is a special identifier that allows you to refer to the current parameter being passed to a lambda expression without explicitly naming the parameter. Lambda expressions are a concise way of writing anonymous functions. Many lambda expressions have only one parameter, when this is true the compiler can determine the parameter type by context. Thus when using it with single parameter lambda expressions, you do not need to declare the type.
  • new BigDecimal(double) should not be used - Use of new BigDecimal(double) constructor can lead to loss of precision. Use BigDecimal.valueOf(double) instead. For example writing new BigDecimal(0.1) does not create a BigDecimal which is exactly equal to 0.1, but it is equal to 0.1000000000000000055511151231257827021181583404541015625. This is because 0.1 cannot be represented exactly as a double (or, for that matter, as a binary fraction of any finite length).
  • switch statements should have at least 3 case clauses - switch statements are useful when many code paths branch depending on the value of a single expression. For just one or two code paths, the code will be more readable with if statements.

sap​

1 recipe

scala​

1 recipe

schemas​

37 recipes

sdk​

4 recipes

1 recipe

secrets​

1 recipe

  • Replace OSSRH secrets with Sonatype secrets - Replace deprecated OSSRH_S01 secrets with new Sonatype secrets in GitHub Actions workflows. This is an example use of the ReplaceSecrets and ReplaceSecretKeys recipes combined used to update the Maven publishing secrets in OpenRewrite's GitHub organization.

security​

52 recipes

servlet​

1 recipe

sleuth​

1 recipe

slf4j​

12 recipes

  • Enhances logging of exceptions by including the full stack trace in addition to the exception message - It is a common mistake to call Exception.getMessage() when passing an exception into a log method. Not all exception types have useful messages, and even if the message is useful this omits the stack trace. Including a complete stack trace of the error along with the exception message in the log allows developers to better understand the context of the exception and identify the source of the error more quickly and accurately. If the method invocation includes any call to Exception.getMessage() or Exception.getLocalizedMessage() and not an exception is already passed as the last parameter to the log method, then we will append the exception as the last parameter in the log method.
  • Loggers should be named for their enclosing classes - Ensure LoggerFactory#getLogger(Class) is called with the enclosing class as argument.
  • Migrate Apache Commons Logging 1.x to SLF4J 1.x - Transforms usages of Apache Commons Logging 1.x to leveraging SLF4J 1.x directly.
  • Migrate JBoss Logging to SLF4J - Migrates usage of the JBoss Logging facade to using SLF4J.
  • Migrate JUL to SLF4J - Migrates usage of Java Util Logging (JUL) to using SLF4J directly.
  • Migrate Log4j 1.x to SLF4J 1.x - Transforms usages of Log4j 1.x to leveraging SLF4J 1.x directly. Note, this currently does not modify log4j.properties files.
  • Migrate Log4j 2.x to SLF4J 1.x - Transforms usages of Log4j 2.x to leveraging SLF4J 1.x directly. Note, this currently does not modify log4j.properties files.
  • Migrate Log4j to SLF4J - Migrates usage of Apache Log4j to using SLF4J directly. Use of the traditional Log4j to SLF4J bridge can result in loss of performance, as the Log4j messages must be formatted before they can be passed to SLF4J. Note, this currently does not modify log4j.properties files.
  • Migrate SLF4J to Log4j 2.x API - Transforms code written using SLF4J to use Log4j 2.x API.
  • Parameterize SLF4J's logging statements - Use SLF4J's parameterized logging, which can significantly boost performance for messages that otherwise would be assembled with String concatenation. Particularly impactful when the log level is not enabled, as no work is done to assemble the message.
  • SLF4J best practices - Applies best practices to logging with SLF4J.
  • SLF4J logging statements should begin with constants - Logging statements shouldn't begin with String#format, calls to toString(), etc.

spring​

80 recipes

  • Comment deprecated methods in Spring 3.4 - Spring Boot 3.4 deprecates methods that are not commonly used or need manual interaction.
  • Downgrade Jakarta Servlet API to 5.0 when using Jetty - Jetty does not yet support Servlet 6.0. This recipe will detect the presence of the spring-boot-starter-jetty as a first-order dependency and will add the maven property jakarta-servlet.version setting it's value to 5.0.0. This will downgrade the jakarta-servlet artifact if the pom's parent extends from the spring-boot-parent.
  • Find patterns that require updating for Spring Boot 2.5 - Looks for a series of patterns that have not yet had auto-remediation recipes developed for.
  • Find projects affected by changes to the default error view message attribute - As of Spring Boot 2.5 the message attribute in the default error view was removed rather than blanked when it is not shown. spring-webmvc or spring-webflux projects that parse the error response JSON may need to deal with the missing item (release notes). You can still use the server.error.include-message property if you want messages to be included.
  • Finds uses of Encryptors.queryableText() - Encryptors.queryableText() is insecure and is removed in Spring Security 6.
  • Migrate Enabled to Access Spring Boot Properties - Migrate properties found in application.properties and application.yml, specifically converting 'enabled' to 'access'
  • Migrate SAP cloud foundry logging support to Spring Boot 3.x - Migrate SAP cloud foundry logging support from cf-java-logging-support-servlet to cf-java-logging-support-servlet-jakarta, to use Jakarta with Spring Boot 3.
  • Migrate Spring Boot 2.x projects to JUnit 5 from JUnit 4 - This recipe will migrate a Spring Boot application's tests from JUnit 4 to JUnit 5. This spring-specific migration includes conversion of Spring Test runners to Spring Test extensions and awareness of the composable Spring Test annotations.
  • Migrate Spring Boot 3.5 deprecated classes and methods - Migrate deprecated classes and methods that have been marked for removal in Spring Boot 3.5.
  • Migrate Spring Boot properties to 2.0 - Migrate properties found in application.properties and application.yml.
  • Migrate Spring Boot properties to 2.1 - Migrate properties found in application.properties and application.yml.
  • Migrate Spring Boot properties to 2.2 - Migrate properties found in application.properties and application.yml.
  • Migrate Spring Boot properties to 2.3 - Migrate properties found in application.properties and application.yml.
  • Migrate Spring Boot properties to 2.4 - Migrate properties found in application.properties and application.yml.
  • Migrate Spring Boot properties to 2.5 - Migrate properties found in application.properties and application.yml.
  • Migrate Spring Boot properties to 2.6 - Migrate properties found in application.properties and application.yml.
  • Migrate Spring Boot properties to 2.7 - Migrate properties found in application.properties and application.yml.
  • Migrate Spring Boot properties to 3.0 - Migrate properties found in application.properties and application.yml.
  • Migrate Spring Boot properties to 3.1 - Migrate properties found in application.properties and application.yml.
  • Migrate Spring Boot properties to 3.2 - Migrate properties found in application.properties and application.yml.
  • Migrate Spring Boot properties to 3.3 - Migrate properties found in application.properties and application.yml.
  • Migrate Spring Boot properties to 3.4 - Migrate properties found in application.properties and application.yml.
  • Migrate Spring Boot properties to 3.5 - Migrate properties found in application.properties and application.yml.
  • Migrate Spring Boot properties to 4.0 - Migrate properties found in application.properties and application.yml.
  • Migrate Spring Cloud Sleuth 3.1 to Micrometer Tracing 1.0 - Spring Cloud Sleuth has been discontinued and only compatible with Spring Boot 2.x.
  • Migrate Spring Cloud properties to 2020 - Migrate properties found in application.properties and application.yml.
  • Migrate Spring Cloud properties to 2021 - Migrate properties found in application.properties and application.yml.
  • Migrate Spring Cloud properties to 2022 - Migrate properties found in application.properties and application.yml.
  • Migrate Spring Cloud properties to 2023 - Migrate properties found in application.properties and application.yml.
  • Migrate Spring Cloud properties to 2024 - Migrate properties found in application.properties and application.yml.
  • Migrate Spring Cloud properties to 2025 - Migrate properties found in application.properties and application.yml.
  • Migrate Spring to Spring Boot - Migrate non Spring Boot applications to the latest compatible Spring Boot release. This recipe will modify an application's build files introducing Maven dependency management for Spring Boot, or adding the Gradle Spring Boot build plugin.
  • Migrate @Endpoint Security properties to 3.4 - Migrate the settings for Spring Boot Management Endpoint Security from true|false to read-only|none.
  • Migrate dropWizard dependencies to Spring Boot 3.x - Migrate dropWizard dependencies to the new artifactId, since these are changed with Spring Boot 3.
  • Migrate from Spring Boot 1.x to 2.0 - Migrate Spring Boot 1.x applications to the latest Spring Boot 2.0 release. This recipe will modify an application's build files, make changes to deprecated/preferred APIs, and migrate configuration settings that have changes between versions. This recipe will also chain additional framework migrations (Spring Framework, Spring Data, etc) that are required as part of the migration to Spring Boot 2.0.
  • Migrate rider-spring (JUnit4) to rider-junit5 (JUnit5) - This recipe will migrate the necessary dependencies and annotations from DbRider with JUnit4 to JUnit5 in a Spring application.
  • Migrate thymeleaf dependencies to Spring Boot 3.x - Migrate thymeleaf dependencies to the new artifactId, since these are changed with Spring Boot 3.
  • Migrate to Spring Batch 5.0 from 4.3 - Migrate applications built on Spring Batch 4.3 to the latest Spring Batch 5.0 release.
  • Migrate to Spring Boot 2.1 - Migrate applications to the latest Spring Boot 2.1 release. This recipe will modify an application's build files, make changes to deprecated/preferred APIs, and migrate configuration settings that have changes between versions. This recipe will also chain additional framework migrations (Spring Framework, Spring Data, etc) that are required as part of the migration to Spring Boot 2.1.
  • Migrate to Spring Boot 2.2 - Migrate applications to the latest Spring Boot 2.2 release. This recipe will modify an application's build files, make changes to deprecated/preferred APIs, and migrate configuration settings that have changes between versions. This recipe will also chain additional framework migrations (Spring Framework, Spring Data, etc) that are required as part of the migration to Spring Boot 2.2.
  • Migrate to Spring Boot 2.3 - Migrate applications to the latest Spring Boot 2.3 release. This recipe will modify an application's build files, make changes to deprecated/preferred APIs, and migrate configuration settings that have changes between versions. This recipe will also chain additional framework migrations (Spring Framework, Spring Data, etc) that are required as part of the migration to Spring Boot 2.3.
  • Migrate to Spring Boot 2.4 - Migrate applications to the latest Spring Boot 2.4 release. This recipe will modify an application's build files, make changes to deprecated/preferred APIs, and migrate configuration settings that have changes between versions. This recipe will also chain additional framework migrations (Spring Framework, Spring Data, etc) that are required as part of the migration to Spring Boot 2.4.
  • Migrate to Spring Boot 2.6 - Migrate applications to the latest Spring Boot 2.6 release. This recipe will modify an application's build files, make changes to deprecated/preferred APIs, and migrate configuration settings that have changes between versions. This recipe will also chain additional framework migrations (Spring Framework, Spring Data, etc) that are required as part of the migration to Spring Boot 2.6.
  • Migrate to Spring Boot 3.0 - Migrate applications to the latest Spring Boot 3.0 release. This recipe will modify an application's build files, make changes to deprecated/preferred APIs, and migrate configuration settings that have changes between versions. This recipe will also chain additional framework migrations (Spring Framework, Spring Data, etc) that are required as part of the migration to Spring Boot 2.7.
  • Migrate to Spring Boot 3.1 - Migrate applications to the latest Spring Boot 3.1 release. This recipe will modify an application's build files, make changes to deprecated/preferred APIs, and migrate configuration settings that have changes between versions. This recipe will also chain additional framework migrations (Spring Framework, Spring Data, etc) that are required as part of the migration to Spring Boot 3.0.
  • Migrate to Spring Boot 3.2 - Migrate applications to the latest Spring Boot 3.2 release. This recipe will modify an application's build files, make changes to deprecated/preferred APIs, and migrate configuration settings that have changes between versions. This recipe will also chain additional framework migrations (Spring Framework, Spring Data, etc) that are required as part of the migration to Spring Boot 3.1.
  • Migrate to Spring Boot 3.3 - Migrate applications to the latest Spring Boot 3.3 release. This recipe will modify an application's build files, make changes to deprecated/preferred APIs, and migrate configuration settings that have changes between versions. This recipe will also chain additional framework migrations (Spring Framework, Spring Data, etc) that are required as part of the migration to Spring Boot 3.2.
  • Migrate to Spring Boot 3.4 - Migrate applications to the latest Spring Boot 3.4 release. This recipe will modify an application's build files, make changes to deprecated/preferred APIs, and migrate configuration settings that have changes between versions. This recipe will also chain additional framework migrations (Spring Framework, Spring Data, etc) that are required as part of the migration to Spring Boot 3.4.
  • Migrate to Spring Boot 3.4 - Migrate applications to the latest Spring Boot 3.4 release. This recipe will modify an application's build files, make changes to deprecated/preferred APIs.
  • Migrate to Spring Boot 3.5 - Migrate applications to the latest Spring Boot 3.5 release. This recipe will modify an application's build files, make changes to deprecated/preferred APIs, and migrate configuration settings that have changes between versions. This recipe will also chain additional framework migrations (Spring Framework, Spring Data, etc) that are required as part of the migration to Spring Boot 3.5.
  • Migrate to Spring Cloud 2022 - Migrate applications to the latest Spring Cloud 2022 (Kilburn) release.
  • Migrate to Spring Cloud 2023 - Migrate applications to the latest Spring Cloud 2023 (Leyton) release.
  • Migrate to Spring Cloud 2024 - Migrate applications to the latest Spring Cloud 2024 (Moorgate) release.
  • Migrate to Spring Cloud 2025 - Migrate applications to the latest Spring Cloud 2025 (Northfields) release.
  • Migrate to Spring Kafka 3.0 - Migrate applications to the latest Spring Kafka 3.0 release.
  • Migrate to Spring Kafka 3.3 - Migrate applications to the latest Spring Kafka 3.3 release.
  • Migrate to Spring Security 5.7 - Migrate applications to the latest Spring Security 5.7 release. This recipe will modify an application's build files, make changes to deprecated/preferred APIs, and migrate configuration settings that have changes between versions.
  • Migrate to Spring Security 5.8 - Migrate applications to the latest Spring Security 5.8 release. This recipe will modify an application's build files, make changes to deprecated/preferred APIs, and migrate configuration settings that have changes between versions.
  • Migrate to Spring Security 6.0 - Migrate applications to the latest Spring Security 6.0 release. This recipe will modify an application's build files, make changes to deprecated/preferred APIs, and migrate configuration settings that have changes between versions.
  • Migrate to Spring Security 6.1 - Migrate applications to the latest Spring Security 6.1 release. This recipe will modify an application's build files, make changes to deprecated/preferred APIs, and migrate configuration settings that have changes between versions.
  • Migrate to Spring Security 6.2 - Migrate applications to the latest Spring Security 6.2 release. This recipe will modify an application's build files, make changes to deprecated/preferred APIs, and migrate configuration settings that have changes between versions.
  • Migrate to Spring Security 6.3 - Migrate applications to the latest Spring Security 6.3 release. This recipe will modify an application's build files, make changes to deprecated/preferred APIs, and migrate configuration settings that have changes between versions.
  • Migrate to Spring Security 6.4 - Migrate applications to the latest Spring Security 6.4 release. This recipe will modify an application's build files, make changes to deprecated/preferred APIs, and migrate configuration settings that have changes between versions.
  • Remove the deprecated properties additional-keys-to-sanitize from the configprops and env end points - Spring Boot 3.0 removed the key-based sanitization mechanism used in Spring Boot 2.x in favor of a unified approach. See https://github.com/openrewrite/rewrite-spring/issues/228
  • Remove unnecessary use-authorization-manager for message security in Spring security 6 - In Spring Security 6, <websocket-message-broker> defaults use-authorization-manager to true. So, the use-authorization-manager attribute for message security is no longer needed and can be removed.
  • Rename server.max-http-header-size to server.max-http-request-header-size - Previously, the server.max-http-header-size was treated inconsistently across the four supported embedded web servers. When using Jetty, Netty, or Undertow it would configure the max HTTP request header size. When using Tomcat it would configure the max HTTP request and response header sizes. The renamed property is used to configure the http request header size in Spring Boot 3.0. To limit the max header size of an HTTP response on Tomcat or Jetty (the only two servers that support such a setting), use a WebServerFactoryCustomizer.
  • Rename the package name from com.nimbusds.jose.shaded.json to net.minidev.json - Rename the package name from com.nimbusds.jose.shaded.json to net.minidev.json.
  • Replace global method security with method security - @EnableGlobalMethodSecurity and <global-method-security> are deprecated in favor of @EnableMethodSecurity and <method-security>, respectively. The new annotation and XML element activate Spring’s pre-post annotations by default and use AuthorizationManager internally.
  • Spring Boot 2.x best practices - Applies best practices to Spring Boot 2 applications.
  • Spring Boot 3.3 best practices - Applies best practices to Spring Boot 3 applications.
  • Spring Boot 3.3 best practices (only) - Applies best practices to Spring Boot 3 applications, without chaining in upgrades to Spring Boot.
  • Spring Boot 3.5 best practices - Applies best practices to Spring Boot 3.5+ applications.
  • Update OpenTelemetry resource attributes - The service.group resource attribute has been deprecated for OpenTelemetry in Spring Boot 3.5. Consider using alternative attributes or remove the deprecated attribute.
  • Upgrade Gradle 8 to 8.4+ for Spring Boot 3.4 - Spring Boot 3.4 requires Gradle 8.4+.
  • Upgrade Gradle to 7.6.4+ for Spring Boot 3.4 - Spring Boot 3.4 requires Gradle 7.6.4.
  • Upgrade dependencies to Spring Cloud 2022 - Upgrade dependencies to Spring Cloud 2022 from prior 2021.x version.
  • Upgrade dependencies to Spring Cloud 2023 - Upgrade dependencies to Spring Cloud 2023 from prior 2022.x version.
  • Upgrade dependencies to Spring Cloud 2024 - Upgrade dependencies to Spring Cloud 2024 from prior 2023.x version.
  • Upgrade dependencies to Spring Cloud 2025 - Upgrade dependencies to Spring Cloud 2025 from prior 2024.x version.
  • Use bean name applicationTaskExecutor instead of taskExecutor - Spring Boot 3.5 removed the bean name taskExecutor. Where this bean name is used, the recipe replaces the bean name to applicationTaskExecutor. This also includes instances where the developer provided their own bean named taskExecutor. This also includes scenarios where JSR-250's @Resource annotation is used.

springdata​

2 recipes

springdoc​

9 recipes

springfox​

2 recipes

springframework​

9 recipes

sqlserver​

1 recipe

storybook​

9 recipes

stylistic​

87 recipes

svelte​

18 recipes

swagger​

9 recipes

taglib​

3 recipes

taglibs​

1 recipe

terraform​

114 recipes

test​

2 recipes

testing​

40 recipes

testng​

1 recipe

testwebxml​

1 recipe

thymeleaf​

1 recipe

tld​

1 recipe

tracing​

1 recipe

transaction​

2 recipes

unaffected​

1 recipe

underscore​

4 recipes

validation​

3 recipes

var​

1 recipe

  • Use local variable type inference - Apply local variable type inference (var) for primitives and objects. These recipes can cause unused imports, be advised to run `org.openrewrite.java.RemoveUnusedImports afterwards.

virtual​

2 recipes

  • Find Virtual Thread opportunities - Find opportunities to convert existing code to use Virtual Threads.
  • Find non-virtual ExecutorService creation - Find all places where static java.util.concurrent.Executors method creates a non-virtual java.util.concurrent.ExecutorService. This recipe can be used to search fro ExecutorService that can be replaced by Virtual Thread executor.

vue​

57 recipes

web​

7 recipes

weblogic​

56 recipes

webservices​

5 recipes

webxml​

1 recipe

wsee​

4 recipes

xhtml​

1 recipe

xjb​

1 recipe

xmlunit​

1 recipe