Diagnoses and fixes Java style violations in the FE module using Checkstyle, a tool that checks coding rules. It interprets errors, applies the project's formatting and import restrictions, and reruns checks to verify fixes.
Fix FE (Java) code style issues using Checkstyle
Review the instructions the agent will receive before you install.
Diagnose and fix Java code style issues in the FE module using the project's Checkstyle configuration.
Checkstyle is integrated into the Maven build and runs automatically during mvn validate. To check style only (without full compilation):
cd fe && mvn checkstyle:check -pl fe-core
Or as part of the normal build:
./build.sh --fe -j${DORIS_PARALLELISM}
If checkstyle fails, the build will fail with error messages showing the file, line number, and rule violated.
Checkstyle output looks like:
[ERROR] src/main/java/.../Foo.java:[42:5] (imports) UnusedImports: Unused import - java.util.List.
[ERROR] src/main/java/.../Bar.java:[10] (header) RegexpHeader: Line does not match expected header line...
Each error shows: [file]:[line:col] (category) RuleName: description.
| Violation | Fix |
|---|---|
RegexpHeader | Add/fix Apache License header at file top |
UnusedImports | Remove unused import statements |
LineLength (>120 chars) | Break long lines |
IllegalImport (shaded classes) | Use the non-shaded equivalent (see import-control.xml) |
FileTabCharacter | Replace tabs with spaces |
NewlineAtEndOfFile | Ensure file ends with a newline |
MergeConflictMarker | Resolve git merge conflicts |
After fixing, re-run checkstyle to confirm:
cd fe && mvn checkstyle:check -pl fe-core
| File | Purpose |
|---|---|
fe/check/checkstyle/checkstyle.xml | Main rules (license header, line length 120, encoding, imports) |
fe/check/checkstyle/suppressions.xml | Rule exclusions (test files, nereids, large files) |
fe/check/checkstyle/import-control.xml | Import restrictions (no shaded classes, no old logging APIs, no Lombok in nereids) |
fe/check/checkstyle/checkstyle-apache-header.txt | Apache License 2.0 header template |
build-support/IntelliJ-code-format.xml | IntelliJ formatter scheme (120 col, import organization) |
Some files/packages have relaxed rules (see suppressions.xml):
The following are excluded from checkstyle (see fe/pom.xml):
**/apache/doris/thrift/**/* (generated Thrift code)**/apache/parquet/**/* (generated Parquet code)org.apache.doris.thirdparty.* directlyorg.apache.commons.logging or java.util.loggingjava.time APIs insteadlombok is disallowed in org.apache.doris.nereids package| Problem | Solution |
|---|---|
Build fails on validate phase | Run mvn checkstyle:check -pl fe-core to see specific violations |
| Can't find checkstyle config | Ensure you're running from the fe/ directory |
| IntelliJ formatting differs | Import build-support/IntelliJ-code-format.xml via Settings → Editor → Code Style |
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Format C++ code in the BE and Cloud modules using the project's clang-format v16 rules. Use the provided scripts to fix formatting or check for violations without changing files, then review the resulting differences before committing.
Run clang-tidy static analysis, which checks code without executing it, on added or modified BE and Cloud C++ files. Focus diagnostics on changed lines, investigate bug, performance, and readability warnings, and verify fixes with another check.
Review Doris code changes using project-specific checklists for data correctness, concurrency, memory safety, compatibility, performance, and tests. Trace related code paths and explain findings with concrete failure scenarios, using query plan trees when reviewing optimizer behavior.
Prepare a clean Doris package and run Docker regression tests, which check whether changes break existing behavior. Restore configuration and startup files from Git, build the test image, and investigate failures using configuration checks and runtime logs.