Skip to content

Add FindThreadGroupUsages recipe (RSPEC-S3014) - #1063

Merged
steve-aom-elliott merged 1 commit into
mainfrom
find-thread-group-usages
Sep 16, 2026
Merged

steve-aom-elliott merged 1 commit into
mainfrom
find-thread-group-usages

Conversation

@steve-aom-elliott

Copy link
Copy Markdown
Contributor

Summary

Adds a search-only recipe that flags uses of java.lang.ThreadGroup. ThreadGroup was originally intended to help with thread management, but its API has serious design flaws — most methods are deprecated or unsafe, and modern code should use java.util.concurrent.ExecutorService instead.

Implements SonarQube RSPEC-S3014.

Design notes

  • Precondition: UsesType<>("java.lang.ThreadGroup") OR UsesMethod<>("java.lang.Thread getThreadGroup()") — the visitor only walks CUs that could match.
  • Three flag sites:
    1. new ThreadGroup(...)visitNewClass + TypeUtils.isOfClassType.
    2. Thread.getThreadGroup() — dedicated MethodMatcher.
    3. Method invocations on a ThreadGroup receiver (e.g. group.activeCount()) — checks m.getSelect().getType().
  • Search-only. Migrating off ThreadGroup typically requires introducing an executor and restructuring how threads are grouped; not automatable.
  • estimatedEffortPerOccurrence = 30 minutes — realistic manual fix cost, higher than a call-removal recipe.

Files

  • src/main/java/org/openrewrite/staticanalysis/FindThreadGroupUsages.java
  • src/test/java/org/openrewrite/staticanalysis/FindThreadGroupUsagesTest.java — 5 tests
  • src/main/resources/META-INF/rewrite/recipes.csv — regenerated (single-row addition, no drift)

Test plan

  • ./gradlew compileJava — passes
  • ./gradlew test --tests FindThreadGroupUsagesTest — 5/5 green
  • ./gradlew recipeCsvGenerate recipeCsvValidateContent — clean

Test coverage

  1. new ThreadGroup("workers") → flagged (also verifies surrounding new Thread(group, ...) and t.start() are not flagged) — @DocumentExample
  2. Thread.currentThread().getThreadGroup() → flagged
  3. group.activeCount() where group is a ThreadGroup parameter → flagged
  4. Plain new Thread(...) / setName / start / interrupt → not flagged (negative)
  5. User-defined com.example.ThreadGroup class → not flagged (confirms FQN matching, not simple-name matching)

Marks uses of `java.lang.ThreadGroup`, which was originally intended to
help with thread management but has serious design flaws: most methods
are deprecated or unsafe, and modern code should use
`java.util.concurrent.ExecutorService` instead.

Sites flagged:
- `new ThreadGroup(...)` constructor calls
- `Thread.getThreadGroup()` method calls
- Method invocations on `ThreadGroup` receivers

Search-only. Migrating off `ThreadGroup` typically requires
introducing an executor and restructuring how threads are grouped,
which is not automatable.

Tags the recipe with RSPEC-S3014.
@github-project-automation github-project-automation Bot moved this to In Progress in OpenRewrite Sep 16, 2026
@steve-aom-elliott steve-aom-elliott moved this from In Progress to Ready to Review in OpenRewrite Sep 16, 2026
@steve-aom-elliott
steve-aom-elliott marked this pull request as ready for review September 16, 2026 19:45
@bblincoe
bblincoe self-requested a review September 16, 2026 19:50
@steve-aom-elliott
steve-aom-elliott merged commit 80e6964 into main Sep 16, 2026
1 check passed
@steve-aom-elliott
steve-aom-elliott deleted the find-thread-group-usages branch September 16, 2026 19:51
@github-project-automation github-project-automation Bot moved this from Ready to Review to Done in OpenRewrite Sep 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

3 participants