Findbugs issue with "Boxing/unboxing to parse a primitive" with Integer.valueOf(String)

27,665

Solution 1

The issue is that Integer.valueOf returns an Integer, not an int, but your someOtherMethod expects an int. Findbugs is basically warning you that you're doing it a long-winded way that involves potentially creating an object (the Integer) that you don't need which you're then immediately going to unbox by passing it to someOtherMethod(int), e.g.:

String => int => Integer => int
          ^^^^^^^^^^^^^^
                \--- This is inside Integer.valueOf

Instead, you can and probably should avoid that unnecessary round-trip through Integer and simply do:

String => int
^^^^^^^^^^^^^
      \--- Integer.parseInt

There's just no need for the temporary Integer and the potential memory allocation and such surrounding it.

If someOtherMethod were expecting an Integer, you wouldn't get the warning, because the Integer isn't purely temporary.

This is just one of a class of unnecessary-boxing-conversions that Findbugs and tools like it helpfully point out.

Solution 2

It took me a while to figure that one out (partially because Jenkins just said "Boxing/unboxing to parse a primitive"), but apparently the problem / solution is in what Integer.valueOf() does internally, namely:

Integer.valueOf(parseInt(s, 10));

So the solution is to simply to call parseInt() directly instead:

someOtherMethod(Integer.parseInt(id));

The detailed description of the issue (DM_BOXED_PRIMITIVE_FOR_PARSING) can be found on the findbugs page.

Share:
27,665
mac
Author by

mac

Updated on July 15, 2022

Comments

  • mac
    mac almost 2 years

    I have this piece of code:

    public void someMethod(String id) {
       someOtherMethod(Integer.valueOf(id));
    }
    
    public void someOtherMethod(int id) {
       // do something with id
    }
    

    And on that second line, Findbugs is throwing this exception:

    Boxing/unboxing to parse a primitive

    Why is Findbugs complaining about this when I'm simply calling Integer.valueOf() / how can I fix this?

  • T.J. Crowder
    T.J. Crowder over 8 years
    "but apparently the problem / solution is in what Integer.valueOf() does internally" That's not the problem, no. It does carry the seeds of the solution, but it's not the problem.
  • mac
    mac over 8 years
    Em ... your solution is exactly what I said (first) ... namely to use Integer.parseInt() directly instead of Integer.valueOf() that causes the boxing/unboxing to happen. You just used more words to explain it.
  • T.J. Crowder
    T.J. Crowder over 8 years
    The difference is that I did explain it. The above just says "use parseInt" without an explanation of why Findbugs is pointing out an issue.
  • Tagir Valeev
    Tagir Valeev over 8 years
    FindBugs does point that out: "A boxed primitive is created from a String, just to extract the unboxed primitive value. It is more efficient to just call the static parseXXX method". If you have better idea how to formulate it, pull-requests are welcome.
  • mac
    mac over 8 years
    @T.J.Crowder - This isn't an issue about explaining boxing/unboxing, this is an issue about how to solve that particular problem. I still think you simply took my answer and beefed it up with somewhat unrelevant information (to the question anyway).
  • mac
    mac over 8 years
    @TagirValeev - Hmmm ... you're right, more information can be found if you dig a bit more, but all my Jenkins build pointed out is: [INFO] BugInstance size is 1 [INFO] Error size is 0 [INFO] Total bugs: 1 [INFO] Boxing/unboxing to parse a primitive
  • T.J. Crowder
    T.J. Crowder over 8 years
    @mac: Then you don't know me very well. And I don't think you've really read the answer.
  • mac
    mac over 8 years
    @T.J.Crowder - Yup, you're right, I don't know you at all. ;) And, yes, I did read your answer. Anyhow ...
  • mac
    mac over 8 years
    I have updated my answer with the feedback from @TagirValeev (thanks!). I'm guessing that's more than plenty of info (from the two answers) to know how to resolve the issue when you come across it. In the future, I would suggest TagirValeev's approach: Provide comments to make an answer better ...