why use `string.length() == 0` instead of `string.empty()`

[LeoLeeTech]

API(s)

string.length() == 0

How do you want it to be improved?

Hi guys,

I've noticed that Guava consistently uses string.length() == 0 instead of string.isEmpty(). I'm curious about the reasoning behind this coding style.

After doing some research, I've gathered a few potential reasons:

1. Android Compatibility: Guava needs to maintain support for older Android versions while staying on a Java 8 baseline.
2. Performance: length() == 0 might be a more direct property check in some older environments.
3. No-churn Policy: The team generally discourages "refactoring for style only" to avoid unnecessary code churn.

However, I'm wondering if there are other factors, such as limited time or bandwidth for such updates. If that’s the case, I’d be happy to help with some minor cleanups—not a massive refactor, just small, focused improvements.

Also, I saw this line, I understand that don't need replacing it with !separator.isEmpty()

checkArgument(separator.length() != 0, "xxxxxxx");

I apologize if this has been discussed before (I couldn't find the exact issue). I would love to hear your thoughts on this.

Thanks in advance!

Why do we need it to be improved?

...

Example

...

Current Behavior

...

Desired Behavior

...

Concrete Use Cases

...

Checklist

• I agree to follow the code of conduct.

• I have read and understood the contribution guidelines.

• I have read and understood Guava's philosophy, and I strongly believe that this proposal aligns with it.

[LeoLeeTech]

I'm already created a PR, so close the issue.

[cpovirk]

Thanks. I think the length() checks are probably left over from when we were maintaining compatibility with Java 5(!), or else they're simple oversights. We have some static analysis in place to encourage using isEmpty() instead, but we don't generally go back to fix up existing occurrences unless we have a strong reason, since we could spend forever on such cleanups, as you've guessed.

All that said, this particular cleanup seems like a nice simplification, given how easy it is. So while I often do leave things like this alone, I'll apply the cleanup in #8149. I'll attribute it to you, given the PR you've created as a demo, unless you'd prefer otherwise.

[cpovirk]

Oh, and I forgot to say: You mentioned in #8146 that there are other opportunities to use Java 8 APIs. APIs from Java 8+ are trickier because they're not necessarily universally available under the older versions of Android that we support. (That may change as soon as this year, though!) We do have some automation that we could apply to generate some such changes when the time comes. We'll still have to be careful not to make changes that might perform especially poorly, including under Android, as streams, for example, sometimes can. (And we try not to make changes to guava-jre without corresponding changes to guava-android when practical.) So we'll likely take some steps in that direction eventually. If anything jumps out to you that you want to point out, I'd be happy for ideas, since I don't have it all in my head.

[LeoLeeTech]

Thank you so much, I will look into it.

thx again.