Skip to content

Conversation

@oowekyala
Copy link
Member

@oowekyala oowekyala commented Mar 14, 2025

Describe the PR

To fix this i had to refactor a bit the constant folding logic. It wasn't actually implementing the definition of the JLS for a "compile-time constant". The logic now makes ASTExpression#isCompileTimeConstant() and #getConstValue() respect the JLS definition, that is, the only variables referenced must be compile-time constant fields (ie static final with CT constant initializer, and cannot have blank initializer). However this is very restrictive, while some rules want to know if the value is known at compile time, even if it uses non-static final fields, or final local variables for instance. I extended the logic of the constant folder to track whether the resolved constant value is a CT constant according to the strict definition or to the loose definition.

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)
  • Added (in-code) documentation (if needed)
@github-actions
Copy link

github-actions bot commented Mar 14, 2025

Documentation Preview

Compared to main:
This changeset changes 0 violations,
introduces 31 new violations, 0 new errors and 0 new configuration errors,
removes 11 violations, 0 errors and 0 configuration errors.

Regression Tester Report

@oowekyala oowekyala marked this pull request as ready for review March 15, 2025 14:02
@adangel adangel self-requested a review March 25, 2025 19:26
@adangel adangel changed the title [java] Fix #5590 - LiteralsFirstInComparisons with constant field Fix #5590: [java] LiteralsFirstInComparisons with constant field Mar 25, 2025
@adangel adangel added this to the 7.12.0 milestone Mar 27, 2025
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!


@Override
public boolean isCompileTimeConstant() {
return false;
Copy link
Member

Choose a reason for hiding this comment

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

isCompileTimeConstant can also be removed here and the default from ASTExpression can be used.

Copy link
Member

Choose a reason for hiding this comment

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

Ok, this change broke the (treedump) tests, that expect that NullLiterals are not compile-time constants. See also

public boolean isCompileTimeConstant() {
return true; // note: NullLiteral overrides this to false
}

@oowekyala I would have expected, that all literals are compile time constants. But this doesn't seem to be the case for null? Is this correct? Do you know, why?
If I understand it correctly, compile-time constants can only be created by Constant Expressions which is of a primitive type or String. But null is neither, therefore null is not a compile-time constant...

@adangel adangel merged commit a88575e into pmd:main Mar 27, 2025
12 checks passed
adangel added a commit that referenced this pull request Mar 27, 2025
adangel added a commit that referenced this pull request Mar 27, 2025
Merge pull request #5595 from oowekyala:issue5590-literal-comparison
@oowekyala oowekyala deleted the issue5590-literal-comparison branch March 27, 2025 18:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

2 participants