Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[java] Shrink reported locations for some rules#6084

Draft
UncleOwen wants to merge 56 commits intopmd:mainfrom
UncleOwen:issue-730-ExcessiveImportsRule-location-of-violation
Draft

[java] Shrink reported locations for some rules#6084
UncleOwen wants to merge 56 commits intopmd:mainfrom
UncleOwen:issue-730-ExcessiveImportsRule-location-of-violation

Conversation

@UncleOwen
Copy link
Member

Describe the PR

This PR shrinks the reported locations for some rules. There is more to do on this front, but I'd like to get this part merged.

Related issues

Ready?

  • Added unit tests for fixed bug/feature
  • Passing all unit tests
  • Complete build ./mvnw clean verify passes (checked automatically by github actions)

@pmd-actions-helper
Copy link
Contributor

pmd-actions-helper bot commented Sep 21, 2025

Documentation Preview

Compared to main:
This changeset changes 45390 violations,
introduces 684 new violations, 0 new errors and 0 new configuration errors,
removes 846 violations, 0 errors and 0 configuration errors.

Regression Tester Report

(comment created at 2026-01-22 18:35:15+00:00 for d15e3b0)

Copy link
Member

@adangel adangel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR!

Before merging this, I'd like to clarify, that we really report on useful lines (e.g. report on the class identifier instead of on the class keyword).

After this PR, I'd suggest the following approach:

  1. create a list of all rules
  2. Cross out the rules, for which you created a test in this PR already
  3. select one single rule
  4. create a test case "Verify location of violation" with the expected report location. Keep in mind, that the end-line seems to where github actions would show the annotation (see #3769)
  5. fix this rule
  6. repeat with 2 until no rules are left
  7. extend documentation "how to write/test a rule" to describe, that not only a positive and negative test case is required, but also a verification of the report location test.
    Because now, we fixed "some rules" but we don't know which exactly, and when we have actually done #3769. This makes it hard to monitor progress on this front.

Additionally, we might need to think about extending the regression tester. I think, we currently only compare the beginLine, but maybe we should compare the complete report location for each violation. But maybe this is not needed, if we have for every rule such a test case. Maybe that's sufficient.

@adangel adangel added this to the 7.19.0 milestone Oct 27, 2025
@adangel adangel self-assigned this Nov 27, 2025
@adangel adangel modified the milestones: 7.19.0, 7.20.0 Nov 27, 2025
int threshold = getProperty(reportLevel);
if (metric >= threshold) {
asCtx(data).addViolation(node, metric, threshold);
asCtx(data).addViolationWithPosition(t, t.getAstInfo(), getReportLocation(t), getMessage(), metric, threshold);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a slight conflict with #6260 because this overload of addViolationWithPosition is removed in that PR. If that PR is merged before this one, the correct incantation would be

Suggested change
asCtx(data).addViolationWithPosition(t, t.getAstInfo(), getReportLocation(t), getMessage(), metric, threshold);
asCtx(data).at(t.atLocation(getReportLocation(t))).warnWithArgs(metric, threshold);

@adangel adangel modified the milestones: 7.20.0, 7.21.0 Dec 28, 2025
@adangel adangel marked this pull request as draft January 7, 2026 13:42
@adangel
Copy link
Member

adangel commented Jan 7, 2026

Note: I'm going to rebase this a couple of times...

@adangel adangel force-pushed the issue-730-ExcessiveImportsRule-location-of-violation branch from bf4235c to 0e585ff Compare January 7, 2026 15:18
@adangel
Copy link
Member

adangel commented Jan 7, 2026

Status update (see also #730): The two rules AbstractClassWithoutAbstractMethod and NonExhaustiveSwitch of category "Best Practices" are done now.

@adangel adangel force-pushed the issue-730-ExcessiveImportsRule-location-of-violation branch from 56b87d5 to 78f0bb7 Compare January 16, 2026 12:52
@adangel
Copy link
Member

adangel commented Jan 16, 2026

When looking at the regression report, the following additional rules have been changed:

  • AtLeastOneConstructor
  • ClassWithOnlyPrivateConstructorShouldBeFinal
  • CommentDefaultAccessModifier
  • CommentRequired
  • ShortClassName
  • TestClassWithoutTestCases
  • UnnecessaryModifier
  • UseUtilityClass

Once the new report is available, maybe less rules are affected by this change. But if there are more rules affected (because e.g. we changed all rules that report on ClassDeclaration), we should already handle them here in this PR.

I'm also inclined to actually implement pmd/pmd-regression-tester#148 before merging this change, just to be sure, the new report location makes sense and we don't inadvertently change other rules as well.

So, this is maybe not ready even for 7.21.0.

@adangel adangel force-pushed the issue-730-ExcessiveImportsRule-location-of-violation branch from 78f0bb7 to b26811f Compare January 16, 2026 16:55
@adangel
Copy link
Member

adangel commented Jan 22, 2026

I've update it now and added test cases for other affected rules (AbstractClassWithoutAnyMethod, AvoidDollarSigns, ClassNamingConventions, CyclomaticComplexity, DataClass, ExhaustiveSwitchHasDefault, GodClass, ImplicitFunctionalInterface, JUnit5TestShouldBePackagePrivate, MissingSerialVersionUID, MissingStaticMethodInNonInstantiatableClass, SwitchDensity, TooFewBranchesForSwitch, NcssCount, SingleMethodSingleton, LocalHomeNamingConvention, LocalInterfaceSessionNamingConvention). They all report on the identifier of class/interfaces now or on the switch keyword.

I fixed CouplingBetweenObjects to correctly recognize nested classes. Hopefully the results make more sense now (lets wait for regression tester result).

Two rules are affected, but I didn't include them, as they would not be finished completely:

  • ControlStatementBraces -> reported on synchronized statement in braceless if. Now, only reports on the synchronized keyword rather than on the whole block. But in general, we still might report multiple lines, if the first statement of a braceless if takes multiple lines. This rule should be tackled in a different PR (along with rethinking the decision to report on the first statement of a braceless if and not on the braceless if statement directly)
  • FinalizeDoesNotCallSuperFinalize -> when reported on synchronized statement, now reporting only on synchronized keyword.

In total, we have now updated 13% of our Java rules (37 of 289 rules).

Next steps:

@adangel adangel modified the milestones: 7.21.0, 7.22.0 Jan 29, 2026
@adangel adangel modified the milestones: 7.22.0, 7.23.0 Feb 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants