Default locale detection #496
Description
The default Locale is one of those mostly overlooked things in Java that can cause a lot of bugs. All JVMs have a default Locale that they usually get from the configuration of the host OS. But, it can also be overridden/set in a number of different ways. In addition, it is JVM-wife and can be set from code anywhere. This means that any piece of Java code that runs, an add-on and probably even a user JSR223 user script, can change the default Locale at any time. To sum it up, the default Locale is completely unreliable, and should never be used for any application that have its own localization/formatting settings, like OH.
It works fairly well for simple Java programs with no such setting, because it will often lead to the desired number formatting, language etc. being used. But, even there it causes havoc, because "internal" strings (not user facing) are often meant to remain unchanged/follow English rules, but that isn't the case on non-English computers.
This is hard for developers to control, first and foremost because many aren't aware that it's a common source of problems, but also because so many standard Java methods implicitly use the default Locale. String.format(), String.toUpperCase(), String.toLowerCase(), Calendar.getInstance() are just a few of these. In most situations, overloaded versions where you can specify the Locale exists (although Calendar is quite badly designed in this respect), but they are rarely used because people aren't aware of neither the problem nor their existence.
My view is that every Locale dependent operation should either use Locale.ROOT for non-user facing data, or the configured user Locale for user-facing data. In OH, the configured Locale can be acquired from LocaleProvider. What I would like to see, is that use of the (implicit) default Locale would trigger a warning.
I'm convinced that I have seen warnings about implicit use of default Locale in Eclipse in the past, but I can not find any trace of it when I look for it now, neither in Eclipse itself, nor in any of the commonly used static code analysis tools. Trying to hunt down the use of calls to methods that implicitly use the default Locale manually is an almost hopeless task. The only place this seems to be handled in "modern tools" is in Android studio, but that doesn't help for OH development.
I was hoping that somebody had an idea of how this could be done by this plugin. I've seen mentions of "the possibility of custom rules" both for CheckStyle and PMD, but nothing concrete. I fear that it means that somebody would somehow manually figure out all the "standard Java" methods that implicitly use the default Locale, and then somehow flag them all, but I'm not even sure how to "flag a method" in any of these tools.
TimeZone has a very similar situation, which also leads to many bugs.