title: The Sonar way to define a constant
body: <p>I use Sonarqube 5.1 and experiment with the “Sonar way” Java quality profile. The job is simple: I want to define a <em>global</em> String constant for a missing media type:</p>
  
  <pre><code>public interface Utf8MediaType {
      String APPLICATION_JSON = "application/json;charset=UTF-8";
  }
  </code></pre>
  
  <p>However, Sonarqube tells me this is bad practice in rule <em>squid:S1214 – Constants should not be defined in interfaces</em>. The long text talks about implementing this interface, which I didn’t intend to, but I give in and create a class instead:</p>
  
  <pre><code>public class Utf8MediaType {
      public static final String APPLICATION_JSON = "application/json;charset=UTF-8";
  }
  </code></pre>
  
  <p>However, this is considered to be a major design issue in rule <em>squid:S1118 – Utility classes should not have public constructors</em>. So it’s urging me to add a private constructor. Of course, this constructor has then to come first not to violate conventions in rule <em>squid:S1213 – The members of an interface declaration or class should appear in a pre-defined order</em>. I guess after that I might even get <em>common-java:InsufficientBranchCoverage</em> because the private constructor is not covered in tests.</p>
  
  <hr>
  
  <p>These are the default rules and I feel they are a bit silly in combination. I have more examples where the defaults just don’t work for us (TestNG support is lacking).
  What can I do about it? What do you recommend?</p>
  
  <ul>
  <li>Give in. Make it a class, add a private constructor, use introspection in the unit test. Makes the code ten times as big. For a String constant.</li>
  <li>Create a list of exceptions. But doing this for each project may lead to long lists and invites people to add exceptions even for important stuff.</li>
  <li>Deactivate rules. Now I would prefer <em>not</em> to tamper with the default profiles, because that may mean a lot of work on Sonarqube upgrades.</li>
  <li>Create a profile that inherits from the default and overwrites things. It turns out that when you inherit from a profile you cannot <em>deactivate</em> rules. You can only add additional rules and change the configuration of rules (to lower their severity).</li>
  </ul>