5

My code uses Apache Commons Lang v.2 (commons-lang). If I update my code to use v.3 (commons-lang3) instead, should I worry that my code might start to behave differently (of course except differences due to fixed bugs and to possible new bugs, which would be normal and don't count) ?

In other words, can lang3 have methods that were also in lang (with the exact same signature) but that might return different results in the two versions?

Apache does mention backwards incompatibilities, and very clearly, but I always understood these incompatibilities in the sense that they break compilation, not in the sense that the very same method can return different results.

I'm asking this because it was claimed to me that some of the backwards incompatibilities that prompted Apache to rename the package from lang to lang3 are methods that may return different results. I believe this is a wrong claim and for me it matters because I always happily replace lang with lang3 in all the imports I stumble upon and I only check that it still compiles, and I really think I'm in the right, but now, due to those claims, I have been told to stop, which I think is wrong, but I have no information that I can use to counter those claims and be allowed to continue.

SantiBailors
  • 1,596
  • 3
  • 21
  • 44
  • If you know what all features you are using, then you can easily test those features, if some bug fixes exist around then test it (this is just an idea). – Alpesh Jikadra Jul 11 '19 at 13:19
  • @AlpeshJikadra I do not know all the features of Commons Lang that this huge code base uses, I want to be able to just update the `import` from `lang` to `lang3` and only recompile. If some behavior changes because of a bug fix or a new bug that's totally OK (and unlikely), so basically what I'm trying to understand is whether the development process of `lang3` was committed to not altering existing behavior. – SantiBailors Jul 11 '19 at 13:25
  • 1
    So best would be a list of encountered differences. You, you could do an inventory of used methods, unit tests, or close source code comparison; all those things are feasible. Also some usages may become obsolete, covered by standard java SE. – Joop Eggen Jul 11 '19 at 13:37
  • @JoopEggen They are feasible but that would take enough time that would make updating to v.3 not worth it. I agree that it would be the safest course of action though. – SantiBailors Jul 11 '19 at 14:36

1 Answers1

10

Did you read their migration guide?

It says that despite the backwards incompatibility tag on v3, most upgrades are as simple as updating imports to use lang3 in place of lang.

There are some classes and methods that were removed, which any IDE and compiler will quickly identify for you.

I think the more dangerous areas are where the behavior and contracts of methods has changed. For example, see this note:

StringUtils.isAlpha, isNumeric and isAlphanumeric now all return false when passed an empty String. Previously they returned true.

If your code is using those methods, you may see different behavior. It's gonna be up to you to see if your code uses them and if so, if you care.

Mike
  • 4,722
  • 1
  • 27
  • 40
  • 1
    I had read that migration guide, but not to the bottom where that note is, my bad. That note is the only thing that matters for my question and it closes the subject beautifully. I was wrong and those claims were right. The removed classes and methods, and anything else that would make compilation fail, were not the changes I was asking about. I was asking exactly about the type of changes in your quote. As an aside, if I look closely at those, I totally regard them as bug fixes (considering an empty string as numeric is a bug to me) but I see how this can be a matter of interpretation. – SantiBailors Jul 11 '19 at 14:29