diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml index 18d86b54..79c63403 100644 --- a/.github/workflows/build.yml +++ b/.github/workflows/build.yml @@ -123,7 +123,7 @@ jobs: uses: ./.github/actions/sonar-update-center with: prop-file: findbugs.properties - description: Use SpotBugs 4.7.3, sb-contrib 7.6.0, and findsecbugs 1.12.0 + description: Use SpotBugs 4.8.1, sb-contrib 7.6.0, and findsecbugs 1.12.0 minimal-supported-sq-version: 8.9 latest-supported-sq-version: LATEST changelog-url: https://github.com/spotbugs/sonar-findbugs/releases/tag/${{ github.event.release.tag_name }} diff --git a/README.md b/README.md index 393ae73b..a1a68b39 100644 --- a/README.md +++ b/README.md @@ -69,4 +69,4 @@ Findbugs Plugin version|Embedded SpotBugs/Findbugs version|Embedded Findsecbugs 4.2.2 | 4.7.3 (SpotBugs) | 1.12.0 | 7.4.7 (sb-contrib) | 1.8|7.9~|5.10.1.16922 4.2.3 | 4.7.3 (SpotBugs) | 1.12.0 | 7.4.7 (sb-contrib) | 1.8|7.9~|5.10.1.16922 4.2.4 | 4.7.3 (SpotBugs) | 1.12.0 | 7.6.0 (sb-contrib) | 1.8|7.9~|5.10.1.16922 -4.2.5-SNAPSHOT | 4.7.3 (SpotBugs) | 1.12.0 | 7.6.0 (sb-contrib) | 1.8|7.9~|5.10.1.16922 +4.2.5-SNAPSHOT | 4.8.1 (SpotBugs) | 1.12.0 | 7.6.0 (sb-contrib) | 1.8|7.9~|5.10.1.16922 diff --git a/generate_profiles/BuildXmlFiles.groovy b/generate_profiles/BuildXmlFiles.groovy index 93396113..287bd7b5 100644 --- a/generate_profiles/BuildXmlFiles.groovy +++ b/generate_profiles/BuildXmlFiles.groovy @@ -8,13 +8,13 @@ import groovy.json.JsonSlurper; @Grapes([ - @Grab(group='com.github.spotbugs', module='spotbugs', version='4.7.3'), + @Grab(group='com.github.spotbugs', module='spotbugs', version='4.8.1'), @Grab(group='com.mebigfatguy.sb-contrib', module='sb-contrib', version='7.6.0'), @Grab(group='com.h3xstream.findsecbugs' , module='findsecbugs-plugin', version='1.12.0')] ) -FB = new Plugin(groupId: 'com.github.spotbugs', artifactId: 'spotbugs', version: '4.7.3') +FB = new Plugin(groupId: 'com.github.spotbugs', artifactId: 'spotbugs', version: '4.8.1') CONTRIB = new Plugin(groupId: 'com.mebigfatguy.sb-contrib', artifactId: 'sb-contrib', version: '7.6.0') FSB = new Plugin(groupId: 'com.h3xstream.findsecbugs', artifactId: 'findsecbugs-plugin', version: '1.12.0') diff --git a/src/main/java/org/sonar/plugins/findbugs/rules/FindbugsRulesDefinition.java b/src/main/java/org/sonar/plugins/findbugs/rules/FindbugsRulesDefinition.java index 0c239ac8..fe2905bc 100644 --- a/src/main/java/org/sonar/plugins/findbugs/rules/FindbugsRulesDefinition.java +++ b/src/main/java/org/sonar/plugins/findbugs/rules/FindbugsRulesDefinition.java @@ -28,8 +28,8 @@ public final class FindbugsRulesDefinition implements RulesDefinition { public static final String REPOSITORY_KEY = "findbugs"; public static final String REPOSITORY_NAME = "FindBugs"; - public static final int RULE_COUNT = 461; - public static final int DEACTIVED_RULE_COUNT = 6; + public static final int RULE_COUNT = 475; + public static final int DEACTIVED_RULE_COUNT = 7; @Override public void define(Context context) { diff --git a/src/main/resources/org/sonar/plugins/findbugs/profile-findbugs-and-fb-contrib.xml b/src/main/resources/org/sonar/plugins/findbugs/profile-findbugs-and-fb-contrib.xml index ca6818a7..bf8a51a8 100644 --- a/src/main/resources/org/sonar/plugins/findbugs/profile-findbugs-and-fb-contrib.xml +++ b/src/main/resources/org/sonar/plugins/findbugs/profile-findbugs-and-fb-contrib.xml @@ -1,4 +1,7 @@ + + + @@ -431,6 +434,9 @@ + + + @@ -557,6 +563,9 @@ + + + @@ -1382,6 +1391,39 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/src/main/resources/org/sonar/plugins/findbugs/profile-findbugs-only.xml b/src/main/resources/org/sonar/plugins/findbugs/profile-findbugs-only.xml index 19f51f7d..e7fc4160 100644 --- a/src/main/resources/org/sonar/plugins/findbugs/profile-findbugs-only.xml +++ b/src/main/resources/org/sonar/plugins/findbugs/profile-findbugs-only.xml @@ -1,4 +1,7 @@ + + + @@ -431,6 +434,9 @@ + + + @@ -557,6 +563,9 @@ + + + @@ -1382,4 +1391,37 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/src/main/resources/org/sonar/plugins/findbugs/rules-findbugs.xml b/src/main/resources/org/sonar/plugins/findbugs/rules-findbugs.xml index 08a3d409..b4a306a5 100644 --- a/src/main/resources/org/sonar/plugins/findbugs/rules-findbugs.xml +++ b/src/main/resources/org/sonar/plugins/findbugs/rules-findbugs.xml @@ -1,4 +1,16 @@ + + Bad practice - Be wary of letting constructors throw exceptions. + CT_CONSTRUCTOR_THROW + <p>Classes that throw exceptions in their constructors are vulnerable to Finalizer attacks</p> + + <p>A finalizer attack can be prevented, by declaring the class final, using an empty finalizer declared as final, or by a clever use of a private constructor.</p> + + <p>See <a href="https://wiki.sei.cmu.edu/confluence/display/java/OBJ11-J.+Be+wary+of+letting+constructors+throw+exceptions"><code>SEI CERT Rule OBJ-11</code></a> + for more information. + </p> + bad-practice + Bad practice - Asserting value of instanceof in tests is not recommended. JUA_DONT_ASSERT_INSTANCEOF_IN_TESTS @@ -1344,9 +1356,9 @@ Thus, having a mutable instance field generally creates race conditions.bug - Malicious code - Public static method may expose internal representation by returning array + Malicious code - Public static method may expose internal representation by returning a mutable object or array MS_EXPOSE_REP - <p> A public static method returns a reference to + <p> A public static method returns a reference to a mutable object or an array that is part of the static state of the class. Any code that calls this method can freely modify the underlying array. @@ -1624,9 +1636,9 @@ For example, in the following code, <code>foo</code> will be null.&l bad-practice - Multi-threading - Synchronization on interned String + Multi-threading - Synchronization on String literal DL_SYNCHRONIZATION_ON_SHARED_CONSTANT - <p> The code synchronizes on interned String.</p> + <p> The code synchronizes on String literal.</p> <pre><code>private static String LOCK = "LOCK"; ... synchronized(LOCK) { @@ -1638,7 +1650,26 @@ synchronized(LOCK) { is locking on something that other code might also be locking. This could result in very strange and hard to diagnose blocking and deadlock behavior. See <a href="http://www.javalobby.org/java/forums/t96352.html">http://www.javalobby.org/java/forums/t96352.html</a> and <a href="http://jira.codehaus.org/browse/JETTY-352">http://jira.codehaus.org/browse/JETTY-352</a>. </p> -<p>See CERT <a href="https://www.securecoding.cert.org/confluence/display/java/CON08-J.+Do+not+synchronize+on+objects+that+may+be+reused">CON08-J. Do not synchronize on objects that may be reused</a> for more information.</p> +<p>See CERT <a href="https://wiki.sei.cmu.edu/confluence/display/java/LCK01-J.+Do+not+synchronize+on+objects+that+may+be+reused">LCK01-J. Do not synchronize on objects that may be reused</a> for more information.</p> + multi-threading + bug + + + Multi-threading - Synchronization on interned String + DL_SYNCHRONIZATION_ON_INTERNED_STRING + <p> The code synchronizes on interned String.</p> +<pre><code>private static String LOCK = new String("LOCK").intern(); +... +synchronized(LOCK) { + ... +} +... +</code></pre> +<p>Constant Strings are interned and shared across all other classes loaded by the JVM. Thus, this code +is locking on something that other code might also be locking. This could result in very strange and hard to diagnose +blocking and deadlock behavior. See <a href="http://www.javalobby.org/java/forums/t96352.html">http://www.javalobby.org/java/forums/t96352.html</a> and <a href="http://jira.codehaus.org/browse/JETTY-352">http://jira.codehaus.org/browse/JETTY-352</a>. +</p> +<p>See CERT <a href="https://wiki.sei.cmu.edu/confluence/display/java/LCK01-J.+Do+not+synchronize+on+objects+that+may+be+reused">LCK01-J. Do not synchronize on objects that may be reused</a> for more information.</p> multi-threading bug @@ -1658,7 +1689,7 @@ synchronized(inited) { </code></pre> <p>Since there normally exist only two Boolean objects, this code could be synchronizing on the same object as other, unrelated code, leading to unresponsiveness and possible deadlock.</p> -<p>See CERT <a href="https://www.securecoding.cert.org/confluence/display/java/CON08-J.+Do+not+synchronize+on+objects+that+may+be+reused">CON08-J. Do not synchronize on objects that may be reused</a> for more information.</p> +<p>See CERT <a href="https://wiki.sei.cmu.edu/confluence/display/java/LCK01-J.+Do+not+synchronize+on+objects+that+may+be+reused">LCK01-J. Do not synchronize on objects that may be reused</a> for more information.</p> multi-threading bug @@ -1700,7 +1731,7 @@ synchronized(count) { <p>Since Integer objects can be cached and shared, this code could be synchronizing on the same object as other, unrelated code, leading to unresponsiveness and possible deadlock.</p> -<p>See CERT <a href="https://www.securecoding.cert.org/confluence/display/java/CON08-J.+Do+not+synchronize+on+objects+that+may+be+reused">CON08-J. Do not synchronize on objects that may be reused</a> for more information.</p> +<p>See CERT <a href="https://wiki.sei.cmu.edu/confluence/display/java/LCK01-J.+Do+not+synchronize+on+objects+that+may+be+reused">LCK01-J. Do not synchronize on objects that may be reused</a> for more information.</p> multi-threading bug @@ -1807,7 +1838,7 @@ defined in an interface references a mutable Malicious code - Field isn't final but should be refactored to be so MS_SHOULD_BE_REFACTORED_TO_BE_FINAL <p> -This static field public but not final, and +This <code>public static</code> or <code>protected static</code> field is not final, and could be changed by malicious code or by accident from another package. The field could be made final to avoid @@ -1820,7 +1851,7 @@ to the field, so doing so will require some refactoring. Malicious code - Field isn't final but should be MS_SHOULD_BE_FINAL <p> -This static field public but not final, and +This <code>public static</code> or <code>protected static</code> field is not final, and could be changed by malicious code or by accident from another package. The field could be made final to avoid @@ -1959,10 +1990,11 @@ Methods should be verbs, in mixed case with the first letter lowercase, with the bad-practice - Bad practice - Field names should start with a lower case letter + Bad practice - Non-final field names should start with a lower case letter, final fields should be uppercase with words separated by underscores NM_FIELD_NAMING_CONVENTION <p> Names of fields that are not final should be in mixed case with a lowercase first letter and the first letters of subsequent words capitalized. +Names of final fields should be all uppercase with words separated by underscores ('_'). </p> bad-practice @@ -2160,6 +2192,14 @@ it may indicate a misunderstanding of how serialization works. SE_TRANSIENT_FIELD_NOT_RESTORED <p> This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class. +</p> + bad-practice + + + Bad practice - Prevent overwriting of externalizable objects + SE_PREVENT_EXT_OBJ_OVERWRITE + <p>The <code>readExternal()</code> method must be declared as public and is not protected from malicious callers, so the code permits any caller to reset the value of the object at any time.</p> + <p>To prevent overwriting of externalizable objects, you can use a Boolean flag that is set after the instance fields have been populated. You can also protect against race conditions by synchronizing on a private lock object. </p> bad-practice @@ -3146,7 +3186,13 @@ with the equals() method. It is possible to create distinct instances that are equal but do not compare as == since they are different objects. Examples of classes which should generally -not be compared by reference are java.lang.Integer, java.lang.Float, etc.</p> +not be compared by reference are java.lang.Integer, java.lang.Float, etc. RC_REF_COMPARISON covers +only wrapper types for primitives. Suspicious types list can be extended by adding frc.suspicious +system property with comma-separated classes:</p> +<pre><code>&lt;systemPropertyVariables&gt; + &lt;frc.suspicious&gt;java.time.LocalDate,java.util.List&lt;/frc.suspicious&gt; + &lt;/systemPropertyVariables&gt; +</code></pre> correctness bug @@ -5708,4 +5754,215 @@ Using floating-point variables should not be used as loop counters, as they are </p> malicious-code + + Security - Expression in assertion may produce a side effect + ASE_ASSERTION_WITH_SIDE_EFFECT + <p>Expressions used in assertions must not produce side effects.</p> + + <p>See <https://wiki.sei.cmu.edu/confluence/display/java/EXP06-J.+Expressions+used+in+assertions+must+not+produce+side+effects><code>SEI CERT Rule EXP06</code></a> + for more information. + </p> + security + + + Security - Method invoked in assertion may produce a side effect + ASE_ASSERTION_WITH_SIDE_EFFECT_METHOD + <p>Expressions used in assertions must not produce side effects.</p> + + <p>See <https://wiki.sei.cmu.edu/confluence/display/java/EXP06-J.+Expressions+used+in+assertions+must+not+produce+side+effects><code>SEI CERT Rule EXP06</code></a> + for more information. + </p> + security + + + Bad practice - Primitive field is public + PA_PUBLIC_PRIMITIVE_ATTRIBUTE + <p> + <a href="https://wiki.sei.cmu.edu/confluence/display/java/OBJ01-J.+Limit+accessibility+of+fields">SEI CERT rule OBJ01-J</a> requires that accessibility to fields must be limited. + Otherwise, the values of the fields may be manipulated from outside the class, which may be unexpected or + undesired behaviour. + In general, requiring that no fields are allowed to be public is overkill and unrealistic. Even + the rule mentions that final fields may be public. Besides final fields, there may be other + usages for public fields: some public fields may serve as "flags" that affect the behavior of + the class. Such flag fields are expected to be read by the current instance (or the current + class, in case of static fields), but written by others. If a field is both written by the + methods of the current instance (or the current class, in case of static fields) and from the + outside, the code is suspicious. Consider making these fields private and provide appropriate + setters, if necessary. Please note that constructors, initializers and finalizers are + exceptions, if only they write the field inside the class, the field is not considered as + written by the class itself.</p> + bad-practice + + + Bad practice - Array-type field is public + PA_PUBLIC_ARRAY_ATTRIBUTE + <p> + <a href="https://wiki.sei.cmu.edu/confluence/display/java/OBJ01-J.+Limit+accessibility+of+fields">SEI CERT rule OBJ01-J</a> requires that accessibility of fields must be limited. + Making an array-type field final does not prevent other classes from modifying the contents of + the array. However, in general, requiring that no fields are allowed to be public is overkill + and unrealistic. There may be usages for public fields: some public fields may serve as "flags" + that affect the behavior of the class. Such flag fields are expected to be read by the current + instance (or the current class, in case of static fields), but written by others. If a field is + both written by the methods of the current instance (or the current class, in case of static + fields) and from the outside, the code is suspicious. Consider making these fields private and + provide appropriate setters, if necessary. Please note that constructors, initializers and + finalizers are exceptions, if only they write the field inside the class, the field is not + considered as written by the class itself.</p> + bad-practice + + + Bad practice - Mutable object-type field is public + PA_PUBLIC_MUTABLE_OBJECT_ATTRIBUTE + <p> + <a href="https://wiki.sei.cmu.edu/confluence/display/java/OBJ01-J.+Limit+accessibility+of+fields">SEI CERT rule OBJ01-J</a> requires that accessibility of fields must be limited. + Making a mutable object-type field final does not prevent other classes from modifying the + contents of the object. However, in general, requiring that no fields are allowed to be public + is overkill and unrealistic. There may be usages for public fields: some public fields may + serve as "flags" that affect the behavior of the class. Such flag fields are expected to be + read by the current instance (or the current class, in case of static fields), but written by + others. If a field is both written by the methods of the current instance (or the current + class, in case of static fields) and from the outside, the code is suspicious. Consider making + these fields private and provide appropriate setters, if necessary. Please note that + constructors, initializers and finalizers are exceptions, if only they write the field inside + the class, the field is not considered as written by the class itself. In case of object-type + fields "writing" means calling methods whose name suggest modification.</p> + bad-practice + + + Malicious code - Non-Private and non-final security check methods are vulnerable + VSC_VULNERABLE_SECURITY_CHECK_METHODS + <p> + Methods that perform security checks should be prevented from being overridden, so they must be declared as + private or final. Otherwise, these methods can be compromised when a malicious subclass overrides them + and omits the checks. + <p> + See SEI CERT rule <a href="https://wiki.sei.cmu.edu/confluence/display/java/MET03-J.+Methods+that+perform+a+security+check+must+be+declared+private+or+final">MET03-J. Methods that perform a security check must be declared private or final</a>. + </p> + malicious-code + + + Bad practice - Assertion is used to validate an argument of a public method + AA_ASSERTION_OF_ARGUMENTS + <p>Asssertions must not be used to validate arguments of public methods because the validations are + not performed if assertions are disabled.</p> + + <p> + See SEI CERT rule <a href="https://wiki.sei.cmu.edu/confluence/display/java/MET01-J.+Never+use+assertions+to+validate+method+arguments">MET01-J. Never use assertions to validate method arguments</a> + for more information. + </p> + bad-practice + + + Bad practice - Do not reuse public identifiers from JSL as class name + PI_DO_NOT_REUSE_PUBLIC_IDENTIFIERS_CLASS_NAMES + <p> + It's essential to avoid reusing public identifiers from the Java Standard Library as class names. + This is because the Java Standard Library is a part of the Java platform and is expected to be available in all Java environments. + Doing so can lead to naming conflicts and confusion, making it harder to understand and maintain the code. + It's best practice to choose unique and descriptive class names that accurately represent the purpose and functionality of your own code. + To provide an example, let's say you want to create a class for handling dates in your application. Instead of using a common name like "Date", + which conflicts with the existing java.util.Date class, you could choose a more specific and unique name like or "AppDate" or "DisplayDate". + + A few key points to keep in mind when choosing names as identifier: + <ul> + <li>Use meaningful prefixes or namespaces: Prepend a project-specific prefix or namespace to your class names to make them distinct. For example, if your project is named "MyApp", you could use "MyAppDate" as your class name.</li> + <li>Use descriptive names: Opt for descriptive class names that clearly indicate their purpose and functionality. This helps avoid shadowing existing Java Standard Library identifiers. For instance, instead of "List", consider using "CustomAppList".</li> + <li>Follow naming conventions: Adhere to Java's naming conventions, such as using camel case (e.g., MyClass) for class names. This promotes code readability and reduces the chances of conflicts.</li> + </ul> + + </p> + <p>See SEI CERT rule <a href="https://wiki.sei.cmu.edu/confluence/display/java/DCL01-J.+Do+not+reuse+public+identifiers+from+the+Java+Standard+Library">DCL01-J. Do not reuse public identifiers from the Java Standard Library</a>.</p> + bad-practice + + + Bad practice - Do not reuse public identifiers from JSL as field name + PI_DO_NOT_REUSE_PUBLIC_IDENTIFIERS_FIELD_NAMES + <p> + It is a good practice to avoid reusing public identifiers from the Java Standard Library as field names in your code. + Doing so can lead to confusion and potential conflicts, making it harder to understand and maintain your codebase. + Instead, it is recommended to choose unique and descriptive names for your fields that accurately represent their purpose and differentiate them from Standard Library identifiers. + + To provide an example, let's say you want to create a class for handling dates in your application. Instead of using a common name like "Date", + which conflicts with the existing java.util.Date class, you could choose a more specific and unique name like or "AppDate" or "DisplayDate". + + For example, let's say you're creating a class to represent a car in your application. Instead of using a common name like "Component" as a field, + which conflicts with the existing java.awt.Component class, you should opt for a more specific and distinct name, such as "VehiclePart" or "CarComponent". + + A few key points to keep in mind when choosing names as identifier: + <ul> + <li>Use descriptive names: Opt for descriptive field names that clearly indicate their purpose and functionality. This helps avoid shadowing existing Java Standard Library identifiers. For instance, instead of "list", consider using "myFancyList"</li> + <li>Follow naming conventions: Adhere to Java's naming conventions, such as using mixed case for field names. Start with a lowercase first letter and the internal words should start with capital letters (e.g., myFieldUsesMixedCase). This promotes code readability and reduces the chances of conflicts.</li> + </ul> + + </p> + <p>See SEI CERT rule <a href="https://wiki.sei.cmu.edu/confluence/display/java/DCL01-J.+Do+not+reuse+public+identifiers+from+the+Java+Standard+Library">DCL01-J. Do not reuse public identifiers from the Java Standard Library</a>.</p> + bad-practice + + + Bad practice - Do not reuse public identifiers from JSL as method name + PI_DO_NOT_REUSE_PUBLIC_IDENTIFIERS_METHOD_NAMES + <p> + + It is a good practice to avoid reusing public identifiers from the Java Standard Library as method names in your code. + Doing so can lead to confusion, potential conflicts, and unexpected behavior. To maintain code clarity and ensure proper functionality, + it is recommended to choose unique and descriptive names for your methods that accurately represent their purpose + and differentiate them from standard library identifiers. + + To provide an example, let's say you want to create a method that handles creation of a custom file in your application. Instead of using a common name like "File" for the method, + which conflicts with the existing java.io.File class, you could choose a more specific and unique name like or "generateFile" or "createOutPutFile". + + A few key points to keep in mind when choosing names as identifier: + <ul> + <li>Use descriptive names: Opt for descriptive method names that clearly indicate their purpose and functionality. This helps avoid shadowing existing Java Standard Library identifiers. For instance, instead of "abs()", consider using "calculateAbsoluteValue()".</li> + <li>Follow naming conventions: Adhere to Java's naming conventions, such as using mixed case for method names. Method names should be verbs, with the first letter lowercase and the first letter of each internal word capitalized (e.g. runFast()). This promotes code readability and reduces the chances of conflicts.</li> + </ul> + + </p> + <p>See SEI CERT rule <a href="https://wiki.sei.cmu.edu/confluence/display/java/DCL01-J.+Do+not+reuse+public+identifiers+from+the+Java+Standard+Library">DCL01-J. Do not reuse public identifiers from the Java Standard Library</a>.</p> + bad-practice + + + Bad practice - Do not reuse public identifiers from JSL as method name + PI_DO_NOT_REUSE_PUBLIC_IDENTIFIERS_LOCAL_VARIABLE_NAMES + <p> + When declaring local variables in Java, it is crucial to refrain from reusing public identifiers from the Java Standard Library. + Reusing these identifiers as local variable names can lead to confusion, hinder code comprehension, and potentially cause conflicts + with existing publicly available identifier names from the Java Standard Library. + To maintain code clarity and avoid such issues, it is best practice to select unique and descriptive names for your local variables. + + To provide an example, let's say you want to store a custom font value in a variable. Instead of using a common name like "Font" for the variable name, + which conflicts with the existing java.awt.Font class, you could choose a more specific and unique name like or "customFont" or "loadedFontName". + + A few key points to keep in mind when choosing names as identifier: + <ul> + <li>Use descriptive names: Opt for descriptive variable names that clearly indicate their purpose and functionality. This helps avoid shadowing existing Java Standard Library identifiers. For instance, instead of "variable", consider using "myVariableName".</li> + <li>Follow naming conventions: Adhere to Java's naming conventions, such as using mixed case for variable names. Start with a lowercase first letter and the internal words should start with capital letters (e.g. myVariableName). This promotes code readability and reduces the chances of conflicts.</li> + </ul> + + </p> + <p>See SEI CERT rule <a href="https://wiki.sei.cmu.edu/confluence/display/java/DCL01-J.+Do+not+reuse+public+identifiers+from+the+Java+Standard+Library">DCL01-J. Do not reuse public identifiers from the Java Standard Library</a>.</p> + bad-practice + + + Experimental - Do not reuse public identifiers from JSL as inner name + PI_DO_NOT_REUSE_PUBLIC_IDENTIFIERS_INNER_CLASS_NAMES + <p> + It's essential to avoid reusing public identifiers from the Java Standard Library as class names. + This is because the Java Standard Library is a part of the Java platform and is expected to be available in all Java environments. + Doing so can lead to naming conflicts and confusion, making it harder to understand and maintain the code. + It's best practice to choose unique and descriptive class names that accurately represent the purpose and functionality of your own code. + To provide an example, let's say you want to create an inner class for handling dates inside a specific Calendar class. Instead of using a common name like "Date", + which conflicts with the existing java.util.Date class, you could choose a more specific and unique name like or "CalendarDate" or "CalendarDisplayDate". + + A few key points to keep in mind when choosing names as identifier: + <ul> + <li>Use meaningful prefixes or namespaces: Prepend a project-specific prefix or namespace to your class names to make them distinct. For example, if your project is named "MyApp", you could use "MyAppDate" as your class name.</li> + <li>Use descriptive names: Opt for descriptive class names that clearly indicate their purpose and functionality. This helps avoid shadowing existing Java Standard Library identifiers. For instance, instead of "List", consider using "CustomAppList".</li> + <li>Follow naming conventions: Adhere to Java's naming conventions, such as using camel case (e.g., MyClass) for class names. This promotes code readability and reduces the chances of conflicts.</li> + </ul> + + </p> + <p>See SEI CERT rule <a href="https://wiki.sei.cmu.edu/confluence/display/java/DCL01-J.+Do+not+reuse+public+identifiers+from+the+Java+Standard+Library">DCL01-J. Do not reuse public identifiers from the Java Standard Library</a>.</p> + experimental + \ No newline at end of file diff --git a/src/test/java/org/sonar/plugins/findbugs/FindbugsProfileImporterTest.java b/src/test/java/org/sonar/plugins/findbugs/FindbugsProfileImporterTest.java index 655cbf33..7cdb7611 100644 --- a/src/test/java/org/sonar/plugins/findbugs/FindbugsProfileImporterTest.java +++ b/src/test/java/org/sonar/plugins/findbugs/FindbugsProfileImporterTest.java @@ -147,7 +147,7 @@ void shouldImportConfigurationBugInclude() { BuiltInQualityProfile profile = context.profile(Java.KEY, TEST_PROFILE); Collection results = profile.rules(); - assertThat(results).hasSize(21); + assertThat(results).hasSize(23); assertThat(findActiveRule(profile, FindbugsRulesDefinition.REPOSITORY_KEY, "RC_REF_COMPARISON_BAD_PRACTICE")).isNotNull(); }