Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[java] UnnecessaryBoxing, but explicit conversion is necessary #4903

Open
andygoossens opened this issue Mar 28, 2024 · 5 comments · May be fixed by #5019
Open

[java] UnnecessaryBoxing, but explicit conversion is necessary #4903

andygoossens opened this issue Mar 28, 2024 · 5 comments · May be fixed by #5019
Assignees
Labels
a:false-positive PMD flags a piece of code that is not problematic
Milestone

Comments

@andygoossens
Copy link

Affects PMD Version: 7.0.0

Rule: UnnecessaryBoxing

Description: PMD reports "Unnecessary explicit conversion from Integer to Long" violation, but removing the explicit conversion will break compilation.

Code Sample demonstrating the issue:

@SuppressWarnings({"PMD.SystemPrintln", "PMD.NoPackage"})
public final class UnnecessaryBoxing {

  private UnnecessaryBoxing() {
  }

  public static void addLong(Long parameter) {
    System.out.println("parameter = " + parameter);
  }

  public static Integer getValue() {
    return 42;
  }

  public static void main(String[] args) {
    addLong(Long.valueOf(getValue())); // PMD complains: "Unnecessary explicit conversion from Integer to Long"
    //addLong(getValue()); // Does not compile: "incompatible types: Integer cannot be converted to Long"
  }
}

Expected outcome:

PMD reports a violation at line 16 (see comment), but that's wrong. That's a false positive.

Running PMD through: Gradle

@andygoossens andygoossens added the a:false-positive PMD flags a piece of code that is not problematic label Mar 28, 2024
@oowekyala
Copy link
Member

oowekyala commented Mar 28, 2024

That's because your code is doing the conversion chain Integer ~> int ~> long -> Long, where the first two are implicit. You can "simplify" that by writing getValue().longValue() and not call Long.valueOf. That way you do Integer -> long ~> Long. I haven't tested that this satisfies the rule but I believe it would.

Although the rule is still definitely wrong because the conversion is not unnecessary in this case.

@andygoossens
Copy link
Author

I see. Using addLong(getValue().longValue()); in my example would indeed have satisfied the rule.

@julius-d

This comment was marked as duplicate.

@oowekyala

This comment was marked as resolved.

@julius-d

This comment was marked as resolved.

@oowekyala oowekyala self-assigned this May 14, 2024
@oowekyala oowekyala modified the milestone: 7.2.0 May 14, 2024
@oowekyala oowekyala linked a pull request May 14, 2024 that will close this issue
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a:false-positive PMD flags a piece of code that is not problematic
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants