use StandardCharsets instead of Charset.forName()

[ivangalkin]

• class StandardCharsets provides constants, which help to avoid typos
  (compile-time check vs run-time check) and reduce number
  of lookups

---

This change is 

[guwirth]

@ivangalkin thx looks good. Only thing I'm wondering is if there is no SQ constant/method to ask for the default?

[ivangalkin]

@guwirth SonarQube requires UTF-8 for the database (on the server side). Grep for UTF8 on https://docs.sonarqube.org/display/SONARqube71/Requirements#Requirements-SupportedPlatforms for more details. Although I believe, that we are pretty safe with UTF-8 as default, there is indeed the standard SonarQube way to determine the project's charset (on the client side):

See org.sonar.api.batch.fs.FileSystem.encoding(). It reads the data from the property sonar.sourceEncoding.

We use it in order to create the CxxConfiguration. Afterwards all visitors, which must respect the encoding (see CxxCharsetAwareVisitor) receive the mentioned encoding through the method CxxCharsetAwareVisitor::setCharset(Charset charset). UTF-8 is just used as a reasonable default for these visitors.

There are still visitors, which still ignore the FileSystem.encoding() and use UTF-8:

• MissingNewLineAtEndOfFileCheck
• FileRegularExpressionCheck (there might be some order issues between setCharset() and init(), must be doube-checked or refactored)

Also all our importing sensors ignore the FileSystem.encoding(). For some 3rd party reports we allow to specify the file charset (ClangTidy, VC, GCC, please grep for REPORT_CHARSET_DEF). Some of them just hardcode the UTF-8 (e.g. CxxDrMemorySensor). The remaining ones use the default (system) charset for parsing I assume. Not sure if and how should we make it uniform.

[guwirth]

@ivangalkin thanks for investigation. Think sonar.sourceEncoding is only for source header files. Think in newer version SQ is also able to handle BOMs? On the other hand reports can have a different encoding (could be from a different machine with a different encoding). So it makes sense to be able to overwrite the default for each sensor individual.

Think we should merge this one. It's for sure an improvement and create a new issue for encoding clean-up.