Rule description & motivation
JDK 7 introduced the class java.nio.charset.StandardCharsets. It provides constants for all charsets that the Java language spec mandates for all JVMs:
- ISO_8859_1
- US_ASCII
- UTF_16
- UTF_16BE
- UTF_16LE
- UTF_8
Many methods in the JDK which deal with charsets are overloaded to accept either a String charsetName or a Charset. Before the advent of StandardCharsets, developers used one of the following approaches, each with their own drawbacks:
- pass a string like
UTF-8- drawback: have to catch/throw an
UnsupportedEncodingExceptionthat will actually never happen unless the JVM violates the language spec
- drawback: have to catch/throw an
- use Guava’s
Charsetsclass- drawback: obsolete as of JDK 7, see StringsExplained · google/guava Wiki
I think that SonarJava running for a JDK 7 or above code base should detect when any of the aliases of the six standard charsets are used for JDK methods that would equally accept Charset instances, and when any of Guava’s Charsets constants are used. The rule should tell developers to replace the reference with the corresponding StandardCharsets constant.
Impact to keep this code as it is
Using names to refer to standard charsets adds useless boilerplate code for an impossible UnsupportedEncodingException. Using Guava’s Charsets class instead of StandardCharsets needlessly introduces/reinforces a library dependency.
Notes
This rule would be similar to S1943 (“Classes and methods that rely on the default system encoding should not be used”) in that it checks for a whole lot of methods.
Noncompliant Code
someString.getBytes("UTF-8");
someString.getBytes(Charsets.UTF_8);
Compliant Code
someString.getBytes(StandardCharsets.UTF_8);
References
Type
Code Smell
Tags
clumsy