Introduce linters to protect and maintain code quality.

[tyzerrr]

SSIA
I prefer to introduce this, built by Netflix.

[tyzerrr]

@draeger Could I take this issue?
I will make CI/CD pipeline with Github Actions.

Goal is below.
[Goal of this issue]

1. Build the way to check whether all tests and all lint check pass or not.
2. Migrate from maven to gradle, this is related Migrate from Maven to Gradle #77.

If I can understand how to migrate from Gradle, I'll also take this issue.
If you think this is fine, could you assign me, and also could you make me Maintainer of this project?
I think this is one of the greatest contribution.

[baranwalayush]

@tyzerrr @draeger I've been reading about this recently and I think maven already supports almost everything associated with "linting". Like, we can use spotless for formatting, checkstyle for style checks and others. We can integrate it with the CI/CD pipeline too. Let me know what do you think. I'd be happy to dive deeper in this, if required.

[draeger]

Dear @baranwalayush, thank you for looking into this.

I agree that Maven already provides a good ecosystem for code quality checks, so I do not see an immediate need to switch build systems for this purpose.

Before we proceed, it would be helpful to have a concrete proposal. For example:

• Which tools would you recommend introducing (e.g., Spotless, Checkstyle, SpotBugs, PMD)?
• Which rulesets would be enabled initially?
• How many violations do these tools currently report on SBSCL?
• Would you suggest fixing all existing violations, or only enforcing the rules for newly introduced code?
• How would the checks be integrated into the CI pipeline?

If you are interested in working on this, I would be happy to review a short proposal or proof-of-concept pull request.

[baranwalayush]

Hi @draeger, I've put together a short proposal for this.

Key Highlights:

• Tooling: Spotless (Google Java Format), Checkstyle, SpotBugs, and PMD integrated directly into Maven (no Gradle migration required).
• Strategy: Start with a conservative initial ruleset and focus on blocking new violations via GitHub Actions CI rather than rewriting legacy code all at once.
• Incremental Rollout: A 6-phase implementation starting from baseline measurements to CI integration.

Complete Proposal:
Please find the complete proposal here: Proposal Document

Feedback and suggestions are welcome!

[draeger]

Thanks a lot for putting this together and for already running the different tools against the current codebase, @baranwalayush. This is very helpful, and I generally like the proposed direction, particularly keeping Maven and introducing the checks incrementally.

I would prefer to keep the individual changes small and reviewable rather than introducing all tools and fixing existing violations at once. In particular, reformatting 234 of 247 files with Google Java Format would be a rather substantial change on its own, so I think we should discuss the formatting conventions separately before applying them repository-wide.

For SpotBugs and PMD, I also agree with establishing a baseline first. Existing findings should not automatically block new PRs. It would be particularly interesting to inspect the high-confidence findings (e.g., the SpotBugs correctness issues) separately.

One change I would suggest to the proposed rollout is to introduce the basic GitHub Actions CI for building and testing SBSCL early on. The individual quality checks could then be added incrementally once we have agreed on their configuration and on how to handle existing findings.

So, please feel free to proceed with a first, focused PR for the basic Maven build/test CI. We can then add the code-quality tools step by step in subsequent PRs.

[baranwalayush]

Thanks for the review. Sure, introducing basic CI first does sound better. Here's the first PR #113 addressing this issue. Feel free to check it out and let me know if everything is fine. Once it is merged, I'll move forward with the next steps.