Add `rewrite` support by Pankraz76 · Pull Request #10963 · jenkinsci/jenkins

Pankraz76 · 2025-08-13T10:20:04Z

See JENKINS-XXXXX.

Testing done

Proposed changelog entries

human-readable text

Proposed changelog category

/label

Proposed upgrade guidelines

N/A

Submitter checklist

The Jira issue, if it exists, is well-described.
The changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developers, depending on the change) and are in the imperative mood (see examples). Fill in the Proposed upgrade guidelines section only if there are breaking changes or changes that may require extra steps from users during upgrade.
There is automated testing or an explanation as to why this change has no tests.
New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadocs, as appropriate.
New deprecations are annotated with @Deprecated(since = "TODO") or @Deprecated(forRemoval = true, since = "TODO"), if applicable.
New or substantially changed JavaScript is not defined inline and does not call eval to ease future introduction of Content Security Policy (CSP) directives (see documentation).
For dependency updates, there are links to external changelogs and, if possible, full differentials.
For new APIs and extension points, there is a link to at least one consumer.

Desired reviewers

@mention

Before the changes are marked as ready-for-merge:

Maintainer checklist

There are at least two (2) approvals for the pull request and no outstanding requests for change.
Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
Proper changelog labels are set so that the changelog can be generated automatically.
If the change needs additional upgrade steps from users, the upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the pull request title (see example).
If it would make sense to backport the change to LTS, a Jira issue must exist, be a Bug or Improvement, and be labeled as lts-candidate to be considered (see query).

Add `rewrite` support for `errorprone.refasterrules`

I’d like to propose integrating Google’s Error Prone and its Picnic extension (demonstrated in Automating Away Bugs with Error Prone | PlatformCon 2023) to enable automated bug fixes via rewrite rules. This would complement Checkstyle’s static analysis capabilities by addressing semantic bugs rather than stylistic issues.

Motivation

Error Prone’s refaster/rewrite rules can automatically:

Fix common bug patterns (e.g., String.equals() misuse)
Modernize code (e.g., JDK migration helpers)
Enforce best practices (e.g., null-check improvements)

Real-world adoptions show tangible benefits:

Proposal

Add support for errorprone.refasterrules-based rewrites
Implement with opt-in adoption (no breaking changes)
Include suppression mechanisms for API constraints

Discussion Points

Need consensus on:
- Scope of auto-fixes
- Preferred suppression strategy
- Integration approach

Next Steps

I’m happy to:

Prepare a PoC demonstrating the value
Collaborate on implementation strategy
Address any concerns about compatibility

relates to:

github-actions · 2025-08-13T10:20:15Z

Missing required label for changelog. Requires at least 1 of: bug, developer, dependencies, internal, localization, major-bug, major-rfe, rfe, regression-fix, removed, skip-changelog. Found: .

You can add the required label by adding a comment with the following text: /label <category>

Pankraz76 · 2025-08-13T10:23:11Z

pom.xml

              <goals>
                <goal>check</goal>
              </goals>
-              <phase>validate</phase>


cant compile like this to use rewrite for auto fix issues.

PMD and check both use verify goal too.

pom.xml

Pankraz76

ApiTokenStats

pom.xml

rewrite.yml

CONTRIBUTING.md

NotMyFault · 2025-08-13T19:48:58Z

I fail to see how this is of use. The linked real-world examples are draft PRs outlined as PoC, implying there is no real-world example of this yet.
While you have provided a motivation, there's no rationale answering why the Jenkins project would want to move to this approach.

Pankraz76 · 2025-08-14T08:23:11Z

implying there is no real-world example of this yet.

The Need for Quality Enforcement in Jenkins

I wouldn’t waste time on this if there weren’t so much waiting to be fixed, rewritten, or addressed. The current de facto standard leaves a massive gap, especially with all the unused code lingering around. This either suggests Jenkins doesn’t prioritize quality—or fails to enforce it.

Failing to act isn’t the issue; tools exist to solve this. But if this is intentionally ignored, then just admit that all this unused clutter serves some "magical benefit." Elsewhere, it’d be labeled technical debt—yet here, it persists unchecked.

Static Analysis: A Non-Negotiable Standard

The Checkstyle project recognizes this: without static code analysis enforcing quality gates, you get quantity—not quality.

Given the endless security flaws, bugs, and vulnerabilities, every project needs static analysis. Jenkins seems to grasp this, leveraging tools like SpotBugs, SonarLint, and Checkstyle. Yet PMD remains excluded—a tool that could purge the unused garbage polluting the codebase.

Apply staticanalysis.RemoveUnused* #10964

Pankraz76 · 2025-08-14T08:24:22Z

Add `rewrite` support for `errorprone.refasterrules`

I’d like to propose integrating Google’s Error Prone and its Picnic extension (demonstrated in Automating Away Bugs with Error Prone | PlatformCon 2023) to enable automated bug fixes via rewrite rules. This would complement Checkstyle’s static analysis capabilities by addressing semantic bugs rather than stylistic issues.

Motivation

Error Prone’s refaster/rewrite rules can automatically:

Fix common bug patterns (e.g., String.equals() misuse)
Modernize code (e.g., JDK migration helpers)
Enforce best practices (e.g., null-check improvements)

Real-world adoptions show tangible benefits:

Proposal

Add support for errorprone.refasterrules-based rewrites
Implement with opt-in adoption (no breaking changes)
Include suppression mechanisms for API constraints

Discussion Points

Need consensus on:
- Scope of auto-fixes
- Preferred suppression strategy
- Integration approach

Next Steps

I’m happy to:

Prepare a PoC demonstrating the value
Collaborate on implementation strategy
Address any concerns about compatibility

relates to:

Pankraz76 · 2025-08-14T09:01:56Z

yes defacto the whole project it broken by design...

Pankraz76 · 2025-08-14T09:02:30Z

activate missing check goal of maven-spotless-plugin #10968

Pankraz76 · 2025-08-14T09:03:09Z

applying spotless changes everything this has to be done once or the config needs to be aligned with check. Its only possible because spotless is not activated by default...

Pankraz76 · 2025-08-14T09:40:50Z

first need to fix current project setup:

activate missing check goal of maven-spotless-plugin #10968

Pankraz76 · 2025-08-14T10:10:29Z

implying there is no real-world example of this yet.

Just because its not merged yet, does not mean, it does not exist or work.

Of course there are several projects, including rewrite itself, using autofix up for issues/flaws/errors, whatsoever.

Considering the overall broken project configuration, it seem to be a good time to increment, improve, and care about the project in general, considering it large-scale.

No offence given, just want to help and address things clearly.

NotMyFault · 2025-08-14T13:44:55Z

There's too much fuzz in the spam of PRs you have created to see a clear goal and strategy.

I recommend opening one PR with a motivation, opening it for discussion on the mailing list, and waiting to get it merged before opening more without clear consensus if this is the approach we want to take.

Additionally, for better readability, I recommend editing the PR body instead of commenting over and over to your monologue; this is incredibly difficult to follow across all PRs, plus it creates plenty of unnecessary emails we need to work through...

Instead of creating PRs over and over again, you can mark them as draft and push your changes until you are fine with them, marking your PR as ready for review afterward. There's no need to create a new PR every time.

Pankraz76 · 2025-08-14T14:20:09Z

Yes, please excuse.

NotMyFault · 2025-08-14T14:29:26Z

Yes, please excuse.

And yet you have created more PRs instead of reworking/implementing my suggestions.
I consider this harmful spam at this point. I'll close all open PRs and/or block you from the organization, if this doesn't stop.

Edit: I took a brief look over your other contributions approaching these kinds of PRs. It looks - at least to me - that many maintainers reject or are not interested in these.
The Jenkins project will likely join the other maintainers here and reject this radical approach as well.

Pankraz76 · 2025-08-14T14:34:50Z

no it was bad timing. Your comment was behind by creations.