String.format(Locale.ROOT, ...) wrapper

[cpovirk]

String.format depends on the default locale, leading to problems like #1567. We can fix it by passing Locale.ROOT to each call, but this is kind of ugly, especially for an API that exists in large part to eliminate ugly string-concatenation code.

Where would it go?

• Strings.format: looks like String.format, possibly too much so
• Strings.rootLocaleFormat: for easy static import
• RootLocale.format: gives a place for future such methods. Are there any candidates?

And how worried are we about use of the default locale here? Oddly, I'm not sure I've ever heard anyone crusading against String.format, even though there are crusaders against many other default-locale APIs. Maybe it's just less frequently noticed there, in part because users often just use %s? Plus, the output is probably more often used for debugging than it would be for, e.g., SimpleDateFormat.

[Stephan202]

Interesting topic. I've seen issues with String.format and the default locale several times in production code, most recently today. I think it's a problem worthy of Guava's help.

As you mentioned, this issue is seemingly on few people's radar. Raising awareness would be a good thing to do.

[bernardosulzbach]

I would like this. Not as Strings.format, though. Although different, when skimming over code this can easily get unnoticed.

[cpovirk]

I suppose there's some overlap with the recently added Strings.lenientFormat, though that API is purportedly only for cases in which String.format is unavailable or throwing an exception would obscure another exception.

[cpovirk]

(One thing that I'd overlooked is that there is (probably?) no problem if you use only %s (via). That suggests that I overdid things a little back in cl/83859950 (e.g., in CacheBuilderSpec). That's not really a problem, though.)

[tbroyer]

Fwiw, %s is only safe if the corresponding argument is not Formattable.