From 6bf741235d3527c2b0a44937c996a15431450d57 Mon Sep 17 00:00:00 2001
From: Alban Auzeill <alban.auzeill@sonarsource.com>
Date: Mon, 19 Jun 2023 13:34:50 +0200
Subject: [PATCH] SONARJAVA-4524 Update rules metadata (#4408)

---
 .../java/org/sonar/java/it/AutoScanTest.java  |   2 +-
 .../autoscan/autoscan-diff-by-rules.json      |  12 --
 .../org/sonar/l10n/java/rules/java/S100.html  |  12 +-
 .../org/sonar/l10n/java/rules/java/S101.html  |  11 +-
 .../org/sonar/l10n/java/rules/java/S103.html  |   2 +-
 .../org/sonar/l10n/java/rules/java/S104.html  |   7 +-
 .../org/sonar/l10n/java/rules/java/S105.html  |   5 +-
 .../org/sonar/l10n/java/rules/java/S108.html  |  10 +-
 .../org/sonar/l10n/java/rules/java/S110.html  |  24 ++-
 .../org/sonar/l10n/java/rules/java/S1111.html |  12 +-
 .../org/sonar/l10n/java/rules/java/S1111.json |   2 +-
 .../org/sonar/l10n/java/rules/java/S1113.html |  23 ++-
 .../org/sonar/l10n/java/rules/java/S1113.json |   2 +-
 .../org/sonar/l10n/java/rules/java/S1114.html |   1 +
 .../org/sonar/l10n/java/rules/java/S1114.json |   7 +-
 .../org/sonar/l10n/java/rules/java/S1117.html |   4 +-
 .../org/sonar/l10n/java/rules/java/S1118.html |   4 +-
 .../org/sonar/l10n/java/rules/java/S1130.html |  49 +++--
 .../org/sonar/l10n/java/rules/java/S1130.json |   2 +-
 .../org/sonar/l10n/java/rules/java/S1134.html |   4 +-
 .../org/sonar/l10n/java/rules/java/S1134.json |   2 +-
 .../org/sonar/l10n/java/rules/java/S1149.html |  20 +-
 .../org/sonar/l10n/java/rules/java/S1149.json |   2 +-
 .../org/sonar/l10n/java/rules/java/S1150.html |  17 +-
 .../org/sonar/l10n/java/rules/java/S1150.json |   2 +-
 .../org/sonar/l10n/java/rules/java/S1153.html |  12 +-
 .../org/sonar/l10n/java/rules/java/S1153.json |   4 +-
 .../org/sonar/l10n/java/rules/java/S1157.html |  24 ++-
 .../org/sonar/l10n/java/rules/java/S1157.json |   3 +-
 .../org/sonar/l10n/java/rules/java/S1158.html |  24 ++-
 .../org/sonar/l10n/java/rules/java/S1161.html |  23 ++-
 .../org/sonar/l10n/java/rules/java/S1163.html |  11 +-
 .../org/sonar/l10n/java/rules/java/S1163.json |   2 +-
 .../org/sonar/l10n/java/rules/java/S1165.html |  23 +--
 .../org/sonar/l10n/java/rules/java/S1165.json |   2 +-
 .../org/sonar/l10n/java/rules/java/S1171.html |  53 +++--
 .../org/sonar/l10n/java/rules/java/S1182.html |  20 +-
 .../org/sonar/l10n/java/rules/java/S1190.html |  36 ++--
 .../org/sonar/l10n/java/rules/java/S1191.html |  17 +-
 .../org/sonar/l10n/java/rules/java/S1193.html |  19 +-
 .../org/sonar/l10n/java/rules/java/S1195.html |  34 ++--
 .../org/sonar/l10n/java/rules/java/S1201.html |  52 +++--
 .../org/sonar/l10n/java/rules/java/S121.html  |  16 +-
 .../org/sonar/l10n/java/rules/java/S121.json  |   1 -
 .../org/sonar/l10n/java/rules/java/S1214.html |  99 +++++++---
 .../org/sonar/l10n/java/rules/java/S1214.json |   2 +-
 .../org/sonar/l10n/java/rules/java/S1217.html |  92 ++++++++-
 .../org/sonar/l10n/java/rules/java/S122.html  |   9 +-
 .../org/sonar/l10n/java/rules/java/S1220.html |  40 ++--
 .../org/sonar/l10n/java/rules/java/S1221.html |  32 +--
 .../org/sonar/l10n/java/rules/java/S1317.html |  47 ++++-
 .../org/sonar/l10n/java/rules/java/S1319.html |  42 ++--
 .../org/sonar/l10n/java/rules/java/S1452.html |  62 ++++--
 .../org/sonar/l10n/java/rules/java/S1596.html |  54 +++--
 .../org/sonar/l10n/java/rules/java/S1598.html |  58 +++++-
 .../org/sonar/l10n/java/rules/java/S1602.html |  44 +++--
 .../org/sonar/l10n/java/rules/java/S1604.html |  54 +++--
 .../org/sonar/l10n/java/rules/java/S1610.html |   1 +
 .../org/sonar/l10n/java/rules/java/S1610.json |   6 +-
 .../org/sonar/l10n/java/rules/java/S1611.html |  11 +-
 .../org/sonar/l10n/java/rules/java/S1611.json |   2 +-
 .../org/sonar/l10n/java/rules/java/S1612.html |  50 +++--
 .../org/sonar/l10n/java/rules/java/S1640.html |  39 ++--
 .../org/sonar/l10n/java/rules/java/S1640.json |   2 +-
 .../org/sonar/l10n/java/rules/java/S1710.html |  22 ++-
 .../org/sonar/l10n/java/rules/java/S1844.html |  42 ++--
 .../org/sonar/l10n/java/rules/java/S1844.json |   2 +-
 .../org/sonar/l10n/java/rules/java/S1849.html |  62 ++++--
 .../org/sonar/l10n/java/rules/java/S1860.html |  69 ++++---
 .../org/sonar/l10n/java/rules/java/S1948.html |  94 ++++++---
 .../org/sonar/l10n/java/rules/java/S1989.html |  48 +++--
 .../org/sonar/l10n/java/rules/java/S2055.html | 187 ++++++++++++++----
 .../org/sonar/l10n/java/rules/java/S2060.html |  77 ++++++--
 .../org/sonar/l10n/java/rules/java/S2068.html |   4 +-
 .../org/sonar/l10n/java/rules/java/S2111.html |  42 ++--
 .../org/sonar/l10n/java/rules/java/S2112.html |  35 ++--
 .../org/sonar/l10n/java/rules/java/S2114.json |   2 +-
 .../org/sonar/l10n/java/rules/java/S2116.html |  48 +++--
 .../org/sonar/l10n/java/rules/java/S2118.html |  48 +++--
 .../org/sonar/l10n/java/rules/java/S2118.json |   2 +-
 .../org/sonar/l10n/java/rules/java/S2119.html |  52 +++--
 .../org/sonar/l10n/java/rules/java/S2121.html |  44 +++--
 .../org/sonar/l10n/java/rules/java/S2121.json |   2 +-
 .../org/sonar/l10n/java/rules/java/S2122.html |  35 +++-
 .../org/sonar/l10n/java/rules/java/S2127.html |  29 ++-
 .../org/sonar/l10n/java/rules/java/S2127.json |   2 +-
 .../org/sonar/l10n/java/rules/java/S2129.html |  27 ++-
 .../org/sonar/l10n/java/rules/java/S2130.html |  18 +-
 .../org/sonar/l10n/java/rules/java/S2133.html |   6 +-
 .../org/sonar/l10n/java/rules/java/S2133.json |   4 +-
 .../org/sonar/l10n/java/rules/java/S2134.html |  62 ++++--
 .../org/sonar/l10n/java/rules/java/S2134.json |   2 +-
 .../org/sonar/l10n/java/rules/java/S2140.html |  15 +-
 .../org/sonar/l10n/java/rules/java/S2140.json |   3 +-
 .../org/sonar/l10n/java/rules/java/S2142.html |  39 ++--
 .../org/sonar/l10n/java/rules/java/S2142.json |   2 +-
 .../org/sonar/l10n/java/rules/java/S2151.html |  28 +--
 .../org/sonar/l10n/java/rules/java/S2153.html |  48 ++---
 .../org/sonar/l10n/java/rules/java/S2153.json |   2 +-
 .../org/sonar/l10n/java/rules/java/S2157.html |  99 +++++++---
 .../org/sonar/l10n/java/rules/java/S2160.html |  98 +++++----
 .../org/sonar/l10n/java/rules/java/S2160.json |   2 +-
 .../org/sonar/l10n/java/rules/java/S2165.html |  40 +++-
 .../org/sonar/l10n/java/rules/java/S2235.html |  36 ++--
 .../org/sonar/l10n/java/rules/java/S2235.json |   2 +-
 .../org/sonar/l10n/java/rules/java/S2236.html |  23 ++-
 .../org/sonar/l10n/java/rules/java/S2390.html |  13 +-
 .../org/sonar/l10n/java/rules/java/S2390.json |   4 +-
 .../org/sonar/l10n/java/rules/java/S2437.json |   2 +-
 .../org/sonar/l10n/java/rules/java/S2438.html |  47 ++---
 .../org/sonar/l10n/java/rules/java/S2438.json |   2 +-
 .../org/sonar/l10n/java/rules/java/S2441.html |  22 ++-
 .../org/sonar/l10n/java/rules/java/S2441.json |   2 +-
 .../org/sonar/l10n/java/rules/java/S2442.html |  20 +-
 .../org/sonar/l10n/java/rules/java/S2442.json |   2 +-
 .../org/sonar/l10n/java/rules/java/S2445.html |   4 +-
 .../org/sonar/l10n/java/rules/java/S2446.html |  27 +--
 .../org/sonar/l10n/java/rules/java/S2446.json |   2 +-
 .../org/sonar/l10n/java/rules/java/S2447.html |  32 ++-
 .../org/sonar/l10n/java/rules/java/S2447.json |   2 +-
 .../org/sonar/l10n/java/rules/java/S2583.html |   4 +-
 .../org/sonar/l10n/java/rules/java/S2629.html |   9 +-
 .../org/sonar/l10n/java/rules/java/S2681.html |  49 ++---
 .../org/sonar/l10n/java/rules/java/S2692.html |  41 ++--
 .../org/sonar/l10n/java/rules/java/S2757.html |  25 ++-
 .../org/sonar/l10n/java/rules/java/S2757.json |   2 +-
 .../org/sonar/l10n/java/rules/java/S2761.html |  35 ++--
 .../org/sonar/l10n/java/rules/java/S2925.json |   2 +-
 .../org/sonar/l10n/java/rules/java/S2975.html | 116 ++++++++---
 .../org/sonar/l10n/java/rules/java/S3011.html |   8 +-
 .../org/sonar/l10n/java/rules/java/S3358.html |   8 +-
 .../org/sonar/l10n/java/rules/java/S3776.html |   3 +-
 .../org/sonar/l10n/java/rules/java/S3923.html |   9 +-
 .../org/sonar/l10n/java/rules/java/S3972.html |  25 ++-
 .../org/sonar/l10n/java/rules/java/S3973.html |  31 +--
 .../org/sonar/l10n/java/rules/java/S4143.html |   5 +-
 .../org/sonar/l10n/java/rules/java/S4144.html |  17 +-
 .../org/sonar/l10n/java/rules/java/S4275.html |   2 +-
 .../org/sonar/l10n/java/rules/java/S4275.json |   2 +-
 .../org/sonar/l10n/java/rules/java/S4524.html |  25 +--
 .../org/sonar/l10n/java/rules/java/S5547.html |  86 ++++----
 .../org/sonar/l10n/java/rules/java/S6418.html |  31 ++-
 .../java/rules/java/Sonar_way_profile.json    |   2 -
 sonarpedia.json                               |   2 +-
 144 files changed, 2278 insertions(+), 1306 deletions(-)

diff --git a/its/ruling/src/test/java/org/sonar/java/it/AutoScanTest.java b/its/ruling/src/test/java/org/sonar/java/it/AutoScanTest.java
index cd2499f9ab2..57286f8ac2d 100644
--- a/its/ruling/src/test/java/org/sonar/java/it/AutoScanTest.java
+++ b/its/ruling/src/test/java/org/sonar/java/it/AutoScanTest.java
@@ -188,7 +188,7 @@ public void javaCheckTestSources() throws Exception {
      * No differences would mean that we find the same issues with and without the bytecode and libraries
      */
     String differences = Files.readString(pathFor(TARGET_ACTUAL + PROJECT_KEY + "-no-binaries_differences"));
-    assertThat(differences).isEqualTo("Issues differences: 3269");
+    assertThat(differences).isEqualTo("Issues differences: 3265");
   }
 
   private static Path pathFor(String path) {
diff --git a/its/ruling/src/test/resources/autoscan/autoscan-diff-by-rules.json b/its/ruling/src/test/resources/autoscan/autoscan-diff-by-rules.json
index ac480fc6c20..7d7541f66d4 100644
--- a/its/ruling/src/test/resources/autoscan/autoscan-diff-by-rules.json
+++ b/its/ruling/src/test/resources/autoscan/autoscan-diff-by-rules.json
@@ -161,12 +161,6 @@
     "falseNegatives": 0,
     "falsePositives": 0
   },
-  {
-    "ruleKey": "S1114",
-    "hasTruePositives": true,
-    "falseNegatives": 0,
-    "falsePositives": 0
-  },
   {
     "ruleKey": "S1116",
     "hasTruePositives": true,
@@ -587,12 +581,6 @@
     "falseNegatives": 11,
     "falsePositives": 0
   },
-  {
-    "ruleKey": "S1610",
-    "hasTruePositives": true,
-    "falseNegatives": 4,
-    "falsePositives": 0
-  },
   {
     "ruleKey": "S1611",
     "hasTruePositives": true,
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S100.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S100.html
index 1232317c668..78c6a5e2456 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S100.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S100.html
@@ -1,11 +1,11 @@
 <h2>Why is this an issue?</h2>
-<p>Shared naming conventions allow teams to collaborate efficiently. This rule checks that all method names match a provided regular expression.</p>
-<h3>Noncompliant code example</h3>
-<p>With default provided regular expression <code>^[a-z][a-zA-Z0-9]*$</code>:</p>
+<p>Shared naming conventions allow teams to collaborate efficiently.</p>
+<p>This rule raises an issue when a method name does not match a provided regular expression.</p>
+<p>For example, with the default provided regular expression <code>^[a-z][a-zA-Z0-9]*$</code>, the method:</p>
 <pre>
-public int DoSomething(){...}
+public int DoSomething(){...} // Noncompliant
 </pre>
-<h3>Compliant solution</h3>
+<p>should be renamed to</p>
 <pre>
 public int doSomething(){...}
 </pre>
@@ -13,6 +13,6 @@ <h3>Exceptions</h3>
 <p>Overriding methods are excluded.</p>
 <pre>
 @Override
-public int Do_Something(){...}
+public int Do_Something(){...} // Compliant by exception
 </pre>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S101.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S101.html
index f772827d774..09f1ed1e20c 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S101.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S101.html
@@ -1,12 +1,11 @@
 <h2>Why is this an issue?</h2>
-<p>Shared coding conventions allow teams to collaborate effectively. This rule allows to check that all class names match a provided regular
-expression.</p>
-<h3>Noncompliant code example</h3>
-<p>With default provided regular expression <code>^[A-Z][a-zA-Z0-9]*$</code>:</p>
+<p>Shared naming conventions allow teams to collaborate efficiently.</p>
+<p>This rule raises an issue when a class name does not match a provided regular expression.</p>
+<p>For example, with the default provided regular expression <code>^[A-Z][a-zA-Z0-9]*$</code>, the class:</p>
 <pre>
-class my_class {...}
+class my_class {...} // Noncompliant
 </pre>
-<h3>Compliant solution</h3>
+<p>should be renamed to</p>
 <pre>
 class MyClass {...}
 </pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S103.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S103.html
index 10a9058c202..013131f8714 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S103.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S103.html
@@ -1,3 +1,3 @@
 <h2>Why is this an issue?</h2>
-<p>Having to scroll horizontally makes it harder to get a quick overview and understanding of any piece of code.</p>
+<p>Scrolling horizontally to see a full line of code lowers the code readability.</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S104.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S104.html
index f6c0dbaa448..cc8ee8fa38f 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S104.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S104.html
@@ -1,5 +1,6 @@
 <h2>Why is this an issue?</h2>
-<p>A source file that grows too much tends to aggregate too many responsibilities and inevitably becomes harder to understand and therefore to
-maintain. Above a specific threshold, it is strongly advised to refactor it into smaller pieces of code which focus on well defined tasks. Those
-smaller files will not only be easier to understand but also probably easier to test.</p>
+<p>A source file that grows too much tends to aggregate too many responsibilities and inevitably becomes harder to understand and, therefore, to
+maintain.</p>
+<p>Above a specific threshold, refactor the file into smaller files whose code focuses on well-defined tasks. Those smaller files will be easier to
+understand and easier to test.</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S105.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S105.html
index 2aab84fc839..2a4251605e3 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S105.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S105.html
@@ -1,4 +1,5 @@
 <h2>Why is this an issue?</h2>
-<p>Developers should not need to configure the tab width of their text editors in order to be able to read source code.</p>
-<p>So the use of the tabulation character must be banned.</p>
+<p>The tab width can differ from one development environment to another. Using tabs may require other developers to configure their environment (text
+editor, preferences, etc.) to read source code.</p>
+<p>That is why using spaces is preferable.</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S108.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S108.html
index 9aa75a10fc0..6fe17c95c47 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S108.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S108.html
@@ -1,10 +1,10 @@
 <h2>Why is this an issue?</h2>
-<p>Most of the time a block of code is empty when a piece of code is really missing. So such empty block must be either filled or removed.</p>
-<h3>Noncompliant code example</h3>
+<p>An empty code block is confusing. It will require some effort from maintainers to determine if it is intentional or indicates the implementation is
+incomplete.</p>
 <pre>
-for (int i = 0; i &lt; 42; i++){}  // Empty on purpose or missing piece of code ?
+for (int i = 0; i &lt; 42; i++){}  // Noncompliant: is the block empty on purpose, or is code missing?
 </pre>
+<p>Removing or filling the empty code blocks takes away ambiguity and generally results in a more straightforward and less surprising code.</p>
 <h3>Exceptions</h3>
-<p>When a block contains a comment, this block is not considered to be empty unless it is a <code>synchronized</code> block. <code>synchronized</code>
-blocks are still considered empty even with comments because they can still affect program flow.</p>
+<p>The rule ignores code blocks that contain comments unless they are <code>synchronized</code> blocks because these can affect program flow.</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S110.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S110.html
index 63beb6ffe8c..fd0be443f34 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S110.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S110.html
@@ -1,10 +1,10 @@
 <h2>Why is this an issue?</h2>
-<p>Inheritance is certainly one of the most valuable concepts in object-oriented programming. It’s a way to compartmentalize and reuse code by
-creating collections of attributes and behaviors called classes which can be based on previously created classes. But abusing this concept by creating
-a deep inheritance tree can lead to very complex and unmaintainable source code. Most of the time too deep of an inheritance tree is due to bad object
-oriented design which leads to a systematic use of 'inheritance' when 'composition' would be better suited.</p>
-<p>This rule raises an issue when the inheritance tree, starting from <code>Object</code> has a greater depth than is allowed.</p>
-<p>For the parameter of the rule, the following rules are applied:</p>
+<p>Inheritance is one of the most valuable concepts in object-oriented programming. It’s a way to categorize and reuse code by creating collections of
+attributes and behaviors called classes, which can be based on previously created classes.</p>
+<p>But abusing this concept by creating a deep inheritance tree can lead to complex and unmaintainable source code. Often, an inheritance tree
+becoming too deep is the symptom of systematic use of "inheritance" when other approaches like "composition" would be better suited.</p>
+<p>This rule raises an issue when the inheritance tree, starting from <code>Object</code>, has a greater depth than is allowed.</p>
+<p>The rule has one parameter to filter out classes of the count of inheritance. The following rules apply to define this parameter:</p>
 <ul>
   <li> <code>?</code> matches a single character </li>
   <li> <code>*</code> matches zero or more characters </li>
@@ -12,11 +12,11 @@ <h2>Why is this an issue?</h2>
 </ul>
 <p>Examples:</p>
 <ul>
-  <li> <code>java.fwk.AbstractFwkClass</code> will stop count when AbstractFwkClassclass is reached. </li>
-  <li> <code>java.fwk.*</code> will stop count when any member of java.fwkPackage package is reached. </li>
-  <li> <code>java.fwk.**</code> same as above, but including sub-packages. </li>
+  <li> <code>java.fwk.AbstractFwkClass</code>: the count stops when AbstractFwkClass class is reached. </li>
+  <li> <code>java.fwk.*</code>: any member of java.fwkPackage package is reached. </li>
+  <li> <code>java.fwk.**</code>: same as above, but including sub-packages. </li>
 </ul>
-<p>Exceptions:</p>
+<h2>Exceptions:</h2>
 <p>The rule stops counting when it encounters a class from one of the following packages (or sub-packages):</p>
 <ul>
   <li> <code>android.**</code> </li>
@@ -26,4 +26,8 @@ <h2>Why is this an issue?</h2>
   <li> <code>org.eclipse.**</code> </li>
   <li> <code>org.springframework.**</code> </li>
 </ul>
+<h2>Resources</h2>
+<h3>Documentation</h3>
+<p><a href="https://en.wikipedia.org/wiki/Composition_over_inheritance">Composition over inheritance: difference between composition and inheritance
+in object-oriented programming</a></p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1111.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1111.html
index 69833610279..2b321a321aa 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1111.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1111.html
@@ -1,6 +1,13 @@
 <h2>Why is this an issue?</h2>
-<p>According to the official javadoc documentation, this Object.finalize() is called by the garbage collector on an object when garbage collection
-determines that there are no more references to the object. Calling this method explicitly breaks this contract and so is misleading.</p>
+<p>Before it reclaims storage from an object that is no longer referenced, the garbage collector calls <code>finalize()</code> on the object.</p>
+<p>This is a good time to release resources held by the object.</p>
+<p>Because the general contract is that the <code>finalize</code> method should only be called once per object, calling this method explicitly is
+misleading and does not respect this contract.</p>
+<h3>What is the potential impact?</h3>
+<p>An explicit call to an object’s finalize method will perform operations that most likely were supposed to be performed only when the object was not
+referenced anymore by any thread.</p>
+<p>Since it is an acceptable practice to override the finalize method in any subclass of <code>Object</code>, by invoking it explicitly, we will run
+code that was designed to only be ran at a different time.</p>
 <h3>Noncompliant code example</h3>
 <pre>
 public void dispose() throws Throwable {
@@ -9,6 +16,7 @@ <h3>Noncompliant code example</h3>
 </pre>
 <h2>Resources</h2>
 <ul>
+  <li> <a href="https://docs.oracle.com/javase/specs/jls/se17/html/jls-12.html#jls-12.6">docs.oracle.com</a> - Finalization of Class Instances </li>
   <li> <a href="https://cwe.mitre.org/data/definitions/586">MITRE, CWE-586</a> - Explicit Call to Finalize() </li>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/4jZGBQ">CERT, MET12-J.</a> - Do not use finalizers </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1111.json b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1111.json
index 8d1dd3651b3..fa96fbc03ba 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1111.json
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1111.json
@@ -1,5 +1,5 @@
 {
-  "title": "The Object.finalize() method should not be called",
+  "title": "The \"Object.finalize()\" method should not be called",
   "type": "BUG",
   "status": "ready",
   "remediation": {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1113.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1113.html
index 81f76dbe18f..81347a39289 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1113.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1113.html
@@ -1,20 +1,31 @@
 <h2>Why is this an issue?</h2>
-<p>The <code>Object.finalize()</code> method is called on an object by the garbage collector when it determines that there are no more references to
-the object. But there is absolutely no warranty that this method will be called AS SOON AS the last references to the object are removed. It can be
-few microseconds to few minutes later. So when system resources need to be disposed by an object, it’s better to not rely on this asynchronous
-mechanism to dispose them.</p>
+<p>Before it reclaims storage from an object that is no longer referenced, the garbage collector calls <code>finalize()</code> on the object.</p>
+<p>But there is no guarantee that this method will be called as soon as the last references to the object are removed.</p>
+<p>It can be few microseconds to few minutes later.</p>
+<p>For this reason relying on overriding the <code>finalize()</code> method to release resources or to update the state of the program is highly
+discouraged.</p>
+<h3>What is the potential impact?</h3>
+<p>More unexpected issues can be caused by relying on the <code>finalize()</code> method to perform important operations on the application state:</p>
+<ul>
+  <li> The JVM might terminate without ever calling this method on a particular object, leaving an unexpected or incomplete state of the program </li>
+  <li> Uncaught exceptions will be ignored inside this method, making it harder to detect issues that could have been logged otherwise </li>
+  <li> Finalizer methods can also be invoked concurrently, even on single-threaded applications, making it hard to maintain desired program invariants
+  </li>
+</ul>
 <h3>Noncompliant code example</h3>
 <pre>
 public class MyClass {
-  ...
+
+  @Override
   protected void finalize() {
     releaseSomeResources();    // Noncompliant
   }
-  ...
+
 }
 </pre>
 <h2>Resources</h2>
 <ul>
+  <li> <a href="https://docs.oracle.com/javase/specs/jls/se17/html/jls-12.html#jls-12.6">docs.oracle.com</a> - Finalization of Class Instances </li>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/4jZGBQ">CERT, MET12-J.</a> - Do not use finalizers </li>
 </ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1113.json b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1113.json
index 16cd7394ddd..9407e453a2b 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1113.json
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1113.json
@@ -1,5 +1,5 @@
 {
-  "title": "The Object.finalize() method should not be overridden",
+  "title": "The \"Object.finalize()\" method should not be overridden",
   "type": "CODE_SMELL",
   "status": "ready",
   "remediation": {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1114.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1114.html
index fb6513fbe7d..4ca94be8155 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1114.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1114.html
@@ -1,3 +1,4 @@
+<p>This rule is deprecated, and will eventually be removed.</p>
 <h2>Why is this an issue?</h2>
 <p>Overriding the <code>Object.finalize()</code> method must be done with caution to dispose some system resources.</p>
 <p>Calling the <code>super.finalize()</code> at the end of this method implementation is highly recommended in case parent implementations must also
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1114.json b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1114.json
index a123ee68766..7ebbe7efd6f 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1114.json
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1114.json
@@ -1,15 +1,12 @@
 {
   "title": "\"super.finalize()\" should be called at the end of \"Object.finalize()\" implementations",
   "type": "BUG",
-  "status": "ready",
+  "status": "deprecated",
   "remediation": {
     "func": "Constant\/Issue",
     "constantCost": "5min"
   },
-  "tags": [
-    "cwe",
-    "cert"
-  ],
+  "tags": [],
   "defaultSeverity": "Critical",
   "ruleSpecification": "RSPEC-1114",
   "sqKey": "S1114",
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1117.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1117.html
index fe4b6a30992..5942c2b9bc0 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1117.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1117.html
@@ -1,18 +1,18 @@
 <h2>Why is this an issue?</h2>
 <p>Overriding or shadowing a variable declared in an outer scope can strongly impact the readability, and therefore the maintainability, of a piece of
 code. Further, it could lead maintainers to introduce bugs because they think they’re using one variable but are really using another.</p>
-<h3>Noncompliant code example</h3>
 <pre>
 class Foo {
   public int myField;
 
   public void doSomething() {
-    int myField = 0;
+    int myField = 0; // Noncompliant
     ...
   }
 }
 </pre>
 <h2>Resources</h2>
+<h3>Documentation</h3>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/display/c/DCL01-C.+Do+not+reuse+variable+names+in+subscopes">CERT, DCL01-C.</a> - Do not reuse
   variable names in subscopes </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1118.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1118.html
index 36ded924a7b..d009768e2ee 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1118.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1118.html
@@ -4,7 +4,7 @@ <h2>Why is this an issue?</h2>
 <p>Java adds an implicit public constructor to every class which does not define at least one explicitly. Hence, at least one non-public constructor
 should be defined.</p>
 <h3>Noncompliant code example</h3>
-<pre>
+<pre data-diff-id="1" data-diff-type="noncompliant">
 class StringUtils { // Noncompliant
 
   public static String concatenate(String s1, String s2) {
@@ -14,7 +14,7 @@ <h3>Noncompliant code example</h3>
 }
 </pre>
 <h3>Compliant solution</h3>
-<pre>
+<pre data-diff-id="1" data-diff-type="compliant">
 class StringUtils { // Compliant
 
   private StringUtils() {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1130.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1130.html
index fbb92b15ee6..44a8f6ae449 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1130.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1130.html
@@ -1,56 +1,75 @@
 <h2>Why is this an issue?</h2>
-<p>An exception in a <code>throws</code> declaration in Java is superfluous if it is:</p>
+<p>Superfluous exceptions within <code>throws</code> clauses have negative effects on the readability and maintainability of the code. An exception in
+a <code>throws</code> clause is superfluous if it is:</p>
 <ul>
   <li> listed multiple times </li>
   <li> a subclass of another listed exception </li>
-  <li> completely unnecessary because the declared exception type cannot actually be thrown </li>
+  <li> not actually thrown by any execution path of the method </li>
 </ul>
 <h3>Noncompliant code example</h3>
-<pre>
+<pre data-diff-id="1" data-diff-type="noncompliant">
 void foo() throws MyException, MyException {}  // Noncompliant; should be listed once
 void bar() throws Throwable, Exception {}  // Noncompliant; Exception is a subclass of Throwable
+void boo() throws IOException { // Noncompliant; IOException cannot be thrown
+  System.out.println("Hi!");
+}
 </pre>
 <h3>Compliant solution</h3>
-<pre>
+<pre data-diff-id="1" data-diff-type="compliant">
 void foo() throws MyException {}
 void bar() throws Throwable {}
+void boo() {
+  System.out.println("Hi!");
+}
 </pre>
 <h3>Exceptions</h3>
 <p>The rule will not raise any issue for exceptions that cannot be thrown from the method body:</p>
 <ul>
-  <li> in overriding and implementation methods </li>
   <li> in interface <code>default</code> methods </li>
+  <li> in overriding and implementating methods </li>
   <li> in non-private methods that only <code>throw</code>, have empty bodies, or a single return statement. </li>
   <li> in overridable methods (non-final, or not member of a final class, non-static, non-private), if the exception is documented with a proper
   JavaDoc </li>
 </ul>
-<p>Also, the rule won’t raise issues on <code>RuntimeException</code>, or one of its descendants, because explicating runtime exceptions which could
-be thrown can ultimately help the method’s users, and can even be considered as good practice.</p>
 <pre>
-class A extends B {
+interface MyInterface {
+  default void defaultMethod() throws IOException {
+    System.out.println("Hi!");
+  }
+  void doSomething() throws IOException;
+}
+
+class A implements MyInterface {
   @Override
   void doSomething() throws IOException {
-    compute(a);
+    System.out.println("Hi!");
   }
 
-  public void foo() throws IOException {}
-
-  public void qix() throws MyRuntimeException {}
+  public void emptyBody() throws IOException {}
 
-  protected void bar() throws IOException {
+  protected void singleThrowStatement() throws IOException {
     throw new UnsupportedOperationException("This method should be implemented in subclasses");
   }
 
-  Object foobar(String s) throws IOException {
+  Object singleReturnStatement() throws IOException {
     return null;
   }
 
   /**
    * @throws IOException Overriding classes may throw this exception if they print values into a file
    */
-  protected void print() throws IOException { // no issue, method is overridable and the exception has proper javadoc
+  protected void overridable() throws IOException { // no issue, method is overridable and the exception has proper javadoc
     System.out.println("foo");
   }
 }
 </pre>
+<p>Also, the rule will not raise issues on <code>RuntimeException</code>, or one of its sub-classes, because documenting runtime exceptions which
+could be thrown can ultimately help users of the method understand its behavior.</p>
+<pre>
+class B {
+  int possibleDivisionByZero(int a, int b) throws ArithmeticException {
+      return a / b;
+  }
+}
+</pre>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1130.json b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1130.json
index c362bb7794f..ba606d60340 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1130.json
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1130.json
@@ -1,5 +1,5 @@
 {
-  "title": "\"throws\" declarations should not be superfluous",
+  "title": "Exceptions in \"throws\" clauses should not be superfluous",
   "type": "CODE_SMELL",
   "status": "ready",
   "remediation": {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1134.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1134.html
index 42d9a98a2a7..cc8ebaf5fab 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1134.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1134.html
@@ -2,14 +2,14 @@ <h2>Why is this an issue?</h2>
 <p><code>FIXME</code> tags are commonly used to mark places where a bug is suspected, but which the developer wants to deal with later.</p>
 <p>Sometimes the developer will not have the time or will simply forget to get back to that tag.</p>
 <p>This rule is meant to track those tags and to ensure that they do not go unnoticed.</p>
-<h3>Noncompliant code example</h3>
 <pre>
 int divide(int numerator, int denominator) {
   return numerator / denominator;              // FIXME denominator value might be  0
 }
 </pre>
 <h2>Resources</h2>
+<h3>Documentation</h3>
 <ul>
-  <li> <a href="https://cwe.mitre.org/data/definitions/546">MITRE, CWE-546</a> - Suspicious Comment </li>
+  <li> <a href="https://cwe.mitre.org/data/definitions/546">MITRE, CWE-546 - Suspicious Comment</a> </li>
 </ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1134.json b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1134.json
index 00aef3d01f5..2fb339349af 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1134.json
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1134.json
@@ -18,5 +18,5 @@
       546
     ]
   },
-  "quickfix": "unknown"
+  "quickfix": "infeasible"
 }
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1149.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1149.html
index ec4c6b1eb66..666a7a39687 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1149.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1149.html
@@ -1,27 +1,27 @@
 <h2>Why is this an issue?</h2>
 <p>Early classes of the Java API, such as <code>Vector</code>, <code>Hashtable</code> and <code>StringBuffer</code>, were synchronized to make them
-thread-safe. Unfortunately, synchronization has a big negative impact on performance, even when using these collections from a single thread.</p>
-<p>It is better to use their new unsynchronized replacements:</p>
+thread-safe. However, synchronization has a significant negative impact on performance, even when using these collections from a single thread.</p>
+<p>It is often best to use their non-synchronized counterparts:</p>
 <ul>
   <li> <code>ArrayList</code> or <code>LinkedList</code> instead of <code>Vector</code> </li>
   <li> <code>Deque</code> instead of <code>Stack</code> </li>
   <li> <code>HashMap</code> instead of <code>Hashtable</code> </li>
   <li> <code>StringBuilder</code> instead of <code>StringBuffer</code> </li>
 </ul>
-<p>Even when used in synchronized context, you should think twice before using it, since it’s usage can be tricky. If you are confident the usage is
-legitimate, you can safely ignore this warning.</p>
+<p>Even when used in synchronized contexts, you should think twice before using their synchronized counterparts, since their usage can be costly. If
+you are confident the usage is legitimate, you can safely ignore this warning.</p>
 <h3>Noncompliant code example</h3>
-<pre>
-Vector cats = new Vector();
+<pre data-diff-id="1" data-diff-type="noncompliant">
+Vector&lt;Cat&gt; cats = new Vector&lt;&gt;();
 </pre>
 <h3>Compliant solution</h3>
-<pre>
-ArrayList cats = new ArrayList();
+<pre data-diff-id="1" data-diff-type="compliant">
+ArrayList&lt;Cat&gt; cats = new ArrayList&lt;&gt;();
 </pre>
 <h3>Exceptions</h3>
-<p>Use of those synchronized classes is ignored in the signatures of overriding methods.</p>
+<p>Usage of these synchronized classes is ignored in the signatures of overriding methods.</p>
 <pre>
 @Override
-public Vector getCats() {...}
+public Vector getCats() {...} // Compliant
 </pre>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1149.json b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1149.json
index 10a7b2a7007..4ddefceef61 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1149.json
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1149.json
@@ -1,5 +1,5 @@
 {
-  "title": "Synchronized classes Vector, Hashtable, Stack and StringBuffer should not be used",
+  "title": "Synchronized classes \"Vector\", \"Hashtable\", \"Stack\" and \"StringBuffer\" should not be used",
   "type": "CODE_SMELL",
   "status": "ready",
   "remediation": {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1150.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1150.html
index 9c8e5fbaa86..7e496b67c61 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1150.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1150.html
@@ -1,19 +1,20 @@
 <h2>Why is this an issue?</h2>
-<p>From the official Oracle Javadoc:</p>
-<blockquote>
-  <p>NOTE: The functionality of this Enumeration interface is duplicated by the Iterator interface. In addition, Iterator adds an optional remove
-  operation, and has shorter method names. New implementations should consider using Iterator in preference to Enumeration.</p>
-</blockquote>
+<p>As documented in <code>Enumeration</code> 's Javadoc, you should favor the <code>Iterator</code> interface over <code>Enumeration</code>.
+<code>Iterator</code> offers a similar contract to <code>Enumeration</code> with the addition of a method for removal and shorter method names.</p>
 <h3>Noncompliant code example</h3>
-<pre>
-public class MyClass implements Enumeration {  // Non-Compliant
+<pre data-diff-id="1" data-diff-type="noncompliant">
+public class MyClass implements Enumeration {  // Noncompliant
   /* ... */
 }
 </pre>
 <h3>Compliant solution</h3>
-<pre>
+<pre data-diff-id="1" data-diff-type="compliant">
 public class MyClass implements Iterator {     // Compliant
   /* ... */
 }
 </pre>
+<h2>Resources</h2>
+<ul>
+  <li> <a href="https://docs.oracle.com/javase/8/docs/api/java/util/Enumeration.html">docs.oracle.com</a> - Enumeration </li>
+</ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1150.json b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1150.json
index 90153f03db9..147e3520b04 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1150.json
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1150.json
@@ -1,5 +1,5 @@
 {
-  "title": "Enumeration should not be implemented",
+  "title": "\"Enumeration\" should not be implemented",
   "type": "CODE_SMELL",
   "status": "ready",
   "remediation": {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1153.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1153.html
index be20bc7daff..9e2ee91cc04 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1153.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1153.html
@@ -2,15 +2,11 @@ <h2>Why is this an issue?</h2>
 <p>Appending <code>String.valueOf()</code> to a <code>String</code> decreases the code readability.</p>
 <p>The argument passed to <code>String.valueOf()</code> should be directly appended instead.</p>
 <h3>Noncompliant code example</h3>
-<pre>
-public void display(int i){
-  System.out.println("Output is " + String.valueOf(i));    // Noncompliant
-}
+<pre data-diff-id="1" data-diff-type="noncompliant">
+String message = "Output is " + String.valueOf(12);
 </pre>
 <h3>Compliant solution</h3>
-<pre>
-public void display(int i){
-  System.out.println("Output is " + i);                    // Compliant
-}
+<pre data-diff-id="1" data-diff-type="compliant">
+String message = "Output is " + 12;
 </pre>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1153.json b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1153.json
index 2f74fa2d401..58a05e7ac91 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1153.json
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1153.json
@@ -1,5 +1,5 @@
 {
-  "title": "String.valueOf() should not be appended to a String",
+  "title": "\"String.valueOf()\" should not be appended to a \"String\"",
   "type": "CODE_SMELL",
   "status": "ready",
   "remediation": {
@@ -13,5 +13,5 @@
   "ruleSpecification": "RSPEC-1153",
   "sqKey": "S1153",
   "scope": "All",
-  "quickfix": "unknown"
+  "quickfix": "targeted"
 }
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1157.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1157.html
index 6f556039cae..38aaf2d38c6 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1157.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1157.html
@@ -2,19 +2,25 @@ <h2>Why is this an issue?</h2>
 <p>Using <code>toLowerCase()</code> or <code>toUpperCase()</code> to make case insensitive comparisons is inefficient because it requires the creation
 of temporary, intermediate <code>String</code> objects.</p>
 <h3>Noncompliant code example</h3>
-<pre>
-boolean result1 = foo.toUpperCase().equals(bar);             // Noncompliant
-boolean result2 = foo.equals(bar.toUpperCase());             // Noncompliant
-boolean result3 = foo.toLowerCase().equals(bar.LowerCase()); // Noncompliant
+<pre data-diff-id="1" data-diff-type="noncompliant">
+private void compareStrings(String foo, String bar){
+    boolean result1 = foo.toUpperCase().equals(bar);               // Noncompliant
+    boolean result2 = foo.equals(bar.toUpperCase());               // Noncompliant
+    boolean result3 = foo.toLowerCase().equals(bar.toLowerCase()); // Noncompliant
+}
 </pre>
 <h3>Compliant solution</h3>
-<pre>
-boolean result = foo.equalsIgnoreCase(bar);                  // Compliant
+<pre data-diff-id="1" data-diff-type="compliant">
+private void compareStrings(String foo, String bar){
+    boolean result1 = foo.equalsIgnoreCase(bar);                    // Compliant
+}
 </pre>
 <h3>Exceptions</h3>
-<p>No issue will be raised when a locale is specified because the result could be different from "equalsIgnoreCase". (e.g.: using the Turkish
-locale)</p>
+<p>No issue will be raised when a locale is specified because the result could be different from <code>equalsIgnoreCase()</code>. (e.g.: using the
+Turkish locale)</p>
 <pre>
-boolean result1 = foo.toUpperCase(locale).equals(bar);             // Compliant
+private void compareStrings(String foo, String bar, java.util.Locale locale){
+    boolean result1 = foo.toUpperCase(locale).equals(bar);         // Compliant
+}
 </pre>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1157.json b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1157.json
index d03b12a40df..0c2a870abee 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1157.json
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1157.json
@@ -7,7 +7,8 @@
     "constantCost": "5min"
   },
   "tags": [
-    "clumsy"
+    "clumsy",
+    "performance"
   ],
   "defaultSeverity": "Minor",
   "ruleSpecification": "RSPEC-1157",
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1158.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1158.html
index e71183a256f..daf5cb85d91 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1158.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1158.html
@@ -1,15 +1,23 @@
 <h2>Why is this an issue?</h2>
-<p>Creating temporary primitive wrapper objects only for <code>String</code> conversion or the use of the <code>compareTo</code> method is
+<p>Creating temporary primitive wrapper objects only for <code>String</code> conversion or the use of the <code>compareTo()</code> method is
 inefficient.</p>
-<p>Instead, the static <code>toString</code> or <code>compare</code> method of the primitive wrapper class should be used.</p>
+<p>Instead, the static <code>toString()</code> or <code>compare()</code> method of the primitive wrapper class should be used.</p>
 <h3>Noncompliant code example</h3>
-<pre>
-new Integer(myInteger).toString();   // Noncompliant
-Integer.valueOf(myInt).compareTo(0); // Noncompliant
+<pre data-diff-id="1" data-diff-type="noncompliant">
+private int isZero(int value){
+    return Integer.valueOf(value).compareTo(0); // Noncompliant
+}
+private String convert(int value){
+    return Integer.valueOf(value).toString(); // Noncompliant
+}
 </pre>
 <h3>Compliant solution</h3>
-<pre>
-Integer.toString(myInteger);        // Compliant
-Integer.compare(myInteger, 0);      // Compliant
+<pre data-diff-id="1" data-diff-type="compliant">
+private int isZero(int value){
+    return Integer.compare(value, 0); // Compliant
+}
+private String convert(int value){
+    return Integer.toString(value); // Compliant
+}
 </pre>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1161.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1161.html
index d9823986bfe..009468b6f2d 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1161.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1161.html
@@ -1,28 +1,27 @@
 <h2>Why is this an issue?</h2>
-<p>Using the <code>@Override</code> annotation is useful for two reasons :</p>
-<ul>
-  <li> It elicits a warning from the compiler if the annotated method doesn’t actually override anything, as in the case of a misspelling. </li>
-  <li> It improves the readability of the source code by making it obvious that methods are overridden. </li>
-</ul>
+<p>While not mandatory, using the <code>@Override</code> annotation on compliant methods improves readability by making it explicit that methods are
+overriden.</p>
+<p>A compliant method either overrides a parent method or implements an interface or abstract method.</p>
 <h3>Noncompliant code example</h3>
-<pre>
+<pre data-diff-id="1" data-diff-type="noncompliant">
 class ParentClass {
-  public boolean doSomething(){...}
+  public boolean doSomething(){/*...*/}
 }
 class FirstChildClass extends ParentClass {
-  public boolean doSomething(){...}  // Noncompliant
+  public boolean doSomething(){/*...*/}  // Noncompliant
 }
 </pre>
 <h3>Compliant solution</h3>
-<pre>
+<pre data-diff-id="1" data-diff-type="compliant">
 class ParentClass {
-  public boolean doSomething(){...}
+  public boolean doSomething(){/*...*/}
 }
 class FirstChildClass extends ParentClass {
   @Override
-  public boolean doSomething(){...}  // Compliant
+  public boolean doSomething(){/*...*/}  // Compliant
 }
 </pre>
 <h3>Exceptions</h3>
-<p>This rule is relaxed when overriding a method from the <code>Object</code> class like <code>toString()</code>, <code>hashCode()</code>, …​</p>
+<p>This rule does not raise issues when overriding methods from <code>Object</code> (eg: <code>equals()</code>, <code>hashCode()</code>,
+<code>toString()</code>, …​).</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1163.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1163.html
index 86f7cd1589b..123b7493f7e 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1163.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1163.html
@@ -1,8 +1,8 @@
 <h2>Why is this an issue?</h2>
-<p>Throwing an exception from within a finally block will mask any exception which was previously thrown in the <code>try</code> or <code>catch</code>
-block, and the masked’s exception message and stack trace will be lost.</p>
-<h3>Noncompliant code example</h3>
-<pre>
+<p>If an exception is already being thrown within the <code>try</code> block or caught in a <code>catch</code> block, throwing another exception in
+the <code>finally</code> block will override the original exception. This means that the original exception’s message and stack trace will be lost,
+potentially making it challenging to diagnose and troubleshoot the root cause of the problem.</p>
+<pre data-diff-id="1" data-diff-type="noncompliant">
 try {
   /* some work which end up throwing an exception */
   throw new IllegalArgumentException();
@@ -11,8 +11,7 @@ <h3>Noncompliant code example</h3>
   throw new RuntimeException();       // Noncompliant; masks the IllegalArgumentException
 }
 </pre>
-<h3>Compliant solution</h3>
-<pre>
+<pre data-diff-id="1" data-diff-type="compliant">
 try {
   /* some work which end up throwing an exception */
   throw new IllegalArgumentException();
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1163.json b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1163.json
index b63aaea0083..21c893aafd6 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1163.json
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1163.json
@@ -15,7 +15,7 @@
   "ruleSpecification": "RSPEC-1163",
   "sqKey": "S1163",
   "scope": "Main",
-  "quickfix": "unknown",
+  "quickfix": "infeasible",
   "securityStandards": {
     "CERT": [
       "ERR05-J."
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1165.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1165.html
index c750d2bd554..6e463ee3f21 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1165.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1165.html
@@ -1,16 +1,13 @@
 <h2>Why is this an issue?</h2>
-<p>Exceptions are meant to represent the application’s state at the point at which an error occurred.</p>
-<p>Making all fields in an <code>Exception</code> class <code>final</code> ensures that this state:</p>
-<ul>
-  <li> Will be fully defined at the same time the <code>Exception</code> is instantiated. </li>
-  <li> Won’t be updated or corrupted by a questionable error handler. </li>
-</ul>
-<p>This will enable developers to quickly understand what went wrong.</p>
+<p>When a class has all <code>final</code> fields, the compiler ensures that the object’s state remains constant. It also enforces a clear design
+intent of immutability, making the class easier to reason about and use correctly.</p>
+<p>Exceptions are meant to represent the application’s state at the point at which an error occurred. Making all fields in an <code>Exception</code>
+class <code>final</code> ensures that these class fields do not change after initialization.</p>
 <h3>Noncompliant code example</h3>
-<pre>
+<pre data-diff-id="1" data-diff-type="noncompliant">
 public class MyException extends Exception {
 
-  private int status;                               // Noncompliant
+  private int status;                        // Noncompliant
 
   public MyException(String message) {
     super(message);
@@ -27,10 +24,10 @@ <h3>Noncompliant code example</h3>
 }
 </pre>
 <h3>Compliant solution</h3>
-<pre>
+<pre data-diff-id="1" data-diff-type="compliant">
 public class MyException extends Exception {
 
-  private final int status;
+  private final int status;                  // Compliant
 
   public MyException(String message, int status) {
     super(message);
@@ -43,4 +40,8 @@ <h3>Compliant solution</h3>
 
 }
 </pre>
+<h2>Resources</h2>
+<ul>
+  <li> Effective Java 3rd Edition, Joshua Bloch - Exceptions - Item 76 : Strive for failure atomicity </li>
+</ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1165.json b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1165.json
index 2c2e1b35e07..5f45a60c1a5 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1165.json
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1165.json
@@ -1,5 +1,5 @@
 {
-  "title": "Exception classes should be immutable",
+  "title": "Exception classes should have final fields",
   "type": "CODE_SMELL",
   "status": "ready",
   "remediation": {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1171.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1171.html
index 92f440359f0..e8bdfdf2cd7 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1171.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1171.html
@@ -1,41 +1,62 @@
 <h2>Why is this an issue?</h2>
-<p>Non-static initializers are rarely used, and can be confusing for most developers because they only run when new class instances are created. When
-possible, non-static initializers should be refactored into standard constructors or field initializers.</p>
-<h3>Noncompliant code example</h3>
-<pre>
+<p>Non-static initializers, also known as instance initializers, are blocks of code within a class that is executed when an instance of the class is
+created. They are executed when an object of the class is created just before the constructor is called. Non-static initializers are useful when you
+want to perform some common initialization logic for all objects of a class. They allow you to initialize instance variables in a concise and
+centralized manner, without having to repeat the same initialization code in each constructor.</p>
+<p>While non-static initializers may have some limited use cases, they are rarely used and can be confusing for most developers because they only run
+when new class instances are created.</p>
+<h2>How to fix it</h2>
+<p>Non-static initializers should be refactored into standard constructors or field initializers when possible.</p>
+<p>In most cases, the use of constructors, overloaded constructors, or factory methods is preferable for initializing instance variables. These
+approaches provide more explicit and controlled initialization, separate concerns, allow for better error handling, and make the code easier to
+understand and maintain.</p>
+<h3>Code examples</h3>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="1" data-diff-type="noncompliant">
 class MyClass {
   private static final Map&lt;String, String&gt; MY_MAP = new HashMap&lt;String, String&gt;() {
-
-    // Noncompliant - HashMap should be extended only to add behavior, not for initialization
     {
       put("a", "b");
     }
+  }; // Noncompliant - HashMap should be extended only to add behavior, not for initialization
+}
+</pre>
+<h4>Compliant solution</h4>
+<p>Using static initialization block:</p>
+<pre data-diff-id="1" data-diff-type="compliant">
+class MyClass {
+  private static final Map&lt;String, String&gt; MY_MAP = new HashMap&lt;&gt;();
 
-  };
+  static {
+    MY_MAP.put("a", "b");  // Compliant
+  }
 }
 </pre>
-<h3>Compliant solution</h3>
+<p>or using constructor:</p>
 <pre>
 class MyClass {
-  private static final Map&lt;String, String&gt; MY_MAP = new HashMap&lt;String, String&gt;();
+  private static final Map&lt;String, String&gt; MY_MAP = new HashMap&lt;&gt;();
 
-  static {
-    MY_MAP.put("a", "b");
+  public MyClass() {
+    MY_MAP.put("a", "b");  // Compliant
   }
 }
 </pre>
 <p>or using Java 9 <code>Map.of</code>:</p>
 <pre>
 class MyClass {
-  // Compliant
-  private static final Map&lt;String, String&gt; MY_MAP = java.util.Map.of("a", "b");
+  private static final Map&lt;String, String&gt; MY_MAP = java.util.Map.of("a", "b");   // Compliant
 }
 </pre>
-<p>or using Guava:</p>
+<p>or using Guava <code>ImmutableMap.of</code>:</p>
 <pre>
 class MyClass {
-  // Compliant
-  private static final Map&lt;String, String&gt; MY_MAP = ImmutableMap.of("a", "b");
+  private static final Map&lt;String, String&gt; MY_MAP = com.google.common.collect.ImmutableMap.of("a", "b");   // Compliant
 }
 </pre>
+<h2>Resources</h2>
+<h3>Articles &amp; blog posts</h3>
+<ul>
+  <li> <a href="https://www.baeldung.com/java-static-instance-initializer-blocks">Static vs. Instance Initializer Block in Java</a> </li>
+</ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1182.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1182.html
index a04f9593827..9f5b95ff66d 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1182.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1182.html
@@ -1,6 +1,6 @@
 <h2>Why is this an issue?</h2>
 <p><code>Cloneable</code> is the marker <code>Interface</code> that indicates that <code>clone()</code> may be called on an object. Overriding
-<code>clone()</code> without implementing <code>Cloneable</code> can be useful if you want to control how subclasses clone themselves, but otherwise,
+<code>clone()</code> without implementing <code>Cloneable</code> can be helpful if you want to control how subclasses clone themselves, but otherwise,
 it’s probably a mistake.</p>
 <p>The usual convention for <code>Object.clone()</code> according to Oracle’s Javadoc is:</p>
 <ol>
@@ -12,13 +12,17 @@ <h2>Why is this an issue?</h2>
 <ol>
   <li> <code>super.clone()</code> returns a new object instance </li>
   <li> <code>super.clone()</code> returns an object of the same type as the one <code>clone()</code> was called on </li>
-  <li> <code>Object.clone()</code> performs a shallow copy of the object’s state </li>
+  <li> <code>Object.clone()</code> performs a shallow copy of the object’s state. </li>
 </ol>
-<h3>Noncompliant code example</h3>
-<pre>
-class BaseClass {  // Noncompliant; should implement Cloneable
+<h2>How to fix it</h2>
+<p>Ensure that the <code>clone()</code> method calls <code>super.clone()</code> and implement <code>Cloneable</code> in the class or remove the clone
+method.</p>
+<h3>Code examples</h3>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="1" data-diff-type="noncompliant">
+class BaseClass {  // Noncompliant - should implement Cloneable
   @Override
-  public Object clone() throws CloneNotSupportedException {    // Noncompliant; should return the super.clone() instance
+  public Object clone() throws CloneNotSupportedException {    // Noncompliant - should return the super.clone() instance
     return new BaseClass();
   }
 }
@@ -38,8 +42,8 @@ <h3>Noncompliant code example</h3>
   }
 }
 </pre>
-<h3>Compliant solution</h3>
-<pre>
+<h4>Compliant solution</h4>
+<pre data-diff-id="1" data-diff-type="compliant">
 class BaseClass implements Cloneable {
   @Override
   public Object clone() throws CloneNotSupportedException {    // Compliant
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1190.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1190.html
index 1c910712436..b28d78ec2b0 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1190.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1190.html
@@ -1,7 +1,8 @@
 <h2>Why is this an issue?</h2>
-<p>Through Java’s evolution keywords have been added. While code that uses those words as identifiers may be compilable under older versions of Java,
-it will not be under modern versions.</p>
-<p>Following keywords are marked as invalid identifiers</p>
+<p>Programming languages evolve over time, and new versions of Java introduce additional keywords. If future keywords are used in the current code, it
+can create compatibility issues when transitioning to newer versions of Java. The code may fail to compile or behave unexpectedly due to conflicts
+with newly introduced keywords.</p>
+<p>The following keywords are marked as invalid identifiers:</p>
 <table>
   <colgroup>
     <col style="width: 50%;">
@@ -10,7 +11,7 @@ <h2>Why is this an issue?</h2>
   <thead>
     <tr>
       <th>Keyword</th>
-      <th>Added</th>
+      <th>Added in version</th>
     </tr>
   </thead>
   <tbody>
@@ -26,17 +27,26 @@ <h2>Why is this an issue?</h2>
 </table>
 <p><code>assert</code> and <code>strictfp</code> are another example of valid identifiers which became keywords in later versions, but are not
 supported by this rule.</p>
-<h3>Noncompliant code example</h3>
-<pre>
-public void doSomething() {
-  int enum = 42;            // Noncompliant
-  String _ = "";   // Noncompliant
+<h2>How to fix it</h2>
+<p>Rename the identifiers that use Java keywords.</p>
+<h3>Code examples</h3>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="1" data-diff-type="noncompliant">
+public class MyClass {
+    int enum = 42;            // Noncompliant
+    String _ = "";            // Noncompliant
 }
 </pre>
-<h3>Compliant solution</h3>
-<pre>
-public void doSomething() {
-  int magic = 42;
+<h4>Compliant solution</h4>
+<pre data-diff-id="1" data-diff-type="compliant">
+public class MyClass {
+    int magic = 42;           // Noncompliant
+    String s = "";            // Noncompliant
 }
 </pre>
+<h2>Resources</h2>
+<h3>Documentation</h3>
+<ul>
+  <li> <a href="https://docs.oracle.com/javase/tutorial/java/nutsandbolts/_keywords.html">Oracle - Java Language Keywords</a> </li>
+</ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1191.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1191.html
index 713e3f967db..263be47b6de 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1191.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1191.html
@@ -1,10 +1,19 @@
 <h2>Why is this an issue?</h2>
-<p>Classes in the <code>sun.*</code> packages are considered implementation details, and are not part of the Java API.</p>
-<p>They can cause problems when moving to new versions of Java because there is no backwards compatibility guarantee. Similarly, they can cause
-problems when moving to a different Java vendor, such as OpenJDK.</p>
-<p>Such classes are almost always wrapped by Java API classes that should be used instead.</p>
+<p>The classes in the <code>sun.*</code> packages are not part of the official Java API and are not intended for public use. They are internal
+implementation details specific to the Oracle JDK (Java Development Kit). Therefore, their availability, behavior, or compatibility is not guaranteed
+across different Java implementations or versions.</p>
+<p>Since these classes are not part of the official Java API, they usually lack proper documentation and support. Finding comprehensive and up-to-date
+information about their usage, functionality, and potential limitations can be challenging. This lack of documentation can make it difficult to
+understand how to use these classes correctly.</p>
+<p>Classes in the <code>sun.*</code> packages are often platform-dependent and can vary between different operating systems or Java Virtual Machine
+(JVM) implementations. Relying on these classes may lead to code that works on one platform but fails on others, limiting your code’s portability and
+cross-platform compatibility.</p>
 <h3>Noncompliant code example</h3>
 <pre>
 import sun.misc.BASE64Encoder; // Noncompliant
 </pre>
+<h2>Documentation</h2>
+<ul>
+  <li> <a href="https://www.oracle.com/java/technologies/faq-sun-packages.html">Sun Packages</a> </li>
+</ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1193.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1193.html
index 295e09a4183..5fef0d56d6b 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1193.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1193.html
@@ -1,7 +1,15 @@
 <h2>Why is this an issue?</h2>
-<p>Multiple catch blocks of the appropriate type should be used instead of catching a general exception, and then testing on the type.</p>
-<h3>Noncompliant code example</h3>
-<pre>
+<p>A <code>try-catch</code> block is used to handle exceptions or errors that may occur during the execution of a block of code. It allows you to
+catch and handle exceptions gracefully, preventing your program from terminating abruptly.</p>
+<p>The code that may throw an exception is enclosed within the <code>try</code> block, while each <code>catch</code> block specifies the type of
+exception it can handle. The corresponding catch block is executed if the exception matches the type specified in any catch block. It is unnecessary
+to manually check the types using <code>instanceof</code> because Java automatically matches the exception type to the appropriate catch block based
+on the declared exception type in the catch clauses.</p>
+<h2>How to fix it</h2>
+<p>Replace <code>if</code> statements that check the exception type using <code>instaceof</code> with corresponding <code>catch</code> blocks.</p>
+<h3>Code examples</h3>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="1" data-diff-type="noncompliant">
 try {
   /* ... */
 } catch (Exception e) {
@@ -9,8 +17,8 @@ <h3>Noncompliant code example</h3>
   if(e instanceof NullPointerException{ /* ... */ }  // Noncompliant
 }
 </pre>
-<h3>Compliant solution</h3>
-<pre>
+<h4>Compliant solution</h4>
+<pre data-diff-id="1" data-diff-type="compliant">
 try {
   /* ... */
 } catch (IOException e) { /* ... */ }                // Compliant
@@ -20,5 +28,6 @@ <h2>Resources</h2>
 <ul>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/display/java/ERR51-J.+Prefer+user-defined+exceptions+over+more+general+exception+types">CERT,
   ERR51-J.</a> - Prefer user-defined exceptions over more general exception types </li>
+  <li> <a href="https://docs.oracle.com/javase/tutorial/essential/exceptions/catch.html">Oracle - Exceptions</a> </li>
 </ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1195.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1195.html
index 9b7ba0e90da..c3ada4b74e2 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1195.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1195.html
@@ -1,21 +1,25 @@
 <h2>Why is this an issue?</h2>
-<p>According to the Java Language Specification:</p>
-<blockquote>
-  <p>For compatibility with older versions of the Java SE platform,</p>
-  <p>the declaration of a method that returns an array is allowed to place (some or all of) the empty bracket pairs that form the declaration of the
-  array type after the formal parameter list.</p>
-  <p>This obsolescent syntax should not be used in new code.</p>
-</blockquote>
+<p>Placing the array designators <code>[]</code> after the type helps maintain backward compatibility with older versions of the Java SE platform.
+This syntax contributes to better readability as it becomes easier to distinguish between array types and non-array types. It helps convey the
+intention of the method to both the developer implementing it and the developer using it.</p>
 <h3>Noncompliant code example</h3>
-<pre>
-public int getVector()[] { /* ... */ }    // Noncompliant
-
-public int[] getMatrix()[] { /* ... */ }  // Noncompliant
+<pre data-diff-id="1" data-diff-type="noncompliant">
+public class Cube {
+    private int magicNumbers[] = { 42 };      // Noncompliant
+    public int getVector()[] { /* ... */ }    // Noncompliant
+    public int[] getMatrix()[] { /* ... */ }  // Noncompliant
+}
 </pre>
 <h3>Compliant solution</h3>
-<pre>
-public int[] getVector() { /* ... */ }
-
-public int[][] getMatrix() { /* ... */ }
+<pre data-diff-id="1" data-diff-type="compliant">
+public class Cube {
+    private int[] magicNumbers = { 42 };      // Compliant
+    public int[] getVector() { /* ... */ }    // Compliant
+    public int[][] getMatrix() { /* ... */ }  // Compliant
+}
 </pre>
+<h2>Documentation</h2>
+<ul>
+  <li> <a href="https://docs.oracle.com/javase/specs/jls/se20/html/jls-10.html">Oracle Java Language Specification</a> - Arrays </li>
+</ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1201.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1201.html
index da0e38cebbe..23a85695357 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1201.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1201.html
@@ -1,9 +1,16 @@
 <h2>Why is this an issue?</h2>
-<p>"equals" as a method name should be used exclusively to override <code>Object.equals(Object)</code> to prevent any confusion.</p>
-<p>It is tempting to overload the method to take a specific class instead of <code>Object</code> as parameter, to save the class comparison check.
-However, this will not work as expected when that is the only override.</p>
-<h3>Noncompliant code example</h3>
-<pre>
+<p>In Java, the <code>Object.equals()</code> method is used for object comparison, and it is typically overridden in classes to provide a custom
+equality check based on your criteria for equality.</p>
+<p>The default implementation of <code>equals()</code> provided by the <code>Object</code> class compares the memory references of the two objects,
+that means it checks if the objects are actually the same instance in memory.</p>
+<p>The "equals" as a method name should be used exclusively to override <code>Object.equals(Object)</code> to prevent confusion.</p>
+<p>It is important to note that when you override <code>equals()</code>, you should also override the <code>hashCode()</code> method to maintain the
+contract between <code>equals()</code> and <code>hashCode()</code>.</p>
+<h2>How to fix it</h2>
+<p>Either override <code>Object.equals(Object)</code> or rename the method.</p>
+<h3>Code examples</h3>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="1" data-diff-type="noncompliant">
 class MyClass {
   private int foo = 1;
 
@@ -17,27 +24,18 @@ <h3>Noncompliant code example</h3>
     System.out.println(o1.equals(o2));  // Prints "false" because o2 an Object not a MyClass
   }
 }
-
-class MyClass2 {
-  public boolean equals(MyClass2 o) {  // Ignored; `boolean equals(Object)` also present
-    //..
-  }
-
-  public boolean equals(Object o) {
-    //...
-  }
-}
 </pre>
-<h3>Compliant solution</h3>
-<pre>
+<h4>Compliant solution</h4>
+<pre data-diff-id="1" data-diff-type="compliant">
 class MyClass {
   private int foo = 1;
 
   @Override
-  public boolean equals(Object o) {
+  public boolean equals(Object o) {  // Compliant
     if (this == o) {
         return true;
     }
+
     if (o == null || getClass() != o.getClass()) {
       return false;
     }
@@ -45,18 +43,12 @@ <h3>Compliant solution</h3>
     MyClass other = (MyClass)o;
     return this.foo == other.foo;
   }
-
-  /* ... */
-}
-
-class MyClass2 {
-  public boolean equals(MyClass2 o) {
-    //..
-  }
-
-  public boolean equals(Object o) {
-    //...
-  }
 }
 </pre>
+<h2>Resources</h2>
+<h3>Documentation</h3>
+<ul>
+  <li> <a href="https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/Object.html#equals(java.lang.Object)">Oracle SDK -
+  Object.equals(Object)</a> </li>
+</ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S121.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S121.html
index 4b0f6a52775..abb12a50290 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S121.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S121.html
@@ -1,22 +1,26 @@
+<p>Control structures are code statements that impact the program’s control flow (e.g., if statements, for loops, etc.)</p>
 <h2>Why is this an issue?</h2>
-<p>While not technically incorrect, the omission of curly braces can be misleading, and may lead to the introduction of errors during maintenance.</p>
-<h3>Noncompliant code example</h3>
+<p>While not technically incorrect, the omission of curly braces can be misleading and may lead to the introduction of errors during maintenance.</p>
+<p>In the following example, the two calls seem to be attached to the <code>if</code> statement, but only the first one is, and
+<code>checkSomething</code> will always be executed:</p>
 <pre>
 if (condition)  // Noncompliant
   executeSomething();
+  checkSomething();
 </pre>
-<h3>Compliant solution</h3>
+<p>Adding curly braces improves the code readability and its robustness:</p>
 <pre>
 if (condition) {
   executeSomething();
+  checkSomething();
 }
 </pre>
+<p>The rule raises an issue when a control structure has no curly braces.</p>
 <h3>Exceptions</h3>
-<p>When the body of an <code>if</code> statement is a single <code>return</code>, <code>break</code> or <code>continue</code> and is on the same
-line.</p>
+<p>The rule doesn’t raise an issue when the body of an <code>if</code> statement is a single <code>return</code>, <code>break</code>, or
+<code>continue</code> and is on the same line.</p>
 <h2>Resources</h2>
 <ul>
-  <li> <a href="https://wiki.sei.cmu.edu/confluence/x/g9YxBQ">CERT, EXP19-C.</a> - Use braces for the body of an if, for, or while statement </li>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/MzZGBQ">CERT, EXP52-J.</a> - Use braces for the body of an if, for, or while statement </li>
 </ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S121.json b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S121.json
index 66b81fa346e..61bc82b6518 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S121.json
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S121.json
@@ -17,7 +17,6 @@
   "quickfix": "unknown",
   "securityStandards": {
     "CERT": [
-      "EXP19-C.",
       "EXP52-J."
     ]
   }
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1214.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1214.html
index 74afe87e6ee..4be16be71a6 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1214.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1214.html
@@ -1,34 +1,83 @@
+<p>This rule raises an issue when an interface consists only of constant definitions without other members.</p>
 <h2>Why is this an issue?</h2>
-<p>According to Joshua Bloch, author of "Effective Java":</p>
-<blockquote>
-  <p>The constant interface pattern is a poor use of interfaces.</p>
-  <p>That a class uses some constants internally is an implementation detail.</p>
-  <p>Implementing a constant interface causes this implementation detail to leak into the class’s exported API. It is of no consequence to the users
-  of a class that the class implements a constant interface. In fact, it may even confuse them. Worse, it represents a commitment: if in a future
-  release the class is modified so that it no longer needs to use the constants, it still must implement the interface to ensure binary compatibility.
-  If a nonfinal class implements a constant interface,</p>
-  <p>all of its subclasses will have their namespaces polluted by the constants in the interface.</p>
-</blockquote>
-<p>This rule raises an issue when an interface consists solely of fields, without any other members.</p>
-<h3>Noncompliant code example</h3>
-<pre>
-interface Status {                      // Noncompliant
-   int OPEN = 1;
-   int CLOSED = 2;
+<p>An interface that consists solely of constant definitions is a bad practice. The purpose of interfaces is to provide an API, not implementation
+details. That is, they should provide functions in the first place and constants only to assist these functions, for example, as possible
+arguments.</p>
+<p>If an interface contains constants only, move them either to somewhere else, or replace the interface with an <em>Enum</em> or a final class with a
+private constructor.</p>
+<h2>How to fix it</h2>
+<p>If the concrete value of the constants is not essential, and they serve as mere identifiers, replace the interface with an <code>enum</code> like
+in the following example:</p>
+<pre data-diff-id="1" data-diff-type="noncompliant">
+public interface Status { // Noncompliant, enum should be used
+  int OPEN = 1;
+  int CLOSED = 2;
 }
 </pre>
-<h3>Compliant solution</h3>
-<pre>
-public enum Status {                    // Compliant
+<pre data-diff-id="1" data-diff-type="compliant">
+public enum Status {      // Compliant
   OPEN,
-  CLOSED;
+  CLOSED
 }
 </pre>
-<p>or</p>
-<pre>
-public final class Status {             // Compliant
-   public static final int OPEN = 1;
-   public static final int CLOSED = 2;
+<p>In some cases, enums are not a suitable option because the concrete constant value is important. Then you should check whether it is appropriate to
+move them to a specific existing class, for example, if that class is the primary user of the constants:</p>
+<pre data-diff-id="1" data-diff-type="noncompliant">
+interface AuxiliaryConstants { // Noncompliant, implementation detail of WordPacker
+  int BITS_PER_WORD = 16;
+  int WORD_MASK = (1 &lt;&lt; BITS_PER_WORD) - 1;
+  int HI_WORD_BK_MASK = ~(WORD_MASK &lt;&lt; BITS_PER_WORD);
+}
+
+class WordPacker {
+  public static int getHiWord(int value) {
+    return (value &gt;&gt;&gt; AuxiliaryConstants.BITS_PER_WORD);
+  }
+
+  public static int setHiWord(int value, int wordValue) {
+    return (value &amp; AuxiliaryConstants.HI_WORD_BK_MASK) |
+      (wordValue &lt;&lt; AuxiliaryConstants.BITS_PER_WORD);
+  }
+}
+</pre>
+<pre data-diff-id="1" data-diff-type="compliant">
+class WordPacker { // Compliant
+  private static final int BITS_PER_WORD = 16;
+  private static final int WORD_MASK = (1 &lt;&lt; BITS_PER_WORD) - 1;
+  private static final int HI_WORD_BK_MASK = ~(WORD_MASK &lt;&lt; BITS_PER_WORD);
+
+  public static int getHiWord(int value) {
+      return (value &gt;&gt;&gt; BITS_PER_WORD);
+  }
+
+  public static int setHiWord(int value, int wordValue) {
+    return (value &amp; HI_WORD_BK_MASK) | (wordValue &lt;&lt; BITS_PER_WORD);
+  }
+}
+</pre>
+<p>If this is not the case and several classes are using the constants equally, you should use a final class with a private constructor. Unlike
+interfaces, they can neither be inherited from nor instantiated.</p>
+<pre data-diff-id="3" data-diff-type="noncompliant">
+public interface ColorTheme { // Noncomplient, final class should be used
+  int COLOR_ERROR = 0xff0000;   // red
+  int COLOR_WARNING = 0xffff00; // yellow
+  int COLOR_OK = 0x00cf00;      // green
+}
+</pre>
+<pre data-diff-id="3" data-diff-type="compliant">
+public final class ColorTheme { // Compliant
+  public static final int COLOR_ERROR = 0xff0000;   // red
+  public static final int COLOR_WARNING = 0xffff00; // yellow
+  public static final int COLOR_OK = 0x00cf00;      // green
+
+  private ColorTheme() {}
 }
 </pre>
+<h2>Resources</h2>
+<h3>Articles &amp; blog posts</h3>
+<ul>
+  <li> <a href="https://dzone.com/articles/reasons-why-the-constant-interface-pattern-is-disc">Mohammad Nadeem - Why the Constant Interface Pattern
+  Should Be Discouraged</a> </li>
+  <li> Joshua Bloch - Effective Java, ISBN 9780134686097 </li>
+</ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1214.json b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1214.json
index 9d3293c1455..77e569468f9 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1214.json
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1214.json
@@ -1,5 +1,5 @@
 {
-  "title": "Constants should not be defined in interfaces",
+  "title": "Interfaces should not solely consist of constants",
   "type": "CODE_SMELL",
   "status": "ready",
   "remediation": {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1217.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1217.html
index e26c0abe878..fdce5468abb 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1217.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1217.html
@@ -1,20 +1,92 @@
+<p>This rule raises an issue when <code>Thread.run()</code> is called instead of <code>Thread.start()</code>.</p>
 <h2>Why is this an issue?</h2>
-<p>The purpose of the <code>Thread.run()</code> method is to execute code in a separate, dedicated thread. Calling this method directly doesn’t make
-sense because it causes its code to be executed in the current thread.</p>
-<p>To get the expected behavior, call the <code>Thread.start()</code> method instead.</p>
-<h3>Noncompliant code example</h3>
-<pre>
+<p>The likely intention of a user calling <code>Thread.run()</code> is to start the execution of code within a new thread. This, however, is not what
+happens when this method is called.</p>
+<p>The purpose of <code>Thread.run()</code> is to provide a method that users can overwrite to specify the code to be executed. The actual thread is
+then started by calling <code>Thread.start()</code>. When <code>Thread.run()</code> is called directly, it will be executed as a regular method within
+the current thread.</p>
+<h2>How to fix it</h2>
+<p>If you intend to execute the contents of the <code>Thread.run()</code> method within a new thread, call <code>Thread.start()</code> instead.</p>
+<p>If your intention is only to have a container for a method but execute this method within the current thread, do not use <code>Thread</code> but
+<code>Runnable</code> or another functional interface.</p>
+<h3>Code examples</h3>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="1" data-diff-type="noncompliant">
 Thread myThread = new Thread(runnable);
-myThread.run(); // Noncompliant
+myThread.run(); // Noncompliant, does not start a thread
 </pre>
-<h3>Compliant solution</h3>
-<pre>
+<h4>Compliant solution</h4>
+<pre data-diff-id="1" data-diff-type="compliant">
 Thread myThread = new Thread(runnable);
 myThread.start(); // Compliant
 </pre>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="2" data-diff-type="noncompliant">
+class ComputePrimesThread extends Thread {
+    @Override
+    public void run() {
+        // ...
+    }
+}
+new ComputePrimesThread().run(); // Noncompliant, does not start a thread
+</pre>
+<h4>Compliant solution</h4>
+<pre data-diff-id="2" data-diff-type="compliant">
+class ComputePrimesThread extends Thread {
+    @Override
+    public void run() {
+        // ...
+    }
+}
+new ComputePrimesThread().start(); // Compliant
+</pre>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="3" data-diff-type="noncompliant">
+class Button {
+
+    private Thread onClick;
+
+    Button(Thread onClick) {
+        this.onClick = onClick;
+    }
+
+    private void clicked() {
+        if (onClick != null) onClick.run(); // Noncompliant, use functional interface
+    }
+}
+
+new Button(new Thread() {
+    @Override public void run() {
+        System.out.println("clicked!");
+    }
+});
+</pre>
+<h4>Compliant solution</h4>
+<pre data-diff-id="3" data-diff-type="compliant">
+class Button {
+
+    private Runnable onClick;
+
+    Button(Runnable onClick) {
+        this.onClick = onClick;
+    }
+
+    private void clicked() {
+        if (onClick != null) onClick.run(); // compliant
+    }
+}
+
+new Button(() -&gt; System.out.println("clicked!"));
+</pre>
 <h2>Resources</h2>
+<h3>Documentation</h3>
+<ul>
+  <li> <a href="https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.html#start--">Java™ Platform, Standard Edition 8 API Specification -
+  Thread.start()</a> </li>
+</ul>
+<h3>Articles &amp; blog posts</h3>
 <ul>
-  <li> <a href="https://cwe.mitre.org/data/definitions/572">MITRE, CWE-572</a> - Call to Thread run() instead of start() </li>
-  <li> <a href="https://wiki.sei.cmu.edu/confluence/x/6DdGBQ">CERT THI00-J.</a> - Do not invoke Thread.run() </li>
+  <li> <a href="https://www.javatpoint.com/what-if-we-call-java-run-method-directly">JavaTPoint - What if we call Java run() method directly instead
+  start() method?</a> </li>
 </ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S122.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S122.html
index 58809c7594b..ab8ed84bb10 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S122.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S122.html
@@ -1,12 +1,11 @@
 <h2>Why is this an issue?</h2>
-<p>For better readability, do not put more than one statement on a single line.</p>
-<h3>Noncompliant code example</h3>
+<p>Putting multiple statements on a single line lowers the code readability and makes debugging the code more complex.</p>
 <pre>
-if(someCondition) doSomething();
+if (someCondition) doSomething(); // Noncompliant
 </pre>
-<h3>Compliant solution</h3>
+<p>Write one statement per line to improve readability.</p>
 <pre>
-if(someCondition) {
+if (someCondition) {
   doSomething();
 }
 </pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1220.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1220.html
index b718b8eb09a..32163dae33a 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1220.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1220.html
@@ -1,18 +1,34 @@
 <h2>Why is this an issue?</h2>
-<p>According to the Java Language Specification:</p>
-<blockquote>
-  <p>Unnamed packages are provided by the Java platform principally for convenience when developing small or temporary applications or when just
-  beginning development.</p>
-</blockquote>
-<p>To enforce this best practice, classes located in default package can no longer be accessed from named ones since Java 1.4.</p>
-<h3>Noncompliant code example</h3>
-<pre>
-public class MyClass { /* ... */ }
+<p>Java packages serve two purposes:</p>
+<ol>
+  <li> Structure — Packages give a structure to the set of classes of your project. It is a bad practice to put all classes flat into the source
+  directory of a project without a package structure. A structure helps to mentally break down a project into smaller parts, simplifying readers'
+  understanding of how components are connected and how they interact. </li>
+  <li> Avoiding name clashes — a class part of the <em>default package</em> if no explicit package name is specified. This can easily cause name
+  collisions when other projects define a class of the same name. </li>
+</ol>
+<p>When no package is explicitly specified for the classes in your project, this makes the project harder to understand and may cause name collisions
+with other projects. Also, classes located in the default package not be accessed from classes within named packages since Java 1.4.</p>
+<h2>How to fix it</h2>
+<p>Move your class to a package directory and explicitly state the package’s name at the top of the class. If your project does not have a package
+structure, think of a structure that fits your needs. The package names should be unique to your project. You can find some best practices when
+choosing package names in the Ressources section below.</p>
+<h3>Code examples</h3>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="1" data-diff-type="noncompliant">
+public class MyClass { /* ... */ } // Noncompliant, no package spacified
 </pre>
-<h3>Compliant solution</h3>
-<pre>
-package org.example;
+<h4>Compliant solution</h4>
+<pre data-diff-id="1" data-diff-type="compliant">
+package org.example; // Compliant
 
 public class MyClass{ /* ... */ }
 </pre>
+<h2>Resources</h2>
+<h3>Articles &amp; blog posts</h3>
+<ul>
+  <li> <a href="https://www.baeldung.com/java-packages">Baeldung - Guide to Java Packages</a> </li>
+  <li> <a
+  href="https://www.tutorialspoint.com/what-are-the-best-practices-to-keep-in-mind-while-using-packages-in-java#:~:text=Naming%20conventions%20and%20best%20practices%20for%20packages">tutorialspoint - What are the best practices to keep in mind while using packages in Java?</a> </li>
+</ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1221.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1221.html
index 542aea48df3..a94766e7b18 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1221.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1221.html
@@ -1,29 +1,31 @@
 <h2>Why is this an issue?</h2>
-<p>Naming a method <code>tostring</code>, <code>hashcode</code> or <code>equal</code> is either:</p>
-<ul>
-  <li> A bug in the form of a typo. Overriding <code>toString</code>, <code>Object.hashCode()</code> (note the camelCasing) or
-  <code>Object.equals</code> (note the 's' on the end) was meant, and the application does not behave as expected. </li>
-  <li> Done on purpose. The name however will confuse every other developer, who may not notice the naming difference, or who will think it is a bug.
-  </li>
-</ul>
-<p>In both cases, the method should be renamed.</p>
-<h3>Noncompliant code example</h3>
+<p>Due to the similar name with the methods <code>Object.toString</code>, <code>Object.hashCode</code> and <code>Object.equals</code>, there is a
+significant likelihood that a developer intended to override one of these methods but made a spelling error.</p>
+<p>Even if no such error exists and the naming was done on purpose, these method names can be misleading. Readers might not notice the difference, or
+if they do, they may falsely assume that the developer made a mistake.</p>
+<h2>How to fix it</h2>
+<p>If you intended to override one of the methods <code>Object.toString</code>, <code>Object.hashCode</code>, or <code>Object.equals</code>, correct
+the spelling. Also, you should add the <code>@Override</code> modifier, which causes a compiler error message in case the annotated method does not
+override anything.</p>
+<p>If the naming was done on purpose, you should rename the methods to be more distinctive.</p>
+<h3>Code examples</h3>
+<h4>Noncompliant code example</h4>
 <pre>
-public int hashcode() { /* ... */ }  // Noncompliant
+public int hashcode() { /* ... */ }             // Noncompliant
 
-public String tostring() { /* ... */ } // Noncompliant
+public String tostring() { /* ... */ }          // Noncompliant
 
 public boolean equal(Object obj) { /* ... */ }  // Noncompliant
 </pre>
-<h3>Compliant solution</h3>
+<h4>Compliant solution</h4>
 <pre>
 @Override
-public int hashCode() { /* ... */ }
+public int hashCode() { /* ... */ }             // Compliant
 
 @Override
-public String toString() { /* ... */ }
+public String toString() { /* ... */ }          // Compliant
 
 @Override
-public boolean equals(Object obj) { /* ... */ }
+public boolean equals(Object obj) { /* ... */ } // Compliant
 </pre>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1317.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1317.html
index 3f75d6dab1c..6b1b54f6574 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1317.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1317.html
@@ -1,13 +1,42 @@
+<p>This rule raises an issue when the <code>StringBuilder</code> or <code>StringBuffer</code> constructor is called with a single character as an
+argument.</p>
 <h2>Why is this an issue?</h2>
-<p>Instantiating a <code>StringBuilder</code> or a <code>StringBuffer</code> with a character is misleading because most Java developers would expect
-the character to be the initial value of the <code>StringBuffer</code>.</p>
-<p>What actually happens is that the int representation of the character is used to determine the initial size of the <code>StringBuffer</code>.</p>
-<h3>Noncompliant code example</h3>
-<pre>
-StringBuffer foo = new StringBuffer('x');   //equivalent to StringBuffer foo = new StringBuffer(120);
+<p>When a developer uses the <code>StringBuilder</code> or <code>StringBuffer</code> constructor with a single character as an argument, the likely
+intention is to create an instance with the character as the initial string value.</p>
+<p>However, this is not what happens because of the absence of a dedicated <code>StringBuilder(char)</code> or <code>StringBuffer(char)</code>
+constructor. Instead, <code>StringBuilder(int)</code> or <code>StringBuffer(int)</code> is invoked, which results in an instance with the provided
+<code>int</code> value as the initial capacity of the <code>StringBuilder</code> or <code>StringBuffer</code>.</p>
+<p>The reason behind this behavior lies in the automatic widening of <code>char</code> expressions to <code>int</code> when required. Consequently,
+the UTF-16 code point value of the character (for example, <code>65</code> for the character <code>'A'</code>) is interpreted as an <code>int</code>
+to specify the initial capacity.</p>
+<h2>How to fix it</h2>
+<p>If the argument is a <code>char</code> literal, use a string literal instead:</p>
+<pre data-diff-id="1" data-diff-type="noncompliant">
+StringBuffer foo = new StringBuffer('x'); // Noncompliant, replace with String
 </pre>
-<h3>Compliant solution</h3>
-<pre>
-StringBuffer foo = new StringBuffer("x");
+<pre data-diff-id="1" data-diff-type="compliant">
+StringBuffer foo = new StringBuffer("x"); // Compliant
 </pre>
+<p>If the argument is it is a non-literal <code>char</code> expression, convert it to <code>String</code> using the <code>String.valueOf()</code>
+method:</p>
+<pre data-diff-id="2" data-diff-type="noncompliant">
+StringBuffer foo(char firstChar) {
+  return new StringBuffer(firstChar);                 // Noncompliant
+}
+</pre>
+<pre data-diff-id="2" data-diff-type="compliant">
+StringBuffer foo(char firstChar) {
+  return new StringBuffer(String.valueOf(firstChar)); // Compliant
+}
+</pre>
+<h2>Resources</h2>
+<h3>Documentation</h3>
+<ul>
+  <li> <a href="https://docs.oracle.com/javase/specs/jls/se10/html/jls-5.html#jls-5.1.2">Oracle - Java Language Specification, section 5.1.2. Widening
+  Primitive Conversion</a> </li>
+</ul>
+<h3>Articles &amp; blog posts</h3>
+<ul>
+  <li> <a href="https://www.w3schools.com/java/java_type_casting.asp">W3schools - Java Type Casting</a> </li>
+</ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1319.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1319.html
index 73130e1a7b4..1369beee0c8 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1319.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1319.html
@@ -1,29 +1,39 @@
-<h2>Why is this an issue?</h2>
-<p>The purpose of the Java Collections API is to provide a well defined hierarchy of interfaces in order to hide implementation details.</p>
-<p>Implementing classes must be used to instantiate new collections, but the result of an instantiation should ideally be stored in a variable whose
-type is a Java Collection interface.</p>
-<p>This rule raises an issue when an implementation class:</p>
+<p>This rule raises an issue when a collection implementation class from <code>java.util.*</code> is used:</p>
 <ul>
-  <li> is returned from a <code>public</code> method. </li>
-  <li> is accepted as an argument to a <code>public</code> method. </li>
-  <li> is exposed as a <code>public</code> member. </li>
+  <li> as a return type of a <code>public</code> method. </li>
+  <li> as an argument type of a <code>public</code> method. </li>
+  <li> as the type of a <code>public</code> field. </li>
 </ul>
-<h3>Noncompliant code example</h3>
-<pre>
+<h2>Why is this an issue?</h2>
+<p>The Java Collections API offers a well-structured hierarchy of interfaces designed to hide collection implementation details. For the various
+collection data structures like lists, sets, and maps, specific interfaces (<code>java.util.List</code>, <code>java.util.Set</code>,
+<code>java.util.Map</code>) cover the essential features.</p>
+<p>When passing collections as method parameters, return values, or when exposing fields, it is generally recommended to use these interfaces instead
+of the implementing classes. The implementing classes, such as <code>java.util.LinkedList</code>, <code>java.util.ArrayList</code>, and
+<code>java.util.HasMap</code>, should only be used for collection instantiation. They provide finer control over the performance characteristics of
+those structures, and developers choose them depending on their use case.</p>
+<p>For example, if fast random element access is essential, <code>java.util.ArrayList</code> should be instantiated. If inserting elements at a random
+position into a list is crucial, a <code>java.util.LinkedList</code> should be preferred. However, this is an implementation detail your API should
+not expose.</p>
+<h3>Code examples</h3>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="1" data-diff-type="noncompliant">
 public class Employees {
-  private HashSet&lt;Employee&gt; employees = new HashSet&lt;Employee&gt;();  // Noncompliant - "employees" should have type "Set" rather than "HashSet"
+  public final HashSet&lt;Employee&gt; employees   // Noncompliant, field type should be "Set"
+    = new HashSet&lt;Employee&gt;();
 
-  public HashSet&lt;Employee&gt; getEmployees() {                       // Noncompliant
+  public HashSet&lt;Employee&gt; getEmployees() {  // Noncompliant, return type should be "Set"
     return employees;
   }
 }
 </pre>
-<h3>Compliant solution</h3>
-<pre>
+<h4>Compliant solution</h4>
+<pre data-diff-id="1" data-diff-type="compliant">
 public class Employees {
-  private Set&lt;Employee&gt; employees = new HashSet&lt;Employee&gt;();      // Compliant
+  public final Set&lt;Employee&gt; employees       // Compliant
+    = new HashSet&lt;Employee&gt;();
 
-  public Set&lt;Employee&gt; getEmployees() {                           // Compliant
+  public Set&lt;Employee&gt; getEmployees() {      // Compliant
     return employees;
   }
 }
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1452.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1452.html
index 0a9122d37a2..4fd44d9ad9e 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1452.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1452.html
@@ -1,20 +1,52 @@
 <h2>Why is this an issue?</h2>
-<p>It is highly recommended <strong>not</strong> to use wildcard types as return types. Because the type inference rules are fairly complex it is
-unlikely the user of that API will know how to use it correctly.</p>
-<p>Let’s take the example of method returning a "List&lt;? extends Animal&gt;". Is it possible on this list to add a Dog, a Cat, …​ we simply don’t
-know. And neither does the compiler, which is why it will not allow such a direct use. The use of wildcard types should be limited to method
-parameters.</p>
-<p>This rule raises an issue when a method returns a wildcard type.</p>
-<h3>Noncompliant code example</h3>
-<pre>
-List&lt;? extends Animal&gt; getAnimals(){...}
+<p>A return type containing wildcards cannot be narrowed down in any context. This indicates that the developer’s intention was likely something
+else.</p>
+<p>The core problem lies in type variance. Expressions at an input position, such as arguments passed to a method, can have a more specific type than
+the type expected by the method, which is called <em>covariance</em>. Expressions at an output position, such as a variable that receives the return
+result from a method, can have a more general type than the method’s return type, which is called <em>contravariance</em>. This can be traced back to
+the Liskov substitution principle.</p>
+<p>In Java, type parameters of a generic type are invariant by default due to their potential occurrence in both input and output positions at the
+same time. A classic example of this is the methods <code>T get()</code> (output position) and <code>add(T element)</code> (input position) in
+interface <code>java.util.List</code>. We could construct cases with invalid typing in <code>List</code> if <code>T</code> were not invariant.</p>
+<p>Wildcards can be employed to achieve covariance or contravariance in situations where the type parameter appears in one position only:</p>
+<ul>
+  <li> <code>&lt;? extends Foo&gt;</code> for covariance (input positions) </li>
+  <li> <code>&lt;? super Foo&gt;</code> for contravariance (output positions) </li>
+</ul>
+<p>However, covariance is ineffective for the return type of a method since it is not an input position. Making it contravariant also has no effect
+since it is the receiver of the return value which must be contravariant (use-site variance in Java). Consequently, a return type containing wildcards
+is generally a mistake.</p>
+<h2>How to fix it</h2>
+<p>The solution to this problem depends on the original intention of the developer. Given the examples:</p>
+<pre data-diff-id="1" data-diff-type="noncompliant">
+List&lt;? extends Animal&gt; getAnimals() { ... } // Noncompliant, wildcard with no use
+List&lt;? super Plant&gt; getLifeforms() { ... }  // Noncompliant, wildcard with no use
 </pre>
-<h3>Compliant solution</h3>
-<pre>
-List&lt;Animal&gt; getAnimals(){...}
+<p>You can remove the wildcards to make the types invariant:</p>
+<pre data-diff-id="1" data-diff-type="compliant">
+List&lt;Animal&gt; getAnimals() { ... }           // Compliant, using invariant type instead
+List&lt;Plant&gt; getLifeforms() { ... }          // Compliant, using invariant type instead
 </pre>
-<p>or</p>
-<pre>
-List&lt;Dog&gt; getAnimals(){...}
+<p>Or replace them with a super- or subtypes (still invariant):</p>
+<pre data-diff-id="1" data-diff-type="compliant">
+List&lt;Dog&gt; getAnimals() { ... }              // Compliant, using subtype instead
+List&lt;Lifeform&gt; getLifeforms() { ... }       // Compliant, using supertype instead
 </pre>
+<h2>Resources</h2>
+<h3>Documentation</h3>
+<ul>
+  <li> <a href="https://docs.oracle.com/javase/tutorial/extra/generics/wildcards.html">The Java™ Tutorials - Wildcards</a> </li>
+</ul>
+<h3>Articles &amp; blog posts</h3>
+<ul>
+  <li> <a href="https://medium.com/javarevisited/variance-in-java-and-scala-63af925d21dc">Sinisa Louc - A Complete Guide to Variance in Java and
+  Scala</a> </li>
+  <li> <a href="https://kotlinexpertise.com/kotlin-generics-and-variance-vs-java">Kotlin Expertise Blog - Kotlin Generics and Variance (Compared to
+  Java)</a> </li>
+  <li> <a href="https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)">Wikipedia - Covariance and contravariance (computer
+  science)</a> </li>
+  <li> <a href="https://schneide.blog/2015/05/11/declaration-site-and-use-site-variance-explained/">Schneide Blog - Declaration-site and use-site
+  variance explained</a> </li>
+  <li> <a href="https://en.wikipedia.org/wiki/Liskov_substitution_principle">Wikipedia - Liskov substitution principle</a> </li>
+</ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1596.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1596.html
index 67a017fcd3f..3004837708c 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1596.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1596.html
@@ -1,17 +1,45 @@
+<p>This rule raises an issue when the <code>Collections.EMPTY_*</code> fields are used instead of the <code>Collections.empty*()</code> methods.</p>
 <h2>Why is this an issue?</h2>
-<p>Since the introduction of generics in Java 5, the use of generic types such as <code>List&lt;String&gt;</code> is recommended over the use of raw
-ones such as <code>List</code>. Assigning a raw type to a generic one is not type safe, and will generate a warning. The old <code>EMPTY_...</code>
-fields of the <code>Collections</code> class return raw types, whereas the newer <code>empty...()</code> methods return generic ones.</p>
-<h3>Noncompliant code example</h3>
-<pre>
-List&lt;String&gt; collection1 = Collections.EMPTY_LIST;  // Noncompliant
-Map&lt;String, String&gt; collection2 = Collections.EMPTY_MAP;  // Noncompliant
-Set&lt;String&gt; collection3 = Collections.EMPTY_SET;  // Noncompliant
+<p>Generic types (types with type parameters) have been introduced into Java with language version 1.5. If type parameters are specified for a class
+or method, it is still possible to ignore them to keep backward compatibility with older code, which is called the <em>raw type</em> of the class or
+interface.</p>
+<p>Using raw type expressions is highly discouraged because the compiler cannot perform static type checking on them. This means that the compiler
+will not report typing errors about them at compile time, but a <code>ClassCastException</code> will be thrown during runtime.</p>
+<p>In Java 1.5, generics were also added to the Java collections API, and the data structures in <code>java.util</code>, such as <code>List</code>,
+<code>Set</code>, or <code>Map</code>, now feature type parameters. <code>Collections.EMPTY_LIST</code>, <code>Collections.EMPTY_SET</code>, and
+<code>Collections.EMPTY_MAP</code> are relics from before generics, and they return raw lists, sets, or maps, with the limitations mentioned
+above.</p>
+<h2>How to fix it</h2>
+<p>Use:</p>
+<ul>
+  <li> <code>Collections.emptyList()</code> instead of <code>Collections.EMPTY_LIST</code> </li>
+  <li> <code>Collections.emptySet()</code> instead of <code>Collections.EMPTY_SET</code> </li>
+  <li> <code>Collections.emptyMap()</code> instead of <code>Collections.EMPTY_MAP</code> </li>
+</ul>
+<p>In addition, there are variants of <code>Collections.empty*()</code> available also for other collection interfaces, such as
+<code>Collections.emptyIterator()</code>, <code>Collections.emptyNavigableMap()</code>, <code>Collections.emptySortedSet()</code>.</p>
+<h3>Code examples</h3>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="1" data-diff-type="noncompliant">
+List&lt;String&gt; collection1 = Collections.EMPTY_LIST;     // Noncompliant, raw List
+Set&lt;Float&gt; collection2 = Collections.EMPTY_SET;        // Noncompliant, raw Set
+Map&lt;Int, String&gt; collection3 = Collections.EMPTY_MAP;  // Noncompliant, raw Map
 </pre>
-<h3>Compliant solution</h3>
-<pre>
-List&lt;String&gt; collection1 = Collections.emptyList();
-Map&lt;String, String&gt; collection2 = Collections.emptyMap();
-Set&lt;String&gt; collection3 = Collections.emptySet();
+<h4>Compliant solution</h4>
+<pre data-diff-id="1" data-diff-type="compliant">
+List&lt;String&gt; collection1 = Collections.emptyList();    // Compliant, List&lt;String&gt;
+Set&lt;Float&gt; collection2 = Collections.emptySet();       // Compliant, Set&lt;Float&gt;
+Map&lt;Int, String&gt; collection3 = Collections.emptyMap(); // Compliant, Map&lt;Int, String&gt;
 </pre>
+<h2>Resources</h2>
+<h3>Documentation</h3>
+<ul>
+  <li> <a href="https://docs.oracle.com/javase/8/docs/api/java/util/Collections.html">Oracle - Java™ Platform, Standard Edition 8 API Specification,
+  Class Collections</a> </li>
+  <li> <a href="https://docs.oracle.com/javase/tutorial/java/generics/rawTypes.html">Oracle - The Java™ Tutorials - Raw Types</a> </li>
+</ul>
+<h3>Articles &amp; blog posts</h3>
+<ul>
+  <li> <a href="https://www.baeldung.com/java-generics">Baeldung - The Basics of Java Generics</a> </li>
+</ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1598.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1598.html
index bf725f930ca..10c4945bea3 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1598.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1598.html
@@ -1,10 +1,52 @@
 <h2>Why is this an issue?</h2>
-<p>By convention, a Java class' physical location (source directories) and its logical representation (packages) should be kept in sync. Thus a Java
-file located at <code>"src/org/bar/Foo.java"</code> should have a package of <code>"org.bar"</code>.</p>
-<p>Unfortunately, this convention is not enforced by Java compilers, and nothing prevents a developer from making the "Foo.java" class part of the
-"com.apple" package, which could degrade the maintainability of both the class and its application.</p>
-<p>Similarly, source placed in a folder with dots in its name instead of having the equivalent folder structure will compile but cause problems at run
-time. For instance, code with a package declaration of <code>org.foo.bar</code> that is placed in <code>org/foo.bar</code> will compile, but the
-classloader will always search for the class into the folder based on package structure, and will consequently expect sources to be in
-<code>org/foo/bar</code> folder. <code>foo.bar</code> is therefore not a proper folder name for sources.</p>
+<p>The purpose of Java packages is to give structure to your project. A structure helps to mentally break down a project into smaller parts,
+simplifying readers' understanding of how components are connected and how they interact.</p>
+<p>By convention, the source files' directory structure should replicate the project’s package structure. This is for the following reasons:</p>
+<ol>
+  <li> The mapping between the package name and the location of the source file of a class is straightforward. That is, the path to the source file is
+  easier to find for a given fully qualified class name. </li>
+  <li> If two different structures are applied to the same project - one to the packages but another to the source file directories - this confuses
+  developers while not providing any benefit. </li>
+  <li> The directory structure of the class files generated by the compiler will match the package structure, no matter the source file’s directory.
+  It would not make sense to have one directory structure for the generated class files but a different one for the associated source files. </li>
+</ol>
+<p>Similarly, a source directory should not have the character <code>.</code> in its name, as this would make it impossible to match the directory to
+the package structure.</p>
+<h2>How to fix it</h2>
+<p>Either move the source file so that the relative file path within the source directory matches the package name, or change the package name so that
+it matches the relative file path.</p>
+<h3>Code examples</h3>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="1" data-diff-type="noncompliant">
+// file: src/main/foo/Fubar.java
+package com.foo.bar;
+
+class Fubar {
+}
+</pre>
+<h4>Compliant solution</h4>
+<pre data-diff-id="1" data-diff-type="compliant">
+// file: src/main/com/foo/bar/Fubar.java
+package com.foo.bar;
+
+class Fubar {
+}
+</pre>
+<pre data-diff-id="1" data-diff-type="compliant">
+// file: src/main/foo/Fubar.java
+package foo;
+
+class Fubar {
+}
+</pre>
+<h2>Resources</h2>
+<h3>Articles &amp; blog posts</h3>
+<ul>
+  <li> <a href="https://www.baeldung.com/java-declared-expected-package-error">Baeldung - Fixing the "Declared package does not match the expected
+  package" Error</a> </li>
+  <li> <a href="https://www.baeldung.com/java-file-vs-file-path-separator">Stackoverflow - Why do java source files require package declarations?</a>
+  </li>
+  <li> <a
+  href="https://www.tutorialspoint.com/what-are-the-best-practices-to-keep-in-mind-while-using-packages-in-java#:~:text=Naming%20conventions%20and%20best%20practices%20for%20packages">tutorialspoint - What are the best practices to keep in mind while using packages in Java?</a> </li>
+</ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1602.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1602.html
index 15a06d678ff..a830f7b50b2 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1602.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1602.html
@@ -1,14 +1,36 @@
+<p>This rule raises an issue when a lambda expression uses block notation while expression notation could be used.</p>
 <h2>Why is this an issue?</h2>
-<p>There are two ways to write lambdas that contain single statement, but one is definitely more compact and readable than the other.</p>
-<p><strong>Note</strong> that this rule is automatically disabled when the project’s <code>sonar.java.source</code> is lower than <code>8</code>.</p>
-<h3>Noncompliant code example</h3>
-<pre>
-x -&gt; {System.out.println(x+1);}
-(a, b) -&gt; { return a+b; }
-</pre>
-<h3>Compliant solution</h3>
-<pre>
-x -&gt; System.out.println(x+1)
-(a, b) -&gt; a+b    //For return statement, the return keyword should also be dropped
+<p>The right-hand side of a lambda expression can be written in two ways:</p>
+<ol>
+  <li> Expression notation: the right-hand side is as an expression, such as in <code>(a, b) → a + b</code> </li>
+  <li> Block notation: the right-hand side is a conventional function body with a code block and an optional return statement, such as in <code>(a, b)
+  → {return a + b;}</code> </li>
+</ol>
+<p>By convention, expression notation is preferred over block notation. Block notation must be used when the function implementation requires more
+than one statement. However, when the code block consists of only one statement (which may or may not be a <code>return</code> statement), it can be
+rewritten using expression notation.</p>
+<p>This convention exists because expression notation has a cleaner, more concise, functional programming style and is regarded as more readable.</p>
+<h2>How to fix it</h2>
+<ul>
+  <li> If the code block consists only of a <code>return</code> statement, replace the code block with the argument expression from the
+  <code>return</code> statement. </li>
+  <li> If the code block consists of a single statement that is not a <code>return</code> statement, replace the code block with that statement. </li>
+</ul>
+<h3>Code examples</h3>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="1" data-diff-type="noncompliant">
+(a, b) -&gt; { return a + b; } // Noncompliant, replace code block with expression
+</pre>
+<h4>Compliant solution</h4>
+<pre data-diff-id="1" data-diff-type="compliant">
+(a, b) -&gt; a + b             // Compliant
+</pre>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="1" data-diff-type="noncompliant">
+x -&gt; {System.out.println(x+1);} // Noncompliant, replace code block with statement
+</pre>
+<h4>Compliant solution</h4>
+<pre data-diff-id="1" data-diff-type="compliant">
+x -&gt; System.out.println(x+1)    // Compliant
 </pre>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1604.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1604.html
index 0aa8f54e30a..fb99b9b290d 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1604.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1604.html
@@ -1,26 +1,40 @@
 <h2>Why is this an issue?</h2>
-<p>Before Java 8, the only way to partially support closures in Java was by using anonymous inner classes. But the syntax of anonymous classes may
-seem unwieldy and unclear.</p>
-<p>With Java 8, most uses of anonymous inner classes should be replaced by lambdas to highly increase the readability of the source code.</p>
-<p><strong>Note</strong> that this rule is automatically disabled when the project’s <code>sonar.java.source</code> is lower than <code>8</code>.</p>
-<h3>Noncompliant code example</h3>
-<pre>
-myCollection.stream().map(new Mapper&lt;String,String&gt;() {
-  public String map(String input) {
+<p>Before Java 8, the only way to partially support closures in Java was by using anonymous inner classes. Java 8 introduced lambdas, which are
+significantly more readable and should be used instead.</p>
+<p>This rule is automatically disabled when the project’s <code>sonar.java.source</code> is lower than <code>8</code>, as lambda expressions were
+introduced in Java 8.</p>
+<h3>Code examples</h3>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="1" data-diff-type="noncompliant">
+myCollection.stream().map(new Function&lt;String,String&gt;() { // Noncompliant, use a lambda expression instead
+  @Override
+  public String apply(String input) {
     return new StringBuilder(input).reverse().toString();
   }
-});
-
-Predicate&lt;String&gt; isEmpty = new Predicate&lt;String&gt; {
-    boolean test(String myString) {
-        return myString.isEmpty();
-    }
-}
+})
+  ...
 </pre>
-<h3>Compliant solution</h3>
-<pre>
-myCollection.stream().map(input -&gt; new StringBuilder(input).reverse().toString());
-
-Predicate&lt;String&gt; isEmpty = myString -&gt; myString.isEmpty();
+<h4>Compliant solution</h4>
+<pre data-diff-id="1" data-diff-type="compliant">
+myCollection.stream()
+  .map(input -&gt; new StringBuilder(input).reverse().toString()) // Compliant
+    ...
+</pre>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="2" data-diff-type="noncompliant">
+Predicate&lt;String&gt; isEmpty = new Predicate&lt;String&gt;() { // Noncompliant, use a lambda expression instead
+  @Override
+  public boolean test(String myString) {
+    return myString.isEmpty();
+  }
+};
+</pre>
+<h4>Compliant solution</h4>
+<pre data-diff-id="2" data-diff-type="compliant">
+Predicate&lt;String&gt; isEmpty = myString -&gt; myString.isEmpty(); // Compliant
 </pre>
+<h2>Resources</h2>
+<ul>
+  <li> <a href="https://docs.oracle.com/javase/tutorial/java/javaOO/lambdaexpressions.html">Lambda Expressions - The Java™ Tutorials</a> </li>
+</ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1610.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1610.html
index 828fdbbd23a..e5b8e28f0b4 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1610.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1610.html
@@ -1,3 +1,4 @@
+<p>This rule is deprecated, and will eventually be removed.</p>
 <h2>Why is this an issue?</h2>
 <p>With Java 8’s "default method" feature, any abstract class without direct or inherited field should be converted into an interface. However, this
 change may not be appropriate in libraries or other applications where the class is intended to be used as an API.</p>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1610.json b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1610.json
index ab64ca1b895..af386c01dfd 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1610.json
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1610.json
@@ -1,14 +1,12 @@
 {
   "title": "Abstract classes without fields should be converted to interfaces",
   "type": "CODE_SMELL",
-  "status": "ready",
+  "status": "deprecated",
   "remediation": {
     "func": "Constant\/Issue",
     "constantCost": "10min"
   },
-  "tags": [
-    "java8"
-  ],
+  "tags": [],
   "defaultSeverity": "Minor",
   "ruleSpecification": "RSPEC-1610",
   "sqKey": "S1610",
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1611.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1611.html
index 0e6af4a0006..158cafb5f49 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1611.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1611.html
@@ -1,13 +1,14 @@
 <h2>Why is this an issue?</h2>
-<p>There are two possible syntaxes for a lambda having only one input parameter with an inferred type: with and without parentheses around that single
-parameter. The simpler syntax, without parentheses, is more compact and readable than the one with parentheses, and is therefore preferred.</p>
-<p><strong>Note</strong> that this rule is automatically disabled when the project’s <code>sonar.java.source</code> is lower than <code>8</code>.</p>
+<p>Lambda expressions with only one argument with an inferred type (i.e., no explicit type declaration) can be written without parentheses around that
+single parameter. This syntax is simpler, more compact and readable than using parentheses and is therefore preferred.</p>
+<p>This rule is automatically disabled when the project’s <code>sonar.java.source</code> is lower than <code>8</code>, as lambda expressions were
+introduced in Java 8.</p>
 <h3>Noncompliant code example</h3>
-<pre>
+<pre data-diff-id="1" data-diff-type="noncompliant">
 (x) -&gt; x * 2
 </pre>
 <h3>Compliant solution</h3>
-<pre>
+<pre data-diff-id="1" data-diff-type="compliant">
 x -&gt; x * 2
 </pre>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1611.json b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1611.json
index 028d3bee7a7..f5c6fbad415 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1611.json
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1611.json
@@ -1,5 +1,5 @@
 {
-  "title": "Parentheses should be removed from a single lambda input parameter when its type is inferred",
+  "title": "Parentheses should be removed from a single lambda parameter when its type is inferred",
   "type": "CODE_SMELL",
   "status": "ready",
   "remediation": {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1612.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1612.html
index 0db3ee29b4d..3404e19485a 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1612.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1612.html
@@ -1,21 +1,27 @@
 <h2>Why is this an issue?</h2>
-<p>Method/constructor references are commonly agreed to be more readable than lambdas in most situations, and are therefore preferred.</p>
-<p>However, method references are sometimes less concise than lambdas. In such cases, it might be fine to keep the lambda if it is better for
-readability. This choice is ultimately up to the programmer. Therefore, this rule only raises issues on lambda functions that could be replaced by
-shorter method references.</p>
-<p><code>null</code> checks can be replaced with references to the <code>Objects::isNull</code> and <code>Objects::nonNull</code> methods,
-<code>casts</code> can be replaced with <code>SomeClass.class::cast</code> and <code>instanceof</code> can be replaced with
-<code>SomeClass.class::isInstance</code>.</p>
-<p><strong>Note</strong> that this rule is automatically disabled when the project’s <code>sonar.java.source</code> is lower than <code>8</code>.</p>
-<h3>Noncompliant code example</h3>
-<pre>
+<p>Method or constructor references are more readable than lambda expressions in many situations, and may therefore be preferred.</p>
+<p>However, method references are sometimes less concise than lambdas. In such cases, it might be preferrable to keep the lambda expression for better
+readability. Therefore, this rule only raises issues on lambda expressions where the replacement method reference is shorter.</p>
+<p>This rule is automatically disabled when the project’s <code>sonar.java.source</code> is lower than <code>8</code>, as lambda expressions were
+introduced in Java 8.</p>
+<h2>How to fix it</h2>
+<p>Refer to the called method by its reference instead of wrapping it in a lambda expression.</p>
+<p>For instance:</p>
+<ul>
+  <li> <code>null</code> checks can be replaced with references to <code>Objects::isNull</code> and <code>Objects::nonNull</code> </li>
+  <li> Casts can be replaced with <code>SomeClass.class::cast</code> </li>
+  <li> <code>instanceof</code> can be replaced with <code>SomeClass.class::isInstance</code> </li>
+</ul>
+<h3>Code examples</h3>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="1" data-diff-type="noncompliant">
 class A {
   void process(List&lt;A&gt; list) {
     list.stream()
-      .filter(a -&gt; a instanceof B)
-      .map(a -&gt; (B) a)
-      .map(b -&gt; b.&lt;String&gt;getObject())
-      .forEach(b -&gt; { System.out.println(b); });
+      .filter(myListValue -&gt; myListValue instanceof B)     // Noncompliant
+      .map(listValueToMap -&gt; (B) listValueToMap)           // Noncompliant
+      .map(bValueToMap -&gt; bValueToMap.&lt;String&gt;getObject()) // Noncompliant
+      .forEach(o -&gt; System.out.println(o));                // Noncompliant
   }
 }
 
@@ -25,15 +31,15 @@ <h3>Noncompliant code example</h3>
   }
 }
 </pre>
-<h3>Compliant solution</h3>
-<pre>
+<h4>Compliant solution</h4>
+<pre data-diff-id="1" data-diff-type="compliant">
 class A {
   void process(List&lt;A&gt; list) {
     list.stream()
-      .filter(B.class::isInstance)
-      .map(B.class::cast)            // Note: keeping the lambda would also be compliant here, since it is shorter
-      .map(B::&lt;String&gt;getObject)
-      .forEach(System.out::println);
+      .filter(B.class::isInstance)   // Compliant
+      .map(B.class::cast)            // Compliant
+      .map(B::&lt;String&gt;getObject)     // Compliant
+      .forEach(System.out::println); // Compliant
   }
 }
 
@@ -43,4 +49,8 @@ <h3>Compliant solution</h3>
   }
 }
 </pre>
+<h2>Resources</h2>
+<ul>
+  <li> <a href="https://docs.oracle.com/javase/tutorial/java/javaOO/methodreferences.html">Method References - The Java™ Tutorials</a> </li>
+</ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1640.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1640.html
index fa657247342..ba9059813c5 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1640.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1640.html
@@ -1,30 +1,25 @@
 <h2>Why is this an issue?</h2>
-<p>When all the keys of a Map are values from the same enum, the <code>Map</code> can be replaced with an <code>EnumMap</code>, which can be much more
-efficient than other sets because the underlying data structure is a simple array.</p>
+<p>If all the keys in a <code>Map</code> are values from a single enum, it is recommended to use an <code>EnumMap</code> as the specific
+implementation. An <code>EnumMap</code>, which has the advantage of knowing all possible keys in advance, is more efficient compared to other
+implementations, as it can use a simple array as its underlying data structure.</p>
 <h3>Noncompliant code example</h3>
-<pre>
-public class MyClass {
-
-  public enum COLOR {
-    RED, GREEN, BLUE, ORANGE;
-  }
-
-  public void mapMood() {
-    Map&lt;COLOR, String&gt; moodMap = new HashMap&lt;COLOR, String&gt; ();
-  }
+<pre data-diff-id="1" data-diff-type="noncompliant">
+public enum Color {
+  RED, GREEN, BLUE, ORANGE;
 }
+
+Map&lt;Color, String&gt; colorMap = new HashMap&lt;&gt;(); // Noncompliant
 </pre>
 <h3>Compliant solution</h3>
-<pre>
-public class MyClass {
-
-  public enum COLOR {
-    RED, GREEN, BLUE, ORANGE;
-  }
-
-  public void mapMood() {
-    EnumMap&lt;COLOR, String&gt; moodMap = new EnumMap&lt;&gt; (COLOR.class);
-  }
+<pre data-diff-id="1" data-diff-type="compliant">
+public enum Color {
+  RED, GREEN, BLUE, ORANGE;
 }
+
+Map&lt;Color, String&gt; colorMap = new EnumMap&lt;&gt;(Color.class); // Compliant
 </pre>
+<h2>Resources</h2>
+<ul>
+  <li> <a href="https://www.baeldung.com/java-enum-map">A Guide to EnumMap - Baeldung</a> </li>
+</ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1640.json b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1640.json
index adbc0cd830e..7b3f07671c2 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1640.json
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1640.json
@@ -1,5 +1,5 @@
 {
-  "title": "Maps with keys that are enum values should be replaced with EnumMap",
+  "title": "Maps with keys that are enum values should use the EnumMap implementation",
   "type": "CODE_SMELL",
   "status": "ready",
   "remediation": {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1710.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1710.html
index f7d87a8907b..3507d4b86ca 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1710.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1710.html
@@ -1,10 +1,12 @@
 <h2>Why is this an issue?</h2>
-<p>Before Java 8 if you needed to use multiple instances of the same annotation, they had to be wrapped in a container annotation. With Java 8, that’s
-no longer necessary, allowing for cleaner, more readable code.</p>
-<p><strong>Note</strong> that this rule is automatically disabled when the project’s <code>sonar.java.source</code> is lower than <code>8</code>.</p>
-<h3>Noncompliant code example</h3>
-<pre>
-@SomeAnnotations({  // Noncompliant
+<p>Before Java 8, a container annotation was required as wrapper to use multiple instances of the same annotation. As of Java 8, this is no longer
+necessary. Instead, these annotations should be used directly without a wrapper, resulting in cleaner and more readable code.</p>
+<p>This rule is automatically disabled when the project’s <code>sonar.java.source</code> is lower than <code>8</code> as repeating annotations were
+introduced is Java 8.</p>
+<h3>Code examples</h3>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="1" data-diff-type="noncompliant">
+@SomeAnnotations({  // Noncompliant, wrapper annotations are not necessary in Java 8+
   @SomeAnnotation(..a..),
   @SomeAnnotation(..b..),
   @SomeAnnotation(..c..),
@@ -13,8 +15,8 @@ <h3>Noncompliant code example</h3>
   ...
 }
 </pre>
-<h3>Compliant solution</h3>
-<pre>
+<h4>Compliant solution</h4>
+<pre data-diff-id="1" data-diff-type="compliant">
 @SomeAnnotation(..a..)
 @SomeAnnotation(..b..)
 @SomeAnnotation(..c..)
@@ -22,4 +24,8 @@ <h3>Compliant solution</h3>
   ...
 }
 </pre>
+<h2>References</h2>
+<ul>
+  <li> <a href="https://docs.oracle.com/javase/tutorial/java/annotations/repeating.html">Repeating Annotations - The Java™ Tutorials</a> </li>
+</ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1844.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1844.html
index 6f7884be272..858e101f7f1 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1844.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1844.html
@@ -1,25 +1,29 @@
 <h2>Why is this an issue?</h2>
-<p>From the Java API documentation:</p>
-<blockquote>
-  <p><code>Condition</code> factors out the <code>Object</code> monitor methods (<code>wait</code>, <code>notify</code> and <code>notifyAll</code>)
-  into distinct objects to give the effect of having multiple wait-sets per object, by combining them with the use of arbitrary Lock implementations.
-  Where a <code>Lock</code> replaces the use of <code>synchronized</code> methods and statements, a <code>Condition</code> replaces the use of the
-  <code>Object</code> monitor methods.</p>
-</blockquote>
-<p>The purpose of implementing the <code>Condition</code> interface is to gain access to its more nuanced <code>await</code> methods. Therefore,
-calling the method <code>Object.wait(...)</code> on a class implementing the <code>Condition</code> interface is silly and confusing.</p>
+<p>The <code>java.util.concurrent.locks.Condition</code> interface provides an alternative to the <code>Object</code> monitor methods
+(<code>wait</code>, <code>notify</code> and <code>notifyAll</code>). Hence, the purpose of implementing said interface is to gain access to its more
+nuanced <code>await</code> methods.</p>
+<p>Consequently, calling the method <code>Object.wait</code> on a class implementing the <code>Condition</code> interface is contradictory and should
+be avoided. Use <code>Condition.await</code> instead.</p>
+<h2>Code examples</h2>
 <h3>Noncompliant code example</h3>
-<pre>
-final Lock lock = new ReentrantLock();
-final Condition notFull  = lock.newCondition();
-...
-notFull.wait();
+<pre data-diff-id="1" data-diff-type="noncompliant">
+void doSomething(Condition condition) {
+    condition.wait(); // Noncompliant, Object.wait is called
+
+        ...
+}
 </pre>
 <h3>Compliant solution</h3>
-<pre>
-final Lock lock = new ReentrantLock();
-final Condition notFull  = lock.newCondition();
-...
-notFull.await();
+<pre data-diff-id="1" data-diff-type="compliant">
+void doSomething(Condition condition) {
+    condition.await(); // Compliant, Condition.await is called
+
+        ...
+}
 </pre>
+<h2>References</h2>
+<ul>
+  <li> <a href="https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/locks/Condition.html">Interface Condition - Java™ Platform SE 8, API
+  Specification</a> </li>
+</ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1844.json b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1844.json
index 0d1b3e749b3..df61be69207 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1844.json
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1844.json
@@ -1,5 +1,5 @@
 {
-  "title": "\"Object.wait(...)\" should never be called on objects that implement \"java.util.concurrent.locks.Condition\"",
+  "title": "\"Object.wait\" should not be called on objects that implement \"java.util.concurrent.locks.Condition\"",
   "type": "CODE_SMELL",
   "status": "ready",
   "remediation": {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1849.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1849.html
index b2869aff9c1..33f5ce9cea3 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1849.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1849.html
@@ -1,19 +1,57 @@
 <h2>Why is this an issue?</h2>
-<p>Calling <code>Iterator.hasNext()</code> is not supposed to have any side effects, and therefore should not change the state of the iterator.
-<code>Iterator.next()</code> advances the iterator by one item. So calling it inside <code>Iterator.hasNext()</code>, breaks the
-<code>hasNext()</code> contract, and will lead to unexpected behavior in production.</p>
+<p>Calling <code>Iterator.hasNext()</code> is not supposed to have any side effects and hence should not change the iterator’s state.
+<code>Iterator.next()</code> advances the iterator by one item. So calling it inside <code>Iterator.hasNext()</code> breaks the <code>hasNext()</code>
+contract and will lead to unexpected behavior in production.</p>
+<h2>How to fix it</h2>
+<p>How to fix this issue strongly depends on the specific implementation of the iterator. Make sure that the logic of the <code>hasNext()</code>
+implementation does not change the state of the iterator or any underlying data sources. Instead, it should merely return state information.</p>
+<h2>Code examples</h2>
 <h3>Noncompliant code example</h3>
-<pre>
-public class FibonacciIterator implements Iterator&lt;Integer&gt;{
-...
-@Override
-public boolean hasNext() {
-  if(next() != null) {
-    return true;
+<pre data-diff-id="1" data-diff-type="noncompliant">
+class MyIterator implements Iterator&lt;Integer&gt; {
+
+  private Queue&lt;Integer&gt; elements;
+
+    ...
+
+  @Override
+  public boolean hasNext() {
+    try {
+      next(); // Noncompliant, next() is called from hasNext()
+      return true;
+    } catch (NoSuchElementException e) {
+      return false;
+    }
+  }
+
+  @Override
+  public Integer next() {
+    return elements.remove();
   }
-  return false;
 }
-...
+</pre>
+<h3>Compliant solution</h3>
+<pre data-diff-id="1" data-diff-type="compliant">
+class MyIterator implements Iterator&lt;Integer&gt; {
+
+  private Queue&lt;Integer&gt; elements;
+
+    ...
+
+  @Override
+  public boolean hasNext() {
+    return !elements.isEmpty(); // Compliant, no call to next()
+  }
+
+  @Override
+  public Integer next() {
+    return elements.remove();
+  }
 }
 </pre>
+<h2>Resources</h2>
+<ul>
+  <li> <a href="https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/Iterator.html">Interface Iterator&lt;E&gt; - Java® Platform SE
+  11 API Specification</a> </li>
+</ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1860.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1860.html
index eab93a229dd..634d18d517c 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1860.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1860.html
@@ -1,22 +1,29 @@
 <h2>Why is this an issue?</h2>
-<p>Objects which are pooled and potentially reused should not be used for synchronization. If they are, it can cause unrelated threads to deadlock
-with unhelpful stacktraces. Specifically, <code>String</code> literals, and boxed primitives such as Integers should not be used as lock objects
-because they are pooled and reused. The story is even worse for <code>Boolean</code> objects, because there could possibly be only two instances of
-<code>Boolean</code>, <code>Boolean.TRUE</code> and <code>Boolean.FALSE</code> and every class that uses a Boolean will be referring to one of the
-two.</p>
-<p>Here is the list of types which shouldn’t be used for synchronization:</p>
+<p>Instances of value-based classes, which are pooled and potentially reused, should not be used for synchronization. If they are, it can cause
+unrelated threads to deadlock with unhelpful stacktraces.</p>
+<p>Within the JDK, types which should not be used for synchronization include:</p>
 <ul>
-  <li> The primitive wrapper classes in java.lang; </li>
-  <li> The class java.lang.Runtime.Version; </li>
-  <li> The "optional" classes in java.util: Optional, OptionalInt, OptionalLong, and OptionalDouble; </li>
-  <li> Many classes in the java.time API: Instant, LocalDate, LocalTime, LocalDateTime, ZonedDateTime, ZoneId, OffsetTime, OffsetDateTime, ZoneOffset,
-  Duration, Period, Year, YearMonth, and MonthDay, and, in java.time.chrono: MinguoDate, HijrahDate, JapaneseDate, and ThaiBuddhistDate; </li>
-  <li> The interface java.lang.ProcessHandle and its implementation classes; </li>
-  <li> The implementation classes of the collection factories in java.util: List.of, List.copyOf, Set.of, Set.copyOf, Map.of, Map.copyOf,
-  Map.ofEntries, and Map.entry. </li>
+  <li> <code>String</code> literals </li>
+  <li> Primitive wrapper classes in <code>java.lang</code> (such as <code>Boolean</code> with <code>Boolean.FALSE</code> and
+  <code>Boolean.TRUE</code>) </li>
+  <li> The class <code>java.lang.Runtime.Version</code> </li>
+  <li> The <code>Optional*</code> classes in <code>java.util</code>: <code>Optional</code>, <code>OptionalInt</code>, <code>OptionalLong</code>, and
+  <code>OptionalDouble</code> </li>
+  <li> Various classes in the <code>java.time</code> API: <code>Instant</code>, <code>LocalDate</code>, <code>LocalTime</code>,
+  <code>LocalDateTime</code>, <code>ZonedDateTime</code>, <code>ZoneId</code>, <code>OffsetTime</code>, <code>OffsetDateTime</code>,
+  <code>ZoneOffset</code>, <code>Duration</code>, <code>Period</code>, <code>Year</code>, <code>YearMonth</code>, and <code>MonthDay</code> </li>
+  <li> Various classes in the <code>java.time.chrono</code> API: <code>MinguoDate</code>, <code>HijrahDate</code>, <code>JapaneseDate</code>, and
+  <code>ThaiBuddhistDate</code> </li>
+  <li> The interface <code>java.lang.ProcessHandle</code> and its implementation classes </li>
+  <li> The implementation classes of the collection factories in <code>java.util</code>: <code>List.of</code>, <code>List.copyOf</code>,
+  <code>Set.of</code>, <code>Set.copyOf</code>, <code>Map.of</code>, <code>Map.copyOf</code>, <code>Map.ofEntries</code>, and <code>Map.entry</code>.
+  </li>
 </ul>
+<h2>How to fix it</h2>
+<p>Replace instances of value-based classes with a new object instance to synchronize on.</p>
+<h2>Code examples</h2>
 <h3>Noncompliant code example</h3>
-<pre>
+<pre data-diff-id="1" data-diff-type="noncompliant">
 private static final Boolean bLock = Boolean.FALSE;
 private static final Integer iLock = Integer.valueOf(0);
 private static final String sLock = "LOCK";
@@ -25,20 +32,20 @@ <h3>Noncompliant code example</h3>
 public void doSomething() {
 
   synchronized(bLock) {  // Noncompliant
-    // ...
+      ...
   }
   synchronized(iLock) {  // Noncompliant
-    // ...
+      ...
   }
   synchronized(sLock) {  // Noncompliant
-    // ...
+      ...
   }
   synchronized(listLock) {  // Noncompliant
-    // ...
+      ...
   }
 </pre>
 <h3>Compliant solution</h3>
-<pre>
+<pre data-diff-id="1" data-diff-type="compliant">
 private static final Object lock1 = new Object();
 private static final Object lock2 = new Object();
 private static final Object lock3 = new Object();
@@ -46,22 +53,24 @@ <h3>Compliant solution</h3>
 
 public void doSomething() {
 
-  synchronized(lock1) {
-    // ...
+  synchronized(lock1) { // Compliant
+      ...
   }
-  synchronized(lock2) {
-    // ...
+  synchronized(lock2) { // Compliant
+      ...
   }
-  synchronized(lock3) {
-    // ...
+  synchronized(lock3) { // Compliant
+      ...
   }
-  synchronized(lock4) {
-    // ...
+  synchronized(lock4) { // Compliant
+      ...
   }
 </pre>
 <h2>Resources</h2>
 <ul>
-  <li> <a href="https://wiki.sei.cmu.edu/confluence/x/1zdGBQ">CERT, LCK01-J.</a> - Do not synchronize on objects that may be reused </li>
-  <li> <a href="https://openjdk.java.net/jeps/390">JEP-390.</a> - JEP 390: Warnings for Value-Based Classes </li>
+  <li> <a href="https://wiki.sei.cmu.edu/confluence/x/1zdGBQ">Do not synchronize on objects that may be reused - CERT, LCK01-J.</a> </li>
+  <li> <a href="https://openjdk.java.net/jeps/390">JEP 390: Warnings for Value-Based Classes - OpenJDK</a> </li>
+  <li> <a href="https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/doc-files/ValueBased.html">Value-based Classes - Java SE 17 API
+  Documentation</a> </li>
 </ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1948.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1948.html
index 0cf082d5e09..a899401dd75 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1948.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1948.html
@@ -1,50 +1,94 @@
+<p>This rule raises an issue on a non-transient and non-serializable field within a serializable class, if said class does not have
+<code>writeObject</code> and <code>readObject</code> methods defined.</p>
 <h2>Why is this an issue?</h2>
-<p>Fields in a <code>Serializable</code> class must themselves be either <code>Serializable</code> or <code>transient</code> even if the class is
-never explicitly serialized or deserialized. For instance, under load, most J2EE application frameworks flush objects to disk, and an allegedly
-<code>Serializable</code> object with non-transient, non-serializable data members could cause program crashes, and open the door to attackers. In
-general a <code>Serializable</code> class is expected to fulfil its contract and not have an unexpected behaviour when an instance is serialized.</p>
-<p>This rule raises an issue on non-<code>Serializable</code> fields, and on collection fields when they are not <code>private</code> (because they
-could be assigned non-<code>Serializable</code> values externally), and when they are assigned non-<code>Serializable</code> types within the
-class.</p>
-<h3>Noncompliant code example</h3>
-<pre>
+<p>By contract, fields in a <code>Serializable</code> class must themselves be either <code>Serializable</code> or <code>transient</code>. Even if the
+class is never explicitly serialized or deserialized, it is not safe to assume that this cannot happen. For instance, under load, most J2EE
+application frameworks flush objects to disk.</p>
+<p>An object that implements <code>Serializable</code> but contains non-transient, non-serializable data members (and thus violates the contract)
+could cause application crashes and open the door to attackers. In general, a <code>Serializable</code> class is expected to fulfil its contract and
+not exhibit unexpected behaviour when an instance is serialized.</p>
+<p>This rule raises an issue on:</p>
+<ul>
+  <li> non-<code>Serializable</code> fields, </li>
+  <li> collection fields when they are not <code>private</code> (because they could be assigned non-<code>Serializable</code> values externally),
+  </li>
+  <li> when a field is assigned a non-<code>Serializable</code> type within the class. </li>
+</ul>
+<h2>How to fix it</h2>
+<p>Consider the following scenario.</p>
+<pre data-diff-id="1" data-diff-type="noncompliant">
 public class Address {
-  //...
+    ...
 }
 
 public class Person implements Serializable {
   private static final long serialVersionUID = 1905122041950251207L;
 
   private String name;
-  private Address address;  // Noncompliant; Address isn't serializable
+  private Address address;  // Noncompliant, Address is not serializable
 }
 </pre>
-<h3>Compliant solution</h3>
-<pre>
+<p>How to fix this issue depends on the application’s needs. If the field’s value should be preserved during serialization and deserialization, you
+may want to make the field’s value serializable.</p>
+<pre data-diff-id="1" data-diff-type="compliant">
 public class Address implements Serializable {
   private static final long serialVersionUID = 2405172041950251807L;
+
+    ...
+}
+
+public class Person implements Serializable {
+  private static final long serialVersionUID = 1905122041950251207L;
+
+  private String name;
+  private Address address; // Compliant, Address is serializable
+}
+</pre>
+<p>If the field’s value does not need to be preserved during serialization and deserialization, mark it as <code>transient</code>. The field will be
+ignored when the object is serialized. After deserialization, the field will be set to the default value corresponding to its type (e.g.,
+<code>null</code> for object references).</p>
+<pre data-diff-id="1" data-diff-type="compliant">
+public class Address {
+    ...
 }
 
 public class Person implements Serializable {
   private static final long serialVersionUID = 1905122041950251207L;
 
   private String name;
-  private Address address;
+  private transient Address address; // Compliant, the field is transient
 }
 </pre>
-<h3>Exceptions</h3>
-<p>The alternative to making all members <code>serializable</code> or <code>transient</code> is to implement special methods which take on the
-responsibility of properly serializing and de-serializing the object. This rule ignores classes which implement the following methods:</p>
-<pre>
- private void writeObject(java.io.ObjectOutputStream out)
-     throws IOException
- private void readObject(java.io.ObjectInputStream in)
-     throws IOException, ClassNotFoundException;
+<p>The alternative to making all members serializable or <code>transient</code> is to implement special methods which take on the responsibility of
+properly serializing and de-serializing the object <code>writeObject</code> and <code>readObject</code>. These methods can be used to properly
+(de-)serialize an object, even though it contains fields that are not transient or serializable. Hence, this rule does not raise issues on fields of
+classes which implement these methods.</p>
+<pre data-diff-id="1" data-diff-type="compliant">
+public class Address {
+    ...
+}
+
+public class Person implements Serializable {
+  private static final long serialVersionUID = 1905122041950251207L;
+
+  private String name;
+  private Address address; // Compliant, writeObject and readObject handle this field
+
+  private void writeObject(java.io.ObjectOutputStream out) throws IOException {
+    // Appropriate serialization logic here
+  }
+
+  private void readObject(java.io.ObjectInputStream in) throws IOException, ClassNotFoundException {
+    // Appropriate deserialization logic here
+  }
+}
 </pre>
 <h2>Resources</h2>
 <ul>
-  <li> <a href="https://cwe.mitre.org/data/definitions/594">MITRE, CWE-594</a> - Saving Unserializable Objects to Disk </li>
-  <li> <a href="https://docs.oracle.com/javase/6/docs/api/java/io/Serializable.html">Oracle Java 6, Serializable</a> </li>
-  <li> <a href="https://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html">Oracle Java 7, Serializable</a> </li>
+  <li> <a href="https://cwe.mitre.org/data/definitions/594">Saving Unserializable Objects to Disk - MITRE, CWE-594</a> </li>
+  <li> <a href="https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/io/Serializable.html">Interface Serializable - Java SE 11 API
+  Documentation</a> </li>
+  <li> <a href="https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/io/Serializable.html">Interface Serializable - Java SE 17 API
+  Documentation</a> </li>
 </ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1989.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1989.html
index a2944ca3f42..4a23f65b1f9 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1989.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S1989.html
@@ -1,33 +1,47 @@
 <h2>Why is this an issue?</h2>
-<p>Even though the signatures for methods in a servlet include <code>throws IOException, ServletException</code>, it’s a bad idea to let such
-exceptions be thrown. Failure to catch exceptions in a servlet could leave a system in a vulnerable state, possibly resulting in denial-of-service
-attacks, or the exposure of sensitive information because when a servlet throws an exception, the servlet container typically sends debugging
-information back to the user. And that information could be very valuable to an attacker.</p>
-<p>This rule checks all exceptions in methods named "do*" are explicitly handled in servlet classes.</p>
-<h3>Noncompliant code example</h3>
+<p>Servlets are components in Java web development, responsible for processing HTTP requests and generating responses. In this context, exceptions are
+used to handle and manage unexpected errors or exceptional conditions that may occur during the execution of a servlet.</p>
+<p>Catching exceptions within the servlet allows us to convert them into meaningful, user-friendly messages. Otherwise, failing to catch exceptions
+will propagate them to the servlet container, where the default error-handling mechanism may impact the overall security and stability of the
+server.</p>
+<p>Possible security problems are:</p>
+<ol>
+  <li> <strong>Vulnerability to denial-of-service attacks:</strong> Not caught exceptions can leave the servlet container in an unstable state, which
+  can exhaust the available resources and make the system unavailable in the worst cases. </li>
+  <li> <strong>Exposure of sensitive information:</strong> Exceptions handled by the servlet container, by default, expose detailed error messages or
+  debugging information to the user, which may contain sensitive data such as stack traces, database connection, or system configuration. </li>
+</ol>
+<p>Unfortunately, servlet method signatures do not force developers to handle <code>IOException</code> and <code>ServletException</code>:</p>
 <pre>
-public void doGet(HttpServletRequest request, HttpServletResponse response)
-  throws IOException, ServletException {
-  String ip = request.getRemoteAddr();
-  InetAddress addr = InetAddress.getByName(ip); // Noncompliant; getByName(String) throws UnknownHostException
+public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException {
+}
+</pre>
+<p>To prevent this risk, this rule enforces all exceptions to be caught within the "do*" methods of servlet classes.</p>
+<h2>How to fix it</h2>
+<p>Surround all method calls that may throw an exception with a <code>try/catch</code> block.</p>
+<h3>Code examples</h3>
+<p>In the following example, the <code>getByName</code> method may throw an <code>UnknownHostException</code>.</p>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="1" data-diff-type="noncompliant">
+public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException {
+  InetAddress addr = InetAddress.getByName(request.getRemoteAddr()); // Noncompliant
   //...
 }
 </pre>
-<h3>Compliant solution</h3>
-<pre>
-public void doGet(HttpServletRequest request, HttpServletResponse response)
-  throws IOException, ServletException {
+<h4>Compliant solution</h4>
+<pre data-diff-id="1" data-diff-type="compliant">
+public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException {
   try {
-    String ip = request.getRemoteAddr();
-    InetAddress addr = InetAddress.getByName(ip);
+    InetAddress addr = InetAddress.getByName(request.getRemoteAddr());
     //...
   }
-  catch (UnknownHostException uhex) {
+  catch (UnknownHostException ex) {  // Compliant
     //...
   }
 }
 </pre>
 <h2>Resources</h2>
+<h3>Articles &amp; blog posts</h3>
 <ul>
   <li> <a href="https://www.owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data
   Exposure </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2055.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2055.html
index 66c20ae8a49..fc5f9c50de9 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2055.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2055.html
@@ -1,50 +1,171 @@
 <h2>Why is this an issue?</h2>
-<p>When a <code>Serializable</code> object has a non-serializable ancestor in its inheritance chain, object deserialization (re-instantiating the
-object from file) starts at the first non-serializable class, and proceeds down the chain, adding the properties of each subsequent child class, until
-the final object has been instantiated.</p>
-<p>In order to create the non-serializable ancestor, its no-argument constructor is called. Therefore the non-serializable ancestor of a
-<code>Serializable</code> class must have a no-arg constructor. Otherwise the class is <code>Serializable</code> but not deserializable.</p>
-<h3>Noncompliant code example</h3>
+<p>Java serialization is the conversion from objects to byte streams for storage or transmission. And later, java deserialization is the reverse
+conversion, it reconstructs objects from byte streams.</p>
+<p>To make a java class serializable, this class should implement the <code>java.io.Serializable</code> interface directly or through its
+inheritance.</p>
 <pre>
-public class Fruit {
-  private Season ripe;
+import java.io.Serializable;
 
-  public Fruit (Season ripe) {...}
-  public void setRipe(Season ripe) {...}
-  public Season getRipe() {...}
+public class NonSerializableClass {
 }
 
-public class Raspberry extends Fruit
-        implements Serializable {  // Noncompliant; nonserializable ancestor doesn't have no-arg constructor
-  private static final long serialVersionUID = 1;
-
-  private String variety;
+public class SerializableClass implements Serializable {
+}
 
-  public Raspberry(Season ripe, String variety) { ...}
-  public void setVariety(String variety) {...}
-  public String getVarity() {...}
+public class OtherSerializableClass extends SerializableClass {
+  // is also serializable because it is a subtype of Serializable
 }
 </pre>
-<h3>Compliant solution</h3>
+<p>Given a serializable class, it is important to note that not all its superclasses are serializable. Eventually, its superclasses stop implementing
+<code>java.io.Serializable</code>. It could be at the end, once reaching the <code>java.lang.Object</code> class, or before.</p>
+<p>This is important because the serialization/deserialization runs through the class hierarchy of an object to decide which object fields to write or
+read, and applies two different logics:</p>
+<ul>
+  <li> When the class is serializable:
+    <ul>
+      <li> Serialization saves the class reference and the object fields of this class. </li>
+      <li> Deserialization instantiates a new object of this class without using a constructor, and restores the object fields of this class. </li>
+    </ul>  </li>
+  <li> When the class is not serializable:
+    <ul>
+      <li> Serialization only saves the class reference and <strong>ignores</strong> the object fields of this class. </li>
+      <li> Deserialization instantiates a new object of this class using the <strong>no-argument constructor</strong> and does not restore the object
+      fields of this class. </li>
+    </ul>  </li>
+</ul>
+<p>So developers should pay particular attention to the non-serializable classes in the class hierarchy, because the presence of an implicit or
+explicit <strong>no-argument constructor</strong> is required in those classes.</p>
+<p>This is an example of mandatory no-argument constructors in the hierarchy of <code>SerializableClass</code>:</p>
 <pre>
-public class Fruit {
-  private Season ripe;
+public class NonSerializableClassWithoutConstructor {
+  // after deserialization, "field1" will always be set to 42
+  private int field1 = 42;
 
-  public Fruit () {...};  // Compliant; no-arg constructor added to ancestor
-  public Fruit (Season ripe) {...}
-  public void setRipe(Season ripe) {...}
-  public Season getRipe() {...}
+  // this non-serializable class has an implicit no-argument constructor
 }
 
-public class Raspberry extends Fruit
-        implements Serializable {
-  private static final long serialVersionUID = 1;
+public class NonSerializableClass extends NonSerializableClassWithoutConstructor {
+  // after deserialization, "field2" will always be set to 12 by the no-argument constructor
+  private int field2;
 
-  private String variety;
+  // this non-serializable class has an explicit no-argument constructor
+  public NonSerializableClass() {
+    field2 = 12;
+  }
+
+  public NonSerializableClass(int field2) {
+    this.field2 = field2;
+  }
+}
 
-  public Raspberry(Season ripe, String variety) {...}
-  public void setVariety(String variety) {...}
-  public String getVarity() {...}
+public class SerializableClass extends NonSerializableClass implements Serializable {
+  // after deserialization, "field3" will have the previously serialized value.
+  private int field3;
+
+  // deserialization does not use declared constructors
+  public SerializableClass(int field3) {
+    super(field3 * 2);
+    this.field3 = field3;
+  }
+}
+</pre>
+<p>Unfortunately, there is no compilation error when a class implements <code>java.io.Serializable</code> and extends a non-serializable superclass
+without a no-argument constructor. This is an issue because, at runtime, deserialization will fail to find the required constructor.</p>
+<p>For example, deserialization of an instance of the following <code>SerializableClass</code> class, throws an <code>InvalidClassException: no valid
+constructor</code>.</p>
+<pre>
+public class NonSerializableClass {
+  private int field;
+  // this class can not be deserialized because it does not have any implicit or explicit no-argument constructor
+  public NonSerializableClass(int field) {
+    this.field = field;
+  }
+}
+
+public class SerializableClass extends NonSerializableClass implements Serializable {
+}
+</pre>
+<p>This rule checks in the hierarchy of serializable classes and reports an issue when a non-serializable superclass does not have the required
+no-argument constructor which will produce a runtime error.</p>
+<h2>How to fix it</h2>
+<p>There are two solutions to fix the missing <strong>no-argument constructor</strong> issue on non-serializable classes:</p>
+<ul>
+  <li> <code>Solution 1</code> If the fields of a non-serializable class need to be persisted, add the <code>java.io.Serializable</code> interface to
+  the class <code>implements</code> definition. </li>
+  <li> <code>Solution 2</code> Otherwise, add a no-argument constructor and initialize the fields with some valid default values. </li>
+</ul>
+<h3>Code examples</h3>
+<p><strong>Example #1</strong></p>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="1" data-diff-type="noncompliant">
+// Noncompliant; this Raspberry's ancestor doesn't have a no-argument constructor
+// this rule raises an issue on the Raspberry class declaration
+public class Fruit {
+  private Season pickingSeason;
+  public Fruit(Season pickingSeason) {
+    this.pickingSeason = pickingSeason;
+  }
+}
+</pre>
+<pre>
+public class Raspberry extends Fruit implements Serializable {
+  private static final long serialVersionUID = 1;
+  private String variety;
+  public Raspberry(String variety) {
+    super(Season.SUMMER);
+    this.variety = variety;
+  }
+}
+</pre>
+<h4>Compliant solution</h4>
+<p><code>Solution 1</code></p>
+<pre data-diff-id="1" data-diff-type="compliant">
+// Compliant; this Raspberry's ancestor is serializable
+public class Fruit implements Serializable {
+  private static final long serialVersionUID = 1;
+  private Season pickingSeason;
+  public Fruit(Season pickingSeason) {
+    this.pickingSeason = pickingSeason;
+  }
+}
+</pre>
+<p><strong>Example #2</strong></p>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="2" data-diff-type="noncompliant">
+public class Fruit {
+  // Noncompliant; this Raspberry's ancestor doesn't have a no-argument constructor
+  // this rule raises an issue on the Raspberry class declaration
+  public Fruit(String debugMessage) {
+    LOG.debug(debugMessage);
+  }
+}
+</pre>
+<pre>
+public class Raspberry extends Fruit implements Serializable {
+  private static final long serialVersionUID = 1;
+  private String variety;
+  public Raspberry(String variety) {
+    super("From Raspberry constructor");
+    this.variety = variety;
+  }
+}
+</pre>
+<h4>Compliant solution</h4>
+<p><code>Solution 2</code></p>
+<pre data-diff-id="2" data-diff-type="compliant">
+public class Fruit {
+  // Compliant; this Raspberry ancestor has a no-argument constructor
+  public Fruit() {
+    this("From serialization");
+  }
+  public Fruit(String debugMessage) {
+    LOG.debug(debugMessage);
+  }
 }
 </pre>
+<h2>Resources</h2>
+<h3>Documentation</h3>
+<ul>
+  <li> <a href="https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/io/Serializable.html">Oracle SDK - java.io.Serializable</a> </li>
+</ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2060.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2060.html
index 34287dc0e0c..e6dd55e175c 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2060.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2060.html
@@ -1,20 +1,73 @@
 <h2>Why is this an issue?</h2>
-<p>An <code>Externalizable</code> class is one which handles its own <code>Serialization</code> and deserialization. During deserialization, the first
-step in the process is a default instantiation using the class' no-argument constructor. Therefore an <code>Externalizable</code> class without a
-no-arg constructor cannot be deserialized.</p>
-<h3>Noncompliant code example</h3>
-<pre>
-public class Tomato implements Externalizable {  // Noncompliant; no no-arg constructor
-
-  public Tomato (String color, int weight) { ... }
+<p>A class that implements <code>java.io.Externalizable</code> is a class that provides a way to customize the serialization and deserialization,
+allowing greater control over how the object’s state is written or read.</p>
+<p>The first step of the deserialization process is to call the class' no-argument constructor before the <code>readExternal(ObjectInput in)</code>
+method.</p>
+<p>An implicit default no-argument constructor exists on a class when no constructor is explicitly defined within the class. But this implicit
+constructor does not exist when any constructor is explicitly defined, and in this case, we should always ensure that one of the constructors has
+no-argument.</p>
+<p>It is an issue if the implicit or explicit no-argument constructor is missing or not public, because the deserialization will fail and throw an
+<code>InvalidClassException: no valid constructor.</code>.</p>
+<h2>How to fix it</h2>
+<p>This issue can be fixed by:</p>
+<ul>
+  <li> Adding an explicit public no-argument constructor. </li>
+  <li> Or if all constructors can be removed, remove all constructors to benefit of the default implicit no-argument constructor. </li>
+</ul>
+<h3>Code examples</h3>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="1" data-diff-type="noncompliant">
+public class Tomato implements Externalizable {
+
+  public Color color;
+
+  // Noncompliant; because of this constructor there is no implicit no-argument constructor,
+  // deserialization will fail
+  public Tomato(Color color) {
+    this.color = color;
+  }
+
+  @Override
+  public void writeExternal(ObjectOutput out) throws IOException {
+    out.writeUTF(color.name());
+  }
+
+  @Override
+  public void readExternal(ObjectInput in) throws IOException {
+    color = Color.valueOf(in.readUTF());
+  }
 }
 </pre>
-<h3>Compliant solution</h3>
-<pre>
+<h4>Compliant solution</h4>
+<pre data-diff-id="1" data-diff-type="compliant">
 public class Tomato implements Externalizable {
 
-  public Tomato() { ... }
-  public Tomato (String color, int weight) { ... }
+  public Color color;
+
+  // Compliant; deserialization will invoke this public no-argument constructor
+  public Tomato() {
+    this.color = Color.UNKNOWN;
+  }
+
+  public Tomato(Color color) {
+    this.color = color;
+  }
+
+  @Override
+  public void writeExternal(ObjectOutput out) throws IOException {
+    out.writeUTF(color.name());
+  }
+
+  @Override
+  public void readExternal(ObjectInput in) throws IOException {
+    color = Color.valueOf(in.readUTF());
+  }
 }
 </pre>
+<h2>Resources</h2>
+<h3>Documentation</h3>
+<ul>
+  <li> <a href="https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/io/Externalizable.html">Oracle SDK - java.io.Externalizable</a>
+  </li>
+</ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2068.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2068.html
index 4ba14cc8434..f48b0a99ece 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2068.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2068.html
@@ -27,14 +27,14 @@ <h2>Sensitive Code Example</h2>
 String username = "steve";
 String password = "blue";
 Connection conn = DriverManager.getConnection("jdbc:mysql://localhost/test?" +
-                  "user=" + uname + "&amp;password=" + password); // Sensitive
+                  "user=" + username + "&amp;password=" + password); // Sensitive
 </pre>
 <h2>Compliant Solution</h2>
 <pre>
 String username = getEncryptedUser();
 String password = getEncryptedPassword();
 Connection conn = DriverManager.getConnection("jdbc:mysql://localhost/test?" +
-                  "user=" + uname + "&amp;password=" + password);
+                  "user=" + username + "&amp;password=" + password);
 </pre>
 <h2>See</h2>
 <ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2111.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2111.html
index bf1486fc7f6..dd1885064aa 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2111.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2111.html
@@ -1,32 +1,34 @@
 <h2>Why is this an issue?</h2>
-<p>Because of floating point imprecision, you’re unlikely to get the value you expect from the <code>BigDecimal(double)</code> constructor.</p>
-<p>From <a href="http://docs.oracle.com/javase/7/docs/api/java/math/BigDecimal.html#BigDecimal(double)">the JavaDocs</a>:</p>
-<blockquote>
-  <p>The results of this constructor can be somewhat unpredictable. One might assume that writing new BigDecimal(0.1) in Java creates a BigDecimal
-  which is exactly equal to 0.1 (an unscaled value of 1, with a scale of 1), but it is actually equal to
-  0.1000000000000000055511151231257827021181583404541015625. This is because 0.1 cannot be represented exactly as a double (or, for that matter, as a
-  binary fraction of any finite length). Thus, the value that is being passed in to the constructor is not exactly equal to 0.1, appearances
-  notwithstanding.</p>
-</blockquote>
-<p>Instead, you should use <code>BigDecimal.valueOf</code>, which uses a string under the covers to eliminate floating point rounding errors, or the
-constructor that takes a <code>String</code> argument.</p>
-<h3>Noncompliant code example</h3>
-<pre>
+<p>The <code>BigDecimal</code> is used to represents immutable, arbitrary-precision signed decimal numbers.</p>
+<p>Differently from the <code>BigDecimal</code>, the <code>double</code> primitive type and the <code>Double</code> type have limited precision due to
+the use of double-precision 64-bit IEEE 754 floating point. Because of floating point imprecision, the <code>BigDecimal(double)</code> constructor can
+be somewhat unpredictable.</p>
+<p>For example writing <code>new BigDecimal(0.1)</code> doesn’t create a BigDecimal which is exactly equal to 0.1, but it is equal to
+0.1000000000000000055511151231257827021181583404541015625. This is because 0.1 cannot be represented exactly as a double (or, for that matter, as a
+binary fraction of any finite length).</p>
+<h2>How to fix it</h2>
+<p>Use <code>BigDecimal.valueOf</code>, which uses a string under the covers to eliminate floating point rounding errors, or the constructor that
+takes a <code>String</code> argument.</p>
+<h3>Code examples</h3>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="1" data-diff-type="noncompliant">
 double d = 1.1;
 
-BigDecimal bd1 = new BigDecimal(d); // Noncompliant; see comment above
-BigDecimal bd2 = new BigDecimal(1.1); // Noncompliant; same result
+BigDecimal bd1 = new BigDecimal(d);   // Noncompliant
+BigDecimal bd2 = new BigDecimal(1.1); // Noncompliant
 </pre>
-<h3>Compliant solution</h3>
-<pre>
+<h4>Compliant solution</h4>
+<pre data-diff-id="1" data-diff-type="compliant">
 double d = 1.1;
 
-BigDecimal bd1 = BigDecimal.valueOf(d);
-BigDecimal bd2 = new BigDecimal("1.1"); // using String constructor will result in precise value
+BigDecimal bd1 = BigDecimal.valueOf(d); // Compliant
+BigDecimal bd2 = new BigDecimal("1.1"); // Compliant
 </pre>
 <h2>Resources</h2>
+<h3>Documentation</h3>
 <ul>
-  <li> <a href="https://wiki.sei.cmu.edu/confluence/x/kzdGBQ">CERT, NUM10-J.</a> - Do not construct BigDecimal objects from floating-point literals
+  <li> <a href="https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/math/BigDecimal.html">Oracle - BigDecimal</a> </li>
+  <li> <a href="https://wiki.sei.cmu.edu/confluence/x/kzdGBQ">CERT, NUM10-J</a> - Do not construct BigDecimal objects from floating-point literals
   </li>
 </ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2112.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2112.html
index 73c609cd7ad..4e60aa070d3 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2112.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2112.html
@@ -1,32 +1,41 @@
 <h2>Why is this an issue?</h2>
-<p>The <code>equals</code> and <code>hashCode</code> methods of <code>java.net.URL</code> both may trigger a name service (usually DNS) lookup to
-resolve the host name or IP address. Depending on the configuration, and network status, that can take a long time. <code>URI</code> on the other hand
-makes no such calls and should be used instead unless the specific <code>URL</code> functionality is required.</p>
-<p>In general it is better to use the <code>URI</code> class until access to the resource is actually needed, at which point you can just convert the
+<p>The <code>equals</code> and <code>hashCode</code> methods of <code>java.net.URL</code> may trigger a name service lookup (typically DNS) to resolve
+the hostname or IP address. Depending on the configuration, and network status, this lookup can be time-consuming.</p>
+<p>On the other hand, the <code>URI</code> class does not perform such lookups and is a better choice unless you specifically require the
+functionality provided by <code>URL</code>.</p>
+<p>In general, it is better to use the <code>URI</code> class until access to the resource is actually needed, at which point you can convert the
 <code>URI</code> to a <code>URL</code> using <code>URI.toURL()</code>.</p>
 <p>This rule checks for uses of <code>URL</code> 's in <code>Map</code> and <code>Set</code> , and for explicit calls to the <code>equals</code> and
-<code>hashCode</code> methods.</p>
-<h3>Noncompliant code example</h3>
-<pre>
+<code>hashCode</code> methods. It suggests reconsidering the use of <code>URL</code> in such scenarios to avoid potential performance issues related
+to name service lookups.</p>
+<h2>How to fix it</h2>
+<p>Use the <code>URI</code> class until access to the resource is actually needed.</p>
+<h3>Code examples</h3>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="1" data-diff-type="noncompliant">
 public void checkUrl(URL url) {
-  Set&lt;URL&gt; sites = new HashSet&lt;URL&gt;();  // Noncompliant
+  Set&lt;URL&gt; sites = new HashSet&lt;URL&gt;();               // Noncompliant
 
   URL homepage = new URL("http://sonarsource.com");  // Compliant
-  if (homepage.equals(url)) { // Noncompliant
+  if (homepage.equals(url)) {                        // Noncompliant
     // ...
   }
 }
 </pre>
-<h3>Compliant solution</h3>
-<pre>
+<h4>Compliant solution</h4>
+<pre data-diff-id="1" data-diff-type="compliant">
 public void checkUrl(URL url) {
-  Set&lt;URI&gt; sites = new HashSet&lt;URI&gt;();  // Compliant
+  Set&lt;URI&gt; sites = new HashSet&lt;URI&gt;();               // Compliant
 
   URI homepage = new URI("http://sonarsource.com");  // Compliant
   URI uri = url.toURI();
-  if (homepage.equals(uri)) {  // Compliant
+  if (homepage.equals(uri)) {                        // Compliant
     // ...
   }
 }
 </pre>
+<h2>Resources</h2>
+<ul>
+  <li> <a href="https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/net/URL.html">Oracle Java SE - java.net.URL</a> </li>
+</ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2114.json b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2114.json
index 6a89ec2950a..ebf28dd9b6b 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2114.json
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2114.json
@@ -11,5 +11,5 @@
   "ruleSpecification": "RSPEC-2114",
   "sqKey": "S2114",
   "scope": "All",
-  "quickfix": "unknown"
+  "quickfix": "infeasible"
 }
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2116.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2116.html
index fe09a2b4faf..0a8e6929451 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2116.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2116.html
@@ -1,19 +1,37 @@
 <h2>Why is this an issue?</h2>
-<p>While <code>hashCode</code> and <code>toString</code> are available on arrays, they are largely useless. <code>hashCode</code> returns the array’s
-"identity hash code", and <code>toString</code> returns nearly the same value. Neither method’s output actually reflects the array’s contents.
-Instead, you should pass the array to the relevant static <code>Arrays</code> method.</p>
-<h3>Noncompliant code example</h3>
-<pre>
-public static void main( String[] args )
-{
-    String argStr = args.toString(); // Noncompliant
-    int argHash = args.hashCode(); // Noncompliant
+<p>The purpose of the <code>hashCode</code> method is to return a hash code based on the contents of the object. Similarly, the purpose of the
+<code>toString</code> method is to provide a textual representation of the object’s contents.</p>
+<p>Calling <code>hashCode()</code> and <code>toString()</code> directly on array instances should be avoided because the default implementations
+provided by the <code>Object</code> class do not provide meaningful results for arrays. <code>hashCode()</code> returns the array’s "identity hash
+code", and <code>toString()</code> returns nearly the same value. Neither method’s output reflects the array’s contents.</p>
+<h2>How to fix it</h2>
+<p>Use relevant static <code>Arrays</code> method.</p>
+<ul>
+  <li> <code>Arrays.hashCode</code> or <code>Arrays.deepHashCode</code> </li>
+  <li> <code>Arrays.toString</code> or <code>Arrays.deepToString</code> </li>
+</ul>
+<h3>Code examples</h3>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="1" data-diff-type="noncompliant">
+public static void main(String[] args) {
+    String argStr = args.toString();       // Noncompliant
+    int argHash = args.hashCode();         // Noncompliant
+}
 </pre>
-<h3>Compliant solution</h3>
-<pre>
-public static void main( String[] args )
-{
-    String argStr = Arrays.toString(args);
-    int argHash = Arrays.hashCode(args);
+<h4>Compliant solution</h4>
+<pre data-diff-id="1" data-diff-type="compliant">
+public static void main(String[] args) {
+    String argStr = Arrays.toString(args); // Compliant
+    int argHash = Arrays.hashCode(args);   // Compliant
+}
 </pre>
+<h2>Resources</h2>
+<h3>Documentation</h3>
+<ul>
+  <li> <a href="https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/util/Arrays.html">Oracle Java SE - Arrays API</a> </li>
+</ul>
+<h3>Articles &amp; blog posts</h3>
+<ul>
+  <li> <a href="https://github.com/google/error-prone/blob/master/docs/bugpattern/ArrayHashCode.md">Error Prone - ArrayHashCode</a> </li>
+</ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2118.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2118.html
index 2db349b4c2f..586b554fb36 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2118.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2118.html
@@ -1,36 +1,42 @@
 <h2>Why is this an issue?</h2>
-<p>Nothing in a non-serializable class will be written out to file, and attempting to serialize such a class will result in an exception being thrown.
-Only a class that <code>implements Serializable</code> or one that extends such a class can successfully be serialized (or de-serialized).</p>
-<h3>Noncompliant code example</h3>
-<pre>
-public class Vegetable {  // neither implements Serializable nor extends a class that does
-  //...
+<p>Serialization is a platform-independent mechanism for writing the state of an object into a byte-stream. For serializing the object, we call the
+<code>writeObject()</code> method of <code>java.io.ObjectOutputStream</code> class. Only classes that implement <code>Serializable</code> or extend a
+class that does it can successfully be serialized (or de-serialized).</p>
+<p>Attempting to write a class with the <code>writeObject</code> method of the <code>ObjectOutputStream</code> class that does not implement
+<code>Serializable</code> or extends a class that implements it, will throw an <code>IOException</code>.</p>
+<h2>How to fix it</h2>
+<p>The object class passed as an argument to the <code>writeObject</code> must implement <code>Serializable</code>.</p>
+<h3>Code examples</h3>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="1" data-diff-type="noncompliant">
+public class Vegetable {
+  // ...
 }
 
 public class Menu {
-  public void meal() throws IOException {
-    Vegetable veg;
-    //...
-    FileOutputStream fout = new FileOutputStream(veg.getName());
-    ObjectOutputStream oos = new ObjectOutputStream(fout);
-    oos.writeObject(veg);  // Noncompliant. Nothing will be written
+  public void meal(ObjectOutputStream oos) throws IOException {
+    Vegetable veg = new Vegetable();
+    oos.writeObject(veg);  // Noncompliant
   }
 }
 </pre>
-<h3>Compliant solution</h3>
-<pre>
-public class Vegetable implements Serializable {  // can now be serialized
-  //...
+<h4>Compliant solution</h4>
+<pre data-diff-id="1" data-diff-type="compliant">
+public class Vegetable implements Serializable {
+  // ...
 }
 
 public class Menu {
-  public void meal() throws IOException {
-    Vegetable veg;
-    //...
-    FileOutputStream fout = new FileOutputStream(veg.getName());
-    ObjectOutputStream oos = new ObjectOutputStream(fout);
+  public void meal(ObjectOutputStream oos) throws IOException {
+    Vegetable veg = new Vegetable();
     oos.writeObject(veg);
   }
 }
 </pre>
+<h2>Resources</h2>
+<ul>
+  <li> <a href="https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/io/Serializable.html">Oracle Java SE - Serializable</a> </li>
+  <li> <a href="https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/io/ObjectOutputStream.html">Oracle Java SE - ObjectOutputStream</a>
+  </li>
+</ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2118.json b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2118.json
index 37552c4ca1b..895eb796f81 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2118.json
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2118.json
@@ -1,5 +1,5 @@
 {
-  "title": "Non-serializable classes should not be written",
+  "title": "\"writeObject\" argument must implement \"Serializable\"",
   "type": "BUG",
   "status": "ready",
   "remediation": {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2119.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2119.html
index 13188fa3d02..b560c15161f 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2119.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2119.html
@@ -1,30 +1,44 @@
 <h2>Why is this an issue?</h2>
-<p>Creating a new <code>Random</code> object each time a random value is needed is inefficient and may produce numbers which are not random depending
-on the JDK. For better efficiency and randomness, create a single <code>Random</code>, then store, and reuse it.</p>
-<p>The <code>Random()</code> constructor tries to set the seed with a distinct value every time. However there is no guarantee that the seed will be
-random or even uniformly distributed. Some JDK will use the current time as seed, which makes the generated numbers not random at all.</p>
+<p>Creating a new <code>Random</code> object each time a random value is needed is inefficient and may produce numbers that are not random, depending
+on the JDK. For better efficiency and randomness, create a single <code>Random</code>, store it, and reuse it.</p>
+<p>The <code>Random()</code> constructor tries to set the seed with a distinct value every time. However, there is no guarantee that the seed will be
+randomly or uniformly distributed. Some JDK will use the current time as seed, making the generated numbers not random.</p>
 <p>This rule finds cases where a new <code>Random</code> is created each time a method is invoked.</p>
-<h3>Noncompliant code example</h3>
-<pre>
-public void doSomethingCommon() {
-  Random rand = new Random();  // Noncompliant; new instance created with each invocation
-  int rValue = rand.nextInt();
-  //...
+<h3>Exceptions</h3>
+<p>This rule doesn’t apply to classes that use a <code>Random</code> in their constructors or the static <code>main</code> function and nowhere
+else.</p>
+<h2>How to fix it</h2>
+<p>Define and reuse the <code>Random</code> object.</p>
+<h3>Code examples</h3>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="1" data-diff-type="noncompliant">
+class MyClass {
+
+    public void doSomethingCommon() {
+      Random random = new Random();        // Noncompliant - new instance created with each invocation
+      int rValue = random.nextInt();
+    }
+}
 </pre>
-<h3>Compliant solution</h3>
-<pre>
-private Random rand = SecureRandom.getInstanceStrong();  // SecureRandom is preferred to Random
+<h4>Compliant solution</h4>
+<pre data-diff-id="1" data-diff-type="compliant">
+class MyClass {
+    private Random random = new Random();  // Compliant
 
-public void doSomethingCommon() {
-  int rValue = this.rand.nextInt();
-  //...
+    public void doSomethingCommon() {
+      int rValue = this.random.nextInt();
+    }
+}
 </pre>
-<h3>Exceptions</h3>
-<p>A class which uses a <code>Random</code> in its constructor or in a static <code>main</code> function and nowhere else will be ignored by this
-rule.</p>
 <h2>Resources</h2>
+<h3>Documentation</h3>
+<ul>
+  <li> <a href="https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/util/Random.html">Oracle Java SE - Random</a> </li>
+</ul>
+<h3>Articles &amp; blog posts</h3>
 <ul>
   <li> <a href="https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
   Misconfiguration </li>
+  <li> <a href="https://www.baeldung.com/java-generating-random-numbers">Baeldung - generating random number</a> </li>
 </ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2121.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2121.html
index 6041f3c22d1..06fa3f2e804 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2121.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2121.html
@@ -1,25 +1,41 @@
 <h2>Why is this an issue?</h2>
-<p>Creating a substring from 0 to the end is silly. You’ll end up with the same string you started with. Using the value of <code>String.length</code>
-as either the start or end of a substring has similarly predictable results.</p>
-<p>Calling <code>String.contains</code> with the argument being identical to the String on which contains is invoked doesn’t make sense.</p>
-<h3>Noncompliant code example</h3>
-<pre>
-String speech = "Now is the time for all good people to come to the aid of their country.";
+<p>Operations performed on a string with predictable outcomes should be avoided. For example:</p>
+<ul>
+  <li> checking if a string contains itself </li>
+  <li> comparing a string with itself </li>
+  <li> matching a string against itself </li>
+  <li> creating a substring from 0 to the end of the string </li>
+  <li> creating a substring from the end of the string </li>
+  <li> replacing a string with itself </li>
+  <li> replacing a substring with the exact substring </li>
+</ul>
+<h2>How to fix it</h2>
+<p>Avoid performing the operation that has a predictable outcome.</p>
+<h3>Code examples</h3>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="1" data-diff-type="noncompliant">
+String speech = "SonarQube is the best static code analysis tool."
 
-String s1 = speech.substring(0); // Noncompliant. Yields the whole string
-String s2 = speech.substring(speech.length()); // Noncompliant. Yields "";
-String s3 = speech.substring(5,speech.length()); // Noncompliant. Use the 1-arg version instead
+String s1 = speech.substring(0); // Noncompliant - yields the whole string
+String s2 = speech.substring(speech.length()); // Noncompliant - yields "";
+String s3 = speech.substring(5, speech.length()); // Noncompliant - use the 1-arg version instead
 
-if (speech.contains(speech)) { // Noncompliant
- // always true
+if (speech.contains(speech)) { // Noncompliant - always true
+    // ...
 }
 </pre>
-<h3>Compliant solution</h3>
-<pre>
-String speech = "Now is the time for all good people to come to the aid of their country.";
+<h4>Compliant solution</h4>
+<pre data-diff-id="1" data-diff-type="compliant">
+String speech = "SonarQube is the best static code analysis tool."
 
 String s1 = speech;
 String s2 = "";
 String s3 = speech.substring(5);
+
+// ...
 </pre>
+<h2>Resources</h2>
+<ul>
+  <li> <a href="https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/String.html">Oracle Java SE - String</a> </li>
+</ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2121.json b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2121.json
index 58801a816f1..817b7c88181 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2121.json
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2121.json
@@ -1,5 +1,5 @@
 {
-  "title": "Silly String operations should not be made",
+  "title": "String operations with predictable outcomes should be avoided",
   "type": "BUG",
   "status": "ready",
   "remediation": {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2122.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2122.html
index 05008afddd1..1d1f7ac7b80 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2122.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2122.html
@@ -1,16 +1,35 @@
 <h2>Why is this an issue?</h2>
-<p><code>java.util.concurrent.ScheduledThreadPoolExecutor</code>'s pool is sized with <code>corePoolSize</code>, so setting <code>corePoolSize</code>
-to zero means the executor will have no threads and run nothing.</p>
-<p>This rule detects instances where <code>corePoolSize</code> is set to zero, via either its setter or the object constructor.</p>
+<p><code>ThreadPoolExecutor</code> is an object that efficiently manages and controls the execution of multiple tasks in a thread pool. A thread pool
+is a collection of pre-initialized threads ready to execute tasks. Instead of creating a new thread for each task, which can be costly in terms of
+system resources, a thread pool reuses existing threads.</p>
+<p><code>java.util.concurrent.ScheduledThreadPoolExecutor</code> is an extension of <code>ThreadPoolExecutor</code> that can additionally schedule
+commands to run after a given delay or to execute periodically.</p>
+<p><code>ScheduledThreadPoolExecutor</code> 's pool is sized with <code>corePoolSize</code>, so setting <code>corePoolSize</code> to zero means the
+executor will have no threads and run nothing. <code>corePoolSize</code> should have a value greater than zero and valid for your tasks.</p>
+<p>This rule detects instances where <code>corePoolSize</code> is set to zero via its setter or the object constructor.</p>
 <h3>Noncompliant code example</h3>
-<pre>
+<pre data-diff-id="1" data-diff-type="noncompliant">
 public void do(){
 
-  ScheduledThreadPoolExecutor stpe1 = new ScheduledThreadPoolExecutor(0); // Noncompliant
+  int poolSize = 5; // value greater than 0
 
-  ScheduledThreadPoolExecutor stpe2 = new ScheduledThreadPoolExecutor(POOL_SIZE);
-  stpe2.setCorePoolSize(0);  // Noncompliant
+  ScheduledThreadPoolExecutor threadPool1 = new ScheduledThreadPoolExecutor(0); // Noncompliant
 
-  ...
+  ScheduledThreadPoolExecutor threadPool2 = new ScheduledThreadPoolExecutor(poolSize);
+  threadPool2.setCorePoolSize(0);  // Noncompliant
+}
 </pre>
+<h2>Resources</h2>
+<h3>Documentation</h3>
+<ul>
+  <li> <a href="https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/util/concurrent/ScheduledThreadPoolExecutor.html">Oracle Java SE -
+  ScheduledThreadPoolExecutor</a> </li>
+</ul>
+<h3>Articles &amp; blog posts</h3>
+<ul>
+  <li> <a href="https://engineering.zalando.com/posts/2019/04/how-to-set-an-ideal-thread-pool-size.html">Zalando - How to set an ideal thread pool
+  size</a> </li>
+  <li> <a href="https://www.baeldung.com/java-threadpooltaskexecutor-core-vs-max-poolsize">Baeldung - ThreadPoolTaskExecutor corePoolSize vs.
+  maxPoolSize</a> </li>
+</ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2127.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2127.html
index aa458561775..39bf18bdae7 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2127.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2127.html
@@ -1,10 +1,27 @@
 <h2>Why is this an issue?</h2>
-<p><code>Double.longBitsToDouble</code> expects a 64-bit, <code>long</code> argument. Pass it a smaller value, such as an <code>int</code> and the
-mathematical conversion into a <code>double</code> simply won’t work as anticipated because the layout of the bits will be interpreted incorrectly, as
-if a child were trying to use an adult’s gloves.</p>
+<p><code>Double.longBitsToDouble</code> converts the bit pattern into its corresponding floating-point representation. The method expects a 64-bit
+long argument to interpret the bits as a double value correctly.</p>
+<p>When the argument is a smaller data type, the cast to <code>long</code> may lead to a different value than expected due to the interpretation of
+the most significant bit, which, in turn, results in <code>Double.longBitsToDouble</code> returning an incorrect value.</p>
 <h3>Noncompliant code example</h3>
-<pre>
-int i = 42;
-double d = Double.longBitsToDouble(i);  // Noncompliant
+<pre data-diff-id="1" data-diff-type="noncompliant">
+int i = 0x80003800;
+Double.longBitsToDouble(i);   // Noncompliant - NaN
 </pre>
+<h3>Compliant solution</h3>
+<pre data-diff-id="1" data-diff-type="compliant">
+long i = 0x80003800L;
+Double.longBitsToDouble(i);   // Compliant - 1.0610049784E-314
+</pre>
+<h2>Resources</h2>
+<h3>Documentation</h3>
+<ul>
+  <li> <a href="https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/Double.html#doubleToLongBits(double)">Oracle Java SE -
+  Double.doubleToLongBits</a> </li>
+</ul>
+<h3>Articles &amp; blog posts</h3>
+<ul>
+  <li> <a href="https://en.wikipedia.org/wiki/Double-precision_floating-point_format">Wikipedia - Double Precision floating point format</a> </li>
+  <li> <a href="https://en.wikipedia.org/wiki/Single-precision_floating-point_format">Wikipedia - Single Precision floating point format</a> </li>
+</ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2127.json b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2127.json
index 3f2ad266d3d..73547751877 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2127.json
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2127.json
@@ -1,5 +1,5 @@
 {
-  "title": "\"Double.longBitsToDouble\" should not be used for \"int\"",
+  "title": "\"Double.longBitsToDouble\" should take \"long\" as argument",
   "type": "BUG",
   "status": "ready",
   "remediation": {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2129.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2129.html
index 02c1af0a1dd..91a1bae125e 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2129.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2129.html
@@ -1,9 +1,9 @@
 <h2>Why is this an issue?</h2>
-<p>Constructors for <code>String</code>, <code>BigInteger</code>, <code>BigDecimal</code> and the objects used to wrap primitives should never be
-used. Doing so is less clear and uses more memory than simply using the desired value in the case of strings, and using <code>valueOf</code> for
-everything else.</p>
+<p>Calling constructors for <code>String</code>, <code>BigInteger</code>, <code>BigDecimal</code> and the objects used to wrap primitives is less
+efficient and less clear than relying on autoboxing or <code>valueOf</code>.</p>
+<p>Consider simplifying when possible for more efficient and cleaner code.</p>
 <h3>Noncompliant code example</h3>
-<pre>
+<pre data-diff-id="1" data-diff-type="noncompliant">
 String empty = new String(); // Noncompliant; yields essentially "", so just use that.
 String nonempty = new String("Hello world"); // Noncompliant
 Double myDouble = new Double(1.1); // Noncompliant; use valueOf
@@ -12,19 +12,26 @@ <h3>Noncompliant code example</h3>
 BigInteger bigInteger1 = new BigInteger("3"); // Noncompliant
 BigInteger bigInteger2 = new BigInteger("9223372036854775807"); // Noncompliant
 BigInteger bigInteger3 = new BigInteger("111222333444555666777888999"); // Compliant, greater than Long.MAX_VALUE
+BigDecimal bigDecimal = new BigDecimal("42.0"); // Compliant (see Exceptions section)
 </pre>
 <h3>Compliant solution</h3>
-<pre>
+<pre data-diff-id="1" data-diff-type="compliant">
 String empty = "";
 String nonempty = "Hello world";
-Double myDouble = Double.valueOf(1.1);
-Integer integer = Integer.valueOf(1);
-Boolean bool = Boolean.valueOf(true);
+Double myDouble = 1.1;
+Integer integer = 1;
+Boolean bool = true;
 BigInteger bigInteger1 = BigInteger.valueOf(3);
 BigInteger bigInteger2 = BigInteger.valueOf(9223372036854775807L);
 BigInteger bigInteger3 = new BigInteger("111222333444555666777888999");
+BigDecimal bigDecimal = new BigDecimal("42.0");
 </pre>
 <h3>Exceptions</h3>
-<p><code>BigDecimal</code> constructor with <code>double</code> argument is ignored as using <code>valueOf</code> instead might change resulting
-value. See {rule:java:S2111} .</p>
+<p><code>BigDecimal</code> constructor with a <code>double</code> argument is ignored as using <code>valueOf</code> instead might change the resulting
+value. See {rule:java:S2111}.</p>
+<h2>Resources</h2>
+<ul>
+  <li> <a href="https://docs.oracle.com/javase/tutorial/java/data/autoboxing.html">Oracle - Learning the Java Language</a> - Autoboxing and Unboxing
+  </li>
+</ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2130.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2130.html
index dbc3103791e..d8642f4c9f9 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2130.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2130.html
@@ -1,16 +1,18 @@
 <h2>Why is this an issue?</h2>
 <p>Rather than creating a boxed primitive from a <code>String</code> to extract the primitive value, use the relevant <code>parse</code> method
-instead. It will be clearer and more efficient.</p>
+instead. Using <code>parse</code> makes the code more efficient and the intent of the developer clearer.</p>
 <h3>Noncompliant code example</h3>
-<pre>
-String myNum = "12.2";
-
-float f = (new Float(myNum)).floatValue();  // Noncompliant; creates &amp; discards a Float
+<pre data-diff-id="1" data-diff-type="noncompliant">
+String myNum = "42.0";
+float myFloat = new Float(myNum);  // Noncompliant
+float myFloatValue = (new Float(myNum)).floatValue();  // Noncompliant
+int myInteger = Integer.valueOf(myNum); // Noncompliant
+int myIntegerValue = Integer.valueOf(myNum).intValue(); // Noncompliant
 </pre>
 <h3>Compliant solution</h3>
-<pre>
-String myNum = "12.2";
-
+<pre data-diff-id="1" data-diff-type="compliant">
+String myNum = "42.0";
 float f = Float.parseFloat(myNum);
+int myInteger = Integer.parseInt(myNum);
 </pre>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2133.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2133.html
index 7617d712fdd..3f10332abee 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2133.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2133.html
@@ -1,13 +1,13 @@
 <h2>Why is this an issue?</h2>
-<p>Creating an object for the sole purpose of calling <code>getClass</code> on it is a waste of memory and cycles. Instead, simply use the class'
+<p>Creating an object for the sole purpose of calling <code>getClass</code> on it is a waste of memory and cycles. Instead, simply use the class’s
 <code>.class</code> property.</p>
 <h3>Noncompliant code example</h3>
-<pre>
+<pre data-diff-id="1" data-diff-type="noncompliant">
 MyObject myOb = new MyObject();  // Noncompliant
 Class c = myOb.getClass();
 </pre>
 <h3>Compliant solution</h3>
-<pre>
+<pre data-diff-id="1" data-diff-type="compliant">
 Class c = MyObject.class;
 </pre>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2133.json b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2133.json
index 27b73662744..308005c67cb 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2133.json
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2133.json
@@ -1,5 +1,5 @@
 {
-  "title": "Objects should not be created only to \"getClass\"",
+  "title": "Objects should not be created only to invoke \"getClass\"",
   "type": "CODE_SMELL",
   "status": "ready",
   "remediation": {
@@ -13,5 +13,5 @@
   "ruleSpecification": "RSPEC-2133",
   "sqKey": "S2133",
   "scope": "All",
-  "quickfix": "unknown"
+  "quickfix": "targeted"
 }
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2134.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2134.html
index 027caa97e92..b8e1b91d708 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2134.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2134.html
@@ -1,30 +1,50 @@
 <h2>Why is this an issue?</h2>
-<p>According to the Java API documentation:</p>
-<blockquote>
-  <p>There are two ways to create a new thread of execution. One is to declare a class to be a subclass of Thread. This subclass should override the
-  run method of class Thread. An instance of the subclass can then be allocated and started…​</p>
-  <p>The other way to create a thread is to declare a class that implements the Runnable interface. That class then implements the run method. An
-  instance of the class can then be allocated, passed as an argument when creating Thread, and started.</p>
-</blockquote>
-<p>By definition, extending the Thread class without overriding the <code>run</code> method doesn’t make sense, and implies that the contract of the
-<code>Thread</code> class is not well understood.</p>
+<p>The default implementation of <code>java.lang.Thread</code> 's <code>run</code> will only perform a task passed as a <code>Runnable</code>. If no
+<code>Runnable</code> has been provided at construction time, then the thread will not perform any action.</p>
+<p>When extending <code>java.lang.Thread</code>, you should override the <code>run</code> method or pass a <code>Runnable</code> target to the
+constructor of <code>java.lang.Thread</code>.</p>
 <h3>Noncompliant code example</h3>
 <pre>
-public class MyRunner extends Thread { // Noncompliant; run method not overridden
-
-  public void doSometing() {...}
+public class MyThread extends Thread { // Noncompliant
+  public void doSomething() {
+    System.out.println("Hello, World!");
+  }
+}
+</pre>
+<h2>How to fix it</h2>
+<p>To fix this issue, you have 2 options:</p>
+<ul>
+  <li> override the <code>run</code> method </li>
+</ul>
+<pre>
+public class MyThread extends Thread {
+  @Override
+  public void run() {
+    System.out.println("Hello, World!");
+  }
 }
 </pre>
-<h3>Exceptions</h3>
-<p>If <code>run()</code> is not overridden in a class extending <code>Thread</code>, it means that starting the thread will actually call
-<code>Thread.run()</code>. However, <code>Thread.run()</code> does nothing if it has not been fed with a target <code>Runnable</code>. The rule
-consequently ignore classes extending <code>Thread</code> if they are calling, in their constructors, the <code>super(...)</code> constructor with a
-proper <code>Runnable</code> target.</p>
+<ul>
+  <li> provide a <code>Runnable</code> at construction time </li>
+</ul>
 <pre>
-class MyThread extends Thread { // Compliant - calling super constructor with a Runnable
-  MyThread(Runnable target) {
-    super(target); // calling super constructor with a Runnable, which will be used for when Thread.run() is executed
-    // ...
+public class MyRunnable implements Runnable {
+  @Override
+  public void run() {
+    System.out.println("Hello, World!");
+  }
+}
+public class MyThread extends Thread {
+  public MyThread(Runnable runnable) {
+    super(runnable);
+  }
+}
+
+public class Main() {
+  public static void main(String [] args) {
+    Runnable runnable = new MyRunnable();
+    Thread customThread = new MyThread(runnable);
+    Thread regularThread = new Thread(runnable);
   }
 }
 </pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2134.json b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2134.json
index 5d43190420c..d4ef3f7df21 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2134.json
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2134.json
@@ -1,5 +1,5 @@
 {
-  "title": "Classes extending java.lang.Thread should override the \"run\" method",
+  "title": "Classes extending java.lang.Thread should provide a specific \"run\" behavior",
   "type": "BUG",
   "status": "ready",
   "remediation": {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2140.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2140.html
index 6acc5369d3d..b60b403cfd7 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2140.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2140.html
@@ -1,17 +1,16 @@
 <h2>Why is this an issue?</h2>
-<p>There is no need to multiply the output of <code>Random</code>'s <code>nextDouble</code> method to get a random integer. Use the
-<code>nextInt</code> method instead.</p>
-<p>This rule raises an issue when the return value of any of <code>Random</code>'s methods that return a floating point value is converted to an
-integer.</p>
+<p>Generating random floating point values to cast them into integers is inefficient. A random bounded integer value can be generated with a single
+proper method call. Use <code>nextInt</code> to make the code more efficient and the intent clearer.</p>
 <h3>Noncompliant code example</h3>
-<pre>
+<pre data-diff-id="1" data-diff-type="noncompliant">
 Random r = new Random();
-int rand = (int)r.nextDouble() * 50;  // Noncompliant way to get a pseudo-random value between 0 and 50
-int rand2 = (int)r.nextFloat(); // Noncompliant; will always be 0;
+int rand = (int) (r.nextDouble() * 50);  // Noncompliant way to get a pseudo-random value between 0 and 50
+int rand2 = (int) r.nextFloat(); // Noncompliant; will always be 0;
 </pre>
 <h3>Compliant solution</h3>
-<pre>
+<pre data-diff-id="1" data-diff-type="compliant">
 Random r = new Random();
 int rand = r.nextInt(50);  // returns pseudo-random value between 0 and 50
+int rand2 = 0;
 </pre>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2140.json b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2140.json
index 4aac4a34250..564dd9fd630 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2140.json
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2140.json
@@ -7,7 +7,8 @@
     "constantCost": "5min"
   },
   "tags": [
-    "clumsy"
+    "clumsy",
+    "performance"
   ],
   "defaultSeverity": "Minor",
   "ruleSpecification": "RSPEC-2140",
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2142.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2142.html
index f3913c6f2fb..31074fcb10a 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2142.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2142.html
@@ -1,22 +1,17 @@
 <h2>Why is this an issue?</h2>
-<p><code>InterruptedExceptions</code> should never be ignored in the code, and simply logging the exception counts in this case as "ignoring". The
-throwing of the <code>InterruptedException</code> clears the interrupted state of the Thread, so if the exception is not handled properly the
-information that the thread was interrupted will be lost. Instead, <code>InterruptedExceptions</code> should either be rethrown - immediately or after
-cleaning up the method’s state - or the thread should be re-interrupted by calling <code>Thread.interrupt()</code> even if this is supposed to be a
-single-threaded application. Any other course of action risks delaying thread shutdown and loses the information that the thread was interrupted -
+<p>If an <code>InterruptedException</code> or a <code>ThreadDeath</code> error is not handled properly, the information that the thread was
+interrupted will be lost. Handling this exception means either to re-throw it or manually re-interrupt the current thread by calling
+<code>Thread.interrupt()</code>. Simply logging the exception is not sufficient and counts as ignoring it. Between the moment the exception is caught
+and handled, is the right time to perform cleanup operations on the method’s state, if needed.</p>
+<h3>What is the potential impact?</h3>
+<p>Failing to interrupt the thread (or to re-throw) risks delaying the thread shutdown and losing the information that the thread was interrupted -
 probably without finishing its task.</p>
-<p>Similarly, the <code>ThreadDeath</code> exception should also be propagated. According to its JavaDoc:</p>
-<blockquote>
-  <p>If <code>ThreadDeath</code> is caught by a method, it is important that it be rethrown so that the thread actually dies.</p>
-</blockquote>
 <h3>Noncompliant code example</h3>
 <pre>
 public void run () {
   try {
-    while (true) {
-      // do stuff
-    }
-  }catch (InterruptedException e) { // Noncompliant; logging is not enough
+    /*...*/
+  } catch (InterruptedException e) { // Noncompliant; logging is not enough
     LOGGER.log(Level.WARN, "Interrupted!", e);
   }
 }
@@ -25,15 +20,23 @@ <h3>Compliant solution</h3>
 <pre>
 public void run () {
   try {
-    while (true) {
-      // do stuff
-    }
-  }catch (InterruptedException e) {
+    /* ... */
+  } catch (InterruptedException e) { // Compliant; the interrupted state is restored
     LOGGER.log(Level.WARN, "Interrupted!", e);
-    // Restore interrupted state...
+    /* Clean up whatever needs to be handled before interrupting  */
     Thread.currentThread().interrupt();
   }
 }
+
+public void run () {
+  try {
+    /* ... */
+  } catch (ThreadDeath e) { // Compliant; the error is being re-thrown
+    LOGGER.log(Level.WARN, "Interrupted!", e);
+    /* Clean up whatever needs to be handled before re-throwing  */
+    throw e;
+  }
+}
 </pre>
 <h2>Resources</h2>
 <ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2142.json b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2142.json
index e412142c1f1..e6e2556e222 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2142.json
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2142.json
@@ -1,5 +1,5 @@
 {
-  "title": "\"InterruptedException\" should not be ignored",
+  "title": "\"InterruptedException\" and \"ThreadDeath\" should not be ignored",
   "type": "BUG",
   "status": "ready",
   "remediation": {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2151.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2151.html
index 0e1c1ebe6e0..a1bf2e51f86 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2151.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2151.html
@@ -1,33 +1,23 @@
 <h2>Why is this an issue?</h2>
-<p>Running finalizers on JVM exit is disabled by default. It can be enabled with <code>System.runFinalizersOnExit</code> and
-<code>Runtime.runFinalizersOnExit</code>, but both methods are deprecated because they are inherently unsafe.</p>
-<p>According to the Oracle Javadoc:</p>
-<blockquote>
-  <p>It may result in finalizers being called on live objects while other threads are concurrently manipulating those objects, resulting in erratic
-  behavior or deadlock.</p>
-</blockquote>
-<p>If you really want to execute something when the virtual machine begins its shutdown sequence, you should attach a shutdown hook.</p>
+<p>Enabling <code>runFinalizersOnExit</code> is unsafe as it might result in erratic behavior and deadlocks on application exit.</p>
+<p>Indeed, finalizers might be force-called on live objects while other threads are concurrently manipulating them.</p>
+<p>Instead, if you want to execute something when the virtual machine begins its shutdown sequence, you should attach a shutdown hook.</p>
 <h3>Noncompliant code example</h3>
-<pre>
+<pre data-diff-id="1" data-diff-type="noncompliant">
 public static void main(String [] args) {
-  ...
   System.runFinalizersOnExit(true);  // Noncompliant
-  ...
 }
 
 protected void finalize(){
-  doSomething();
+  doShutdownOperations();
 }
 </pre>
 <h3>Compliant solution</h3>
-<pre>
+<pre data-diff-id="1" data-diff-type="compliant">
 public static void main(String [] args) {
-  Runtime.addShutdownHook(new Runnable() {
-    public void run(){
-      doSomething();
-    }
-  });
-  //...
+  Thread myThread = new Thread( () -&gt; { doShutdownOperations(); });
+  Runtime.getRuntime().addShutdownHook(myThread);
+}
 </pre>
 <h2>Resources</h2>
 <ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2153.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2153.html
index 5d88d6e17d4..2e1dd0316b3 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2153.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2153.html
@@ -1,55 +1,55 @@
 <h2>Why is this an issue?</h2>
-<p>Boxing is the process of putting a primitive value into an analogous object, such as creating an <code>Integer</code> to hold an <code>int</code>
-value. Unboxing is the process of retrieving the primitive value from such an object.</p>
-<p>Since the original value is unchanged during boxing and unboxing, there’s no point in doing either when not needed. This also applies to autoboxing
-and auto-unboxing (when Java implicitly handles the primitive/object transition for you).</p>
+<p>Boxing is the process of putting a primitive value into a wrapper object, such as creating an <code>Integer</code> to hold an <code>int</code>
+value. Unboxing is the process of retrieving the primitive value from such an object. Since the original value is unchanged during boxing and
+unboxing, there is no point in doing either when not needed.</p>
+<p>Instead, you should rely on Java’s implicit boxing/unboxing to convert from the primitive type to the wrapper type and vice versa, for better
+readability.</p>
 <h3>Noncompliant code example</h3>
-<pre>
-public void examineInt(int a) {
+<pre data-diff-id="1" data-diff-type="noncompliant">
+public void examinePrimitiveInt(int a) {
   //...
 }
 
-public void examineInteger(Integer a) {
+public void examineBoxedInteger(Integer a) {
   // ...
 }
 
 public void func() {
-  int i = 0;
-  Integer iger1 = Integer.valueOf(0);
+  int primitiveInt = 0;
+  Integer boxedInt = Integer.valueOf(0);
   double d = 1.0;
 
-  int dIntValue = new Double(d).intValue(); // Noncompliant
+  int dIntValue = Double.valueOf(d).intValue(); // Noncompliant; should be replaced with a simple cast
 
-  examineInt(new Integer(i).intValue()); // Noncompliant; explicit box/unbox
-  examineInt(Integer.valueOf(i));  // Noncompliant; boxed int will be auto-unboxed
+  examinePrimitiveInt(boxedInt.intValue()); // Noncompliant; unnecessary unboxing
+  examinePrimitiveInt(Integer.valueOf(primitiveInt));  // Noncompliant; boxed int will be auto-unboxed
 
-  examineInteger(i); // Compliant; value is boxed but not then unboxed
-  examineInteger(iger1.intValue()); // Noncompliant; unboxed int will be autoboxed
-
-  Integer iger2 = new Integer(iger1); // Noncompliant; unnecessary unboxing, value can be reused
+  examineBoxedInteger(Integer.valueOf(primitiveInt)); // Noncompliant; unnecessary boxing
+  examineBoxedInteger(boxedInt.intValue()); // Noncompliant; unboxed int will be autoboxed
 }
 </pre>
 <h3>Compliant solution</h3>
-<pre>
-public void examineInt(int a) {
+<pre data-diff-id="1" data-diff-type="compliant">
+public void examinePrimitiveInt(int a) {
   //...
 }
 
-public void examineInteger(Integer a) {
+public void examineBoxedInteger(Integer a) {
   // ...
 }
 
 public void func() {
-  int i = 0;
-  Integer iger1 = Integer.valueOf(0);
+  int primitiveInt = 0;
+  Integer boxedInt = Integer.valueOf(0);
   double d = 1.0;
 
   int dIntValue = (int) d;
 
-  examineInt(i);
+  examinePrimitiveInt(primitiveInt);
+  examinePrimitiveInt(boxedInt);
 
-  examineInteger(i);
-  examineInteger(iger1);
+  examineBoxedInteger(primitiveInt);
+  examineBoxedInteger(boxedInt);
 }
 </pre>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2153.json b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2153.json
index 43c323826bb..055f052985c 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2153.json
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2153.json
@@ -1,5 +1,5 @@
 {
-  "title": "Boxing and unboxing should not be immediately reversed",
+  "title": "Unnecessary boxing and unboxing should be avoided",
   "type": "BUG",
   "status": "ready",
   "remediation": {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2157.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2157.html
index 37a7fa94c98..9d5c4bb2e12 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2157.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2157.html
@@ -1,32 +1,85 @@
+<p>This rule raises an issue when a class implements the interface <code>java.lang.Cloneable</code>, but does not override the
+<code>Object.clone()</code> method.</p>
 <h2>Why is this an issue?</h2>
-<p>Simply implementing <code>Cloneable</code> without also overriding <code>Object.clone()</code> does not necessarily make the class cloneable. While
-the <code>Cloneable</code> interface does not include a <code>clone</code> method, it is required by convention, and ensures true cloneability.
-Otherwise the default JVM <code>clone</code> will be used, which copies primitive values and object references from the source to the target. I.e.
-without overriding <code>clone</code>, any cloned instances will potentially share members with the source instance.</p>
-<p>Removing the <code>Cloneable</code> implementation and providing a good copy constructor is another viable (some say preferable) way of allowing a
-class to be copied.</p>
-<h3>Noncompliant code example</h3>
-<pre>
-class Team implements Cloneable {  // Noncompliant
-  private Person coach;
-  private List&lt;Person&gt; players;
-  public void addPlayer(Person p) {...}
-  public Person getCoach() {...}
+<p><code>Cloneable</code> is a <em>marker interface</em> that defines the contract of the <code>Object.clone</code> method, which is to create a
+consistent copy of the instance. The <code>clone</code> method is not defined by the interface though, but by class <code>Objects</code>.</p>
+<p>The general problem with marker interfaces is that their definitions cannot be enforced by the compiler because they have no own API. When a class
+implements <code>Cloneable</code> but does not override <code>Object.clone</code>, it is highly likely that it violates the contract for
+<code>Cloneable</code>.</p>
+<h2>How to fix it</h2>
+<p>Consider the following example:</p>
+<pre data-diff-id="1" data-diff-type="noncompliant">
+class Foo implements Cloneable { // Noncompliant, override `clone` method
+  public int value;
 }
 </pre>
-<h3>Compliant solution</h3>
-<pre>
-class Team implements Cloneable {
-  private Person coach;
-  private List&lt;Person&gt; players;
-  public void addPlayer(Person p) { ... }
-  public Person getCoach() { ... }
+<p>Override the <code>clone</code> method in class <code>Foo</code>. By convention, it must call <code>super.clone()</code>. At this point, we know
+that:</p>
+<ul>
+  <li> By behavioral contract, <code>Object.clone</code> will not throw a <code>CloneNotSupportedException</code>, because <code>Foo</code> implements
+  <code>Cloneable</code>. </li>
+  <li> The returned object is an instance of class <code>Foo</code> </li>
+</ul>
+<p>We can narrow down the return type of <code>clone</code> to <code>Foo</code> and handle the <code>CloneNotSupportedException</code> inside the
+function instead of throwing it:</p>
+<pre data-diff-id="1" data-diff-type="compliant">
+class Foo implements Cloneable { // Compliant
+
+  public int value;
+
+  @Override
+  public Foo clone() {
+    try {
+      return (Foo) super.clone();
+    } catch (CloneNotSupportedException e) {
+      throw new AssertionError();
+    }
+  }
+}
+</pre>
+<p>Be aware that <code>super.clone()</code> returns a one-by-one copy of the fields of the original instance. This means that in our example, the
+<code>Foo.value</code> field is not required to be explicitly copied in the overridden function.</p>
+<p>If you require another copy behavior for some or all of the fields, for example, deep copy or certain invariants that need to be true for a field,
+these fields must be patched after <code>super.clone()</code>:</p>
+<pre data-diff-id="1" data-diff-type="compliant">
+class Entity implements Cloneable {
+
+  public int id; // unique per instance
+  public List&lt;Entity&gt; children; // deep copy wanted
 
   @Override
-  public Object clone() {
-    Team clone = (Team) super.clone();
-    //...
+  public Entity clone() {
+    try {
+      Entity copy = (Entity) super.clone();
+      copy.id = System.identityHashCode(this);
+      copy.children = children.stream().map(Entity::clone).toList();
+      return copy;
+    } catch (CloneNotSupportedException e) {
+      throw new AssertionError();
+    }
+  }
+}
+</pre>
+<p>Be aware that the <code>Cloneable</code> / <code>Object.clone</code> approach has several drawbacks. You might, therefore, also consider resorting
+to other solutions, such as a custom <code>copy</code> method or a copy constructor:</p>
+<pre data-diff-id="1" data-diff-type="compliant">
+class Entity implements Cloneable {
+
+  public int id; // unique per instance
+  public List&lt;Entity&gt; children; // deep copy wanted
+
+  Entity(Entity template) {
+    id = System.identityHashCode(this);
+    children = template.children.stream().map(Entity::new).toList();
   }
 }
 </pre>
+<h2>Resources</h2>
+<h3>Documentation</h3>
+<ul>
+  <li> <a href="https://docs.oracle.com/javase/8/docs/api/java/lang/Cloneable.html">Interface Cloneable - Java™ Platform, Standard Edition 8 API
+  Specification</a> </li>
+  <li> <a href="https://docs.oracle.com/javase/8/docs/api/java/lang/Object.html#clone--">Object.clone - Java™ Platform, Standard Edition 8 API
+  Specification</a> </li>
+</ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2160.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2160.html
index c91e33ad9f5..47a27b456e3 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2160.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2160.html
@@ -1,69 +1,61 @@
+<p>This rule raises an issue when a subclass of a class that overrides <code>Object.equals</code> introduces new fields but does not also override the
+<code>Object.equals</code> method.</p>
 <h2>Why is this an issue?</h2>
-<p>Extend a class that overrides <code>equals</code> and add fields without overriding <code>equals</code> in the subclass, and you run the risk of
-non-equivalent instances of your subclass being seen as equal, because only the superclass fields will be considered in the equality test.</p>
-<p>This rule looks for classes that do all of the following:</p>
-<ul>
-  <li> extend classes that override <code>equals</code>. </li>
-  <li> do not themselves override <code>equals</code>. </li>
-  <li> add fields. </li>
-</ul>
-<h3>Noncompliant code example</h3>
+<p>When a class overrides <code>Object.equals</code>, this indicates that the class not just considers object identity as equal (the default
+implementation of <code>Object.equals</code>) but implements another logic for what is considered equal in the context of this class. Usually (but not
+necessarily), the semantics of <code>equals</code> in this case is that two objects are equal when their state is equal field by field.</p>
+<p>Because of this, adding new fields to a subclass of a class that overrides <code>Object.equals</code> but not updating the implementation of
+<code>equals</code> in the subclass is most likely an error.</p>
+<h2>How to fix it</h2>
+<p>Consider the following example:</p>
 <pre>
-public class Fruit {
-  private Season ripe;
+class Foo {
+
+  final int a;
 
-  public boolean equals(Object obj) {
-    if (obj == this) {
-      return true;
-    }
-    if (this.class != obj.class) {
-      return false;
-    }
-    Fruit fobj = (Fruit) obj;
-    if (ripe.equals(fobj.getRipe()) {
-      return true;
-    }
-    return false;
+  @Override
+  public boolean equals(Object other) {
+    if (other == null) return false;
+    if (getClass() != other.getClass()) return false;
+    return a == ((Foo) other).a;
   }
 }
-
-public class Raspberry extends Fruit {  // Noncompliant; instances will use Fruit's equals method
-  private Color ripeColor;
+</pre>
+<pre data-diff-id="1" data-diff-type="noncompliant">
+class Bar extends Foo { // Noncompliant, `equals` ignores the value of `b`
+  final int b;
 }
 </pre>
-<h3>Compliant solution</h3>
-<pre>
-public class Fruit {
-  private Season ripe;
+<p>Override the <code>equals</code> method in the subclass to incorporate the new fields into the comparison:</p>
+<pre data-diff-id="1" data-diff-type="compliant">
+class Bar extends Foo { // Compliant, `equals` now also considers `b`
+
+  final int b;
 
-  public boolean equals(Object obj) {
-    if (obj == this) {
-      return true;
-    }
-    if (this.class != obj.class) {
-      return false;
-    }
-    Fruit fobj = (Fruit) obj;
-    if (ripe.equals(fobj.getRipe()) {
-      return true;
-    }
-    return false;
+  @Override
+  public boolean equals(Object other) {
+    if (!super.equals(other)) return false;
+    return b == ((Bar) other).b;
   }
 }
+</pre>
+<p>In case the new fields should not be part of the comparison because they are, for example, auxiliary variables not contributing to the object value
+(), still override the method to make the point clear that this was not just forgotten:</p>
+<pre data-diff-id="1" data-diff-type="compliant">
+class Bar extends Foo { // Compliant, we do explicitly not want to take `b` into account
 
-public class Raspberry extends Fruit {
-  private Color ripeColor;
+  final int b;
 
-  public boolean equals(Object obj) {
-    if (! super.equals(obj)) {
-      return false;
-    }
-    Raspberry fobj = (Raspberry) obj;
-    if (ripeColor.equals(fobj.getRipeColor()) {  // added fields are tested
-      return true;
-    }
-    return false;
+  @Override
+  public boolean equals(Object other) {
+    return super.equals(other);
   }
 }
 </pre>
+<h2>Resources</h2>
+<h3>Documentation</h3>
+<ul>
+  <li> <a href="https://docs.oracle.com/javase/8/docs/api/java/lang/Object.html#equals-java.lang.Object-">Object.equals - Java SE 8 API
+  Specification</a> </li>
+</ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2160.json b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2160.json
index 366dce6c991..23229d2691b 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2160.json
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2160.json
@@ -1,5 +1,5 @@
 {
-  "title": "Subclasses that add fields should override \"equals\"",
+  "title": "Subclasses that add fields to classes that override \"equals\" should also override \"equals\"",
   "type": "CODE_SMELL",
   "status": "ready",
   "remediation": {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2165.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2165.html
index e0bc9b9efb3..fd2ee76ec89 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2165.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2165.html
@@ -1,15 +1,45 @@
+<p>This rule raises an issue when a finalizer assign <code>null</code> to fields of the instance it is called on.</p>
 <h2>Why is this an issue?</h2>
-<p>There is no point in setting class fields to <code>null</code> in a finalizer. If this this is a hint to the garbage collector, it is unnecessary -
-the object will be garbage collected anyway - and doing so may actually cause extra work for the garbage collector.</p>
-<h3>Noncompliant code example</h3>
-<pre>
+<p>In the Java object lifecycle, the <code>finalize</code> method for an instance is called after the garbage collector has determined that the
+instance can be removed from the object heap. Therefore, it is unnecessary to implement a finalizer to set instance fields explicitly to
+<code>null</code> to tell the garbage collector that the instance no longer needs them.</p>
+<p>In the worst case, implementing <code>finalize</code> is even counterproductive because it might accidentally create new references from other
+(living) objects on the heap to the collectible instance, thus, reviving it.</p>
+<p><strong>Important note about finalizers:</strong></p>
+<p>There are no guarantees when the Java Runtime will call the <code>finalize</code> method or whether it will be called at all.</p>
+<p>Using finalizers is, therefore, a bad practice. They should never be used to free resources, such as closing streams, freeing locks, or freeing
+native system resources. Consider other freeing mechanisms instead, such as an explicit <code>close</code>, <code>unlock</code>, or <code>free</code>
+method in your class.</p>
+<h2>How to fix it</h2>
+<p>Remove assignments from your finalizer that assign <code>null</code> to fields of the instance the finalizer is called on. When this leaves you
+with an empty finalizer body, remove the finalizer.</p>
+<h3>Code examples</h3>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="1" data-diff-type="noncompliant">
 public class Foo {
   private String name;
 
   @Override
   void finalize() {
-    name = null;  // Noncompliant; completely unnecessary
+    name = null;  // Noncompliant, instance will be removed anyway
   }
 }
 </pre>
+<h4>Compliant solution</h4>
+<pre data-diff-id="1" data-diff-type="compliant">
+public class Foo { // Compliant
+  private String name;
+}
+</pre>
+<h2>Resources</h2>
+<h3>Documentation</h3>
+<ul>
+  <li> <a href="https://docs.oracle.com/javase/8/docs/api/java/lang/Object.html#finalize--">Java SE 8 API Specification - Object.finalize</a> </li>
+</ul>
+<h3>Articles &amp; blog posts</h3>
+<ul>
+  <li> <a href="https://howtodoinjava.com/java/basics/why-not-to-use-finalize-method-in-java">Java finalize() – Why We Should Not Use It? - Lokesh
+  Gupta</a> </li>
+  <li> <a href="https://www.baeldung.com/java-finalize">A Guide to the finalize Method in Java - Baeldung</a> </li>
+</ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2235.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2235.html
index 669126ff67e..5ffc877e220 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2235.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2235.html
@@ -1,33 +1,31 @@
 <h2>Why is this an issue?</h2>
-<p>According to Oracle Javadoc:</p>
-<blockquote>
-  <p><code>IllegalMonitorStateException</code> is thrown when a thread has attempted to wait on an object’s monitor or to notify other threads waiting
-  on an object’s monitor without owning the specified monitor.</p>
-</blockquote>
-<p>In other words, this exception can be thrown only in case of bad design because <code>Object.wait(...)</code>, <code>Object.notify()</code> and
-<code>Object.notifyAll()</code> methods should never be called on an object whose monitor is not held.</p>
+<p>The <code>IllegalMonitorStateException</code> is an exception that occurs when a thread tries to perform an operation on an object’s monitor that
+it does not own. This exception is typically thrown when a method like <code>wait()</code>, <code>notify()</code>, or <code>notifyAll()</code> is
+called outside a synchronized block or method.</p>
+<p><code>IllegalMonitorStateException</code> is specifically designed to be an unchecked exception to point out a programming mistake. This exception
+serves as a reminder for developers to rectify their code by correctly acquiring and releasing locks using synchronized blocks or methods. It also
+emphasizes the importance of calling monitor-related methods on the appropriate objects to ensure proper synchronization.</p>
+<p>Catching and handling this exception can mask underlying synchronization issues and lead to unpredictable behavior.</p>
 <h3>Noncompliant code example</h3>
-<pre>
-public void doSomething(){
-  ...
+<pre data-diff-id="1" data-diff-type="noncompliant">
+public void doSomething() {
   try {
-    ...
     anObject.notify();
-    ...
-  } catch(IllegalMonitorStateException e) {
-    ...
+  } catch(IllegalMonitorStateException e) { // Noncompliant
   }
 }
 </pre>
 <h3>Compliant solution</h3>
-<pre>
-public void doSomething(){
-  ...
+<pre data-diff-id="1" data-diff-type="compliant">
+public void doSomething() {
   synchronized(anObject) {
-    ...
     anObject.notify();
-    ...
   }
 }
 </pre>
+<h2>Resources</h2>
+<ul>
+  <li> <a href="https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/IllegalMonitorStateException.html">Oracle Java SE -
+  IllegalMonitorStateException</a> </li>
+</ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2235.json b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2235.json
index 2d083d6e2d4..67bea0b4838 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2235.json
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2235.json
@@ -1,5 +1,5 @@
 {
-  "title": "IllegalMonitorStateException should not be caught",
+  "title": "\"IllegalMonitorStateException\" should not be caught",
   "type": "CODE_SMELL",
   "status": "ready",
   "remediation": {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2236.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2236.html
index f63ac98959e..0cb8d02a38f 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2236.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2236.html
@@ -1,17 +1,20 @@
 <h2>Why is this an issue?</h2>
-<p>The methods <code>wait(...)</code>, <code>notify()</code> and <code>notifyAll()</code> are available on a <code>Thread</code> instance, but only
-because all classes in Java extend <code>Object</code> and therefore automatically inherit those methods. But there are two very good reasons for not
-calling them on a <code>Thread</code>:</p>
-<ul>
-  <li> Internally, the JVM relies on these methods to change the state of the Thread (<code>BLOCKED</code>, <code>WAITING</code>, …​), so calling them
-  will corrupt the behavior of the JVM. </li>
-  <li> It is not clear (perhaps even to the original coder) what is really expected. For instance, it is waiting for the execution of the Thread to
-  suspended, or is it the acquisition of the object monitor that is waited for? </li>
-</ul>
+<p>In Java, the <code>Thread</code> class represents a thread of execution. Synchronization between threads is typically achieved using objects or
+shared resources.</p>
+<p>The methods <code>wait(…​)</code>, <code>notify()</code>, and <code>notifyAll()</code> are related to the underlying object’s monitor and are
+designed to be called on objects that act as locks or monitors for synchronization. These methods are available on Java <code>Object</code> and,
+therefore, automatically inherited by all objects, including <code>Thread.</code></p>
+<p>Calling these methods on a <code>Thread</code> may corrupt the behavior of the JVM, which relies on them to change the state of the thread
+(<code>BLOCKED,</code> <code>WAITING,</code>…​).</p>
 <h3>Noncompliant code example</h3>
 <pre>
 Thread myThread = new Thread(new RunnableJob());
 ...
-myThread.wait(2000);
+myThread.wait(); // Noncompliant
 </pre>
+<h2>Resources</h2>
+<ul>
+  <li> <a href="https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/Thread.html">Oracle Java SE - Thread</a> </li>
+  <li> <a href="https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/Object.html">Oracle Java SE - Object</a> </li>
+</ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2390.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2390.html
index 067219e1aa8..fb5026a92aa 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2390.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2390.html
@@ -1,7 +1,10 @@
 <h2>Why is this an issue?</h2>
-<p>When a parent class references a member of a subclass during its own initialization, the results might not be what you expect because the child
-class might not have been initialized yet. This could create what is known as an "initialisation cycle", or even a deadlock in some extreme cases.</p>
-<p>To make things worse, these issues are very hard to diagnose so it is highly recommended you avoid creating this kind of dependencies.</p>
+<p>Referencing a static member of a subclass from its parent during class initialization, makes the code more fragile and prone to future bugs. The
+execution of the program will rely heavily on the order of initialization of classes and their static members.</p>
+<h3>What is the potential impact?</h3>
+<p>This could create what is known as an "initialization cycle", or even a deadlock in some extreme cases. Additionally, if the order of the static
+class members is changed, the behavior of the program might change. These issues can be very hard to diagnose so it is highly recommended to avoid
+creating this kind of dependencies.</p>
 <h3>Noncompliant code example</h3>
 <pre>
 class Parent {
@@ -23,7 +26,7 @@ <h2>Resources</h2>
 <ul>
   <li> <a href="https://www.securecoding.cert.org/confluence/display/java/DCL00-J.+Prevent+class+initialization+cycles">CERT, DCL00-J.</a> - Prevent
   class initialization cycles </li>
-  <li> Java Language Specifications - <a href="https://docs.oracle.com/javase/specs/jls/se8/html/jls-12.html#jls-12.4">Section 12.4: Initialization of
-  Classes and Interfaces</a> </li>
+  <li> <a href="https://docs.oracle.com/javase/specs/jls/se17/html/jls-12.html#jls-12.4">Section 12.4: Initialization of Classes and Interfaces</a> -
+  Java Language Specification </li>
 </ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2390.json b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2390.json
index dc4c9b699e7..82aed73bd2c 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2390.json
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2390.json
@@ -1,6 +1,6 @@
 {
-  "title": "Classes should not access their own subclasses during initialization",
-  "type": "CODE_SMELL",
+  "title": "Classes should not access their own subclasses during class initialization",
+  "type": "BUG",
   "status": "ready",
   "remediation": {
     "func": "Constant\/Issue",
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2437.json b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2437.json
index 7cf859c957b..a0073bb4c00 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2437.json
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2437.json
@@ -1,5 +1,5 @@
 {
-  "title": "Silly bit operations should not be performed",
+  "title": "Unnecessary bit operations should not be performed",
   "type": "CODE_SMELL",
   "status": "ready",
   "remediation": {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2438.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2438.html
index af44e9bfd97..173a39d4b43 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2438.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2438.html
@@ -1,32 +1,27 @@
 <h2>Why is this an issue?</h2>
-<p>While it is technically correct to use a <code>Thread</code> where a <code>Runnable</code> is called for, the semantics of the two objects are
-different, and mixing them is a bad practice that will likely lead to headaches in the future.</p>
-<p>The crux of the issue is that <code>Thread</code> is a larger concept than <code>Runnable</code>. A <code>Runnable</code> is an object whose
-running should be managed. A <code>Thread</code> expects to manage the running of itself or other <code>Runnables</code>.</p>
+<p>The semantics of <code>Thread</code> and <code>Runnable</code> are different, and while it is technically correct to use <code>Thread</code> where
+a <code>Runnable</code> is expected, it is a bad practice to do so.</p>
+<p>The crux of the issue is that <code>Thread</code> is a larger concept than <code>Runnable</code>. A <code>Runnable</code> represents a task. A
+<code>Thread</code> represents a task and its execution management (ie: how it should behave when started, stopped, resumed, …​). It is both a task
+and a lifecycle management.</p>
 <h3>Noncompliant code example</h3>
-<pre>
-	public static void main(String[] args) {
-		Thread r =new Thread() {
-			int p;
-			@Override
-			public void run() {
-				while(true)
-					System.out.println("a");
-			}
-		};
-		new Thread(r).start();  // Noncompliant
+<pre data-diff-id="1" data-diff-type="noncompliant">
+public static void main(String[] args) {
+	Thread runnable = new Thread() {
+		@Override
+		public void run() { /* ... */ }
+	};
+	new Thread(runnable).start();  // Noncompliant
+}
 </pre>
 <h3>Compliant solution</h3>
-<pre>
-	public static void main(String[] args) {
-		Runnable r =new Runnable() {
-			int p;
-			@Override
-			public void run() {
-				while(true)
-					System.out.println("a");
-			}
-		};
-		new Thread(r).start();
+<pre data-diff-id="1" data-diff-type="compliant">
+public static void main(String[] args) {
+	Runnable runnable = new Runnable() {
+		@Override
+		public void run() { /* ... */ }
+	};
+	new Thread(runnable).start();
+}
 </pre>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2438.json b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2438.json
index 21381a5bc07..d40c898a4e3 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2438.json
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2438.json
@@ -1,5 +1,5 @@
 {
-  "title": "\"Threads\" should not be used where \"Runnables\" are expected",
+  "title": "\"Thread\" should not be used where a \"Runnable\" argument is expected",
   "type": "CODE_SMELL",
   "status": "ready",
   "remediation": {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2441.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2441.html
index 258aa22c68c..5039880cfc9 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2441.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2441.html
@@ -1,20 +1,26 @@
 <h2>Why is this an issue?</h2>
-<p>If you have no intention of writting an <code>HttpSession</code> object to file, then storing non-<code>serializable</code> objects in it may not
-seem like a big deal. But whether or not you explicitly serialize the session, it may be written to disk anyway, as the server manages its memory use
-in a process called "passivation". Further, some servers automatically write their active sessions out to file at shutdown &amp; deserialize any such
-sessions at startup.</p>
-<p>The point is, that even though <code>HttpSession</code> does not <code>extend Serializable</code>, you must nonetheless assume that it will be
-serialized, and understand that if you’ve stored non-serializable objects in the session, errors will result.</p>
+<p><code>HttpSession</code> s are managed by web servers and can be serialized and stored on disk as the server manages its memory use in a process
+called "passivation" (and later restored during "activation").</p>
+<p>Even though <code>HttpSession</code> does not extend <code>Serializable</code>, you must nonetheless assume that it will be serialized. If
+non-serializable objects are stored in the session, serialization might fail.</p>
 <h3>Noncompliant code example</h3>
-<pre>
+<pre data-diff-id="1" data-diff-type="noncompliant">
 public class Address {
   //...
 }
 
-//...
 HttpSession session = request.getSession();
 session.setAttribute("address", new Address());  // Noncompliant; Address isn't serializable
 </pre>
+<h3>Compliant solution</h3>
+<pre data-diff-id="1" data-diff-type="compliant">
+public class Address implements Serializable {
+  //...
+}
+
+HttpSession session = request.getSession();
+session.setAttribute("address", new Address());
+</pre>
 <h2>Resources</h2>
 <ul>
   <li> <a href="https://owasp.org/Top10/A04_2021-Insecure_Design/">OWASP Top 10 2021 Category A4</a> - Insecure Design </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2441.json b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2441.json
index 7189a232792..d3cf40a988a 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2441.json
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2441.json
@@ -1,5 +1,5 @@
 {
-  "title": "Non-serializable objects should not be stored in \"HttpSession\" objects",
+  "title": "Non-serializable objects should not be stored in \"javax.servlet.http.HttpSession\" instances",
   "type": "BUG",
   "status": "ready",
   "remediation": {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2442.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2442.html
index 2a186cd9ad0..db4699c824a 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2442.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2442.html
@@ -1,19 +1,25 @@
 <h2>Why is this an issue?</h2>
 <p><code>java.util.concurrent.locks.Lock</code> offers far more powerful and flexible locking operations than are available with
-<code>synchronized</code> blocks. So synchronizing on a <code>Lock</code> throws away the power of the object, and is just silly. Instead, such
-objects should be locked and unlocked using <code>tryLock()</code> and <code>unlock()</code>.</p>
+<code>synchronized</code> blocks. So synchronizing on a <code>Lock</code> instance throws away the power of the object, as it overrides its better
+locking mechanisms. Instead, such objects should be locked and unlocked using one of their <code>lock</code> and <code>unlock</code> method
+variants.</p>
 <h3>Noncompliant code example</h3>
-<pre>
+<pre data-diff-id="1" data-diff-type="noncompliant">
 Lock lock = new MyLockImpl();
 synchronized(lock) {  // Noncompliant
-  //...
+  // ...
 }
 </pre>
 <h3>Compliant solution</h3>
-<pre>
+<pre data-diff-id="1" data-diff-type="compliant">
 Lock lock = new MyLockImpl();
-lock.tryLock();
-//...
+if (lock.tryLock()) {
+  try {
+    // ...
+  } finally {
+    lock.unlock();
+  }
+}
 </pre>
 <h2>Resources</h2>
 <ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2442.json b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2442.json
index 85c01685c14..af9b29b1791 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2442.json
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2442.json
@@ -1,5 +1,5 @@
 {
-  "title": "\"Lock\" objects should not be \"synchronized\"",
+  "title": "Synchronizing on a \"Lock\" object should be avoided",
   "type": "CODE_SMELL",
   "status": "ready",
   "remediation": {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2445.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2445.html
index 1b2f7ce09af..f93b1cc1c2f 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2445.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2445.html
@@ -5,7 +5,7 @@ <h2>Why is this an issue?</h2>
 <p>The story is very similar for synchronizing on parameters; two different threads running the method in parallel could pass two different object
 instances in to the method as parameters, completely undermining the synchronization.</p>
 <h3>Noncompliant code example</h3>
-<pre>
+<pre data-diff-id="1" data-diff-type="noncompliant">
 private String color = "red";
 
 private void doSomething(){
@@ -20,7 +20,7 @@ <h3>Noncompliant code example</h3>
 }
 </pre>
 <h3>Compliant solution</h3>
-<pre>
+<pre data-diff-id="1" data-diff-type="compliant">
 private String color = "red";
 private final Object lockObj = new Object();
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2446.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2446.html
index 210809a6078..8c2db9c1bc9 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2446.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2446.html
@@ -1,28 +1,31 @@
 <h2>Why is this an issue?</h2>
-<p><code>notify</code> and <code>notifyAll</code> both wake up sleeping threads, but <code>notify</code> only rouses one, while <code>notifyAll</code>
-rouses all of them. Since <code>notify</code> might not wake up the right thread, <code>notifyAll</code> should be used instead.</p>
+<p><code>notify</code> and <code>notifyAll</code> both wake up sleeping threads waiting on the object’s monitor, but <code>notify</code> only wakes up
+one single thread, while <code>notifyAll</code> wakes them all up. Unless you do not care which specific thread is woken up, <code>notifyAll</code>
+should be used instead.</p>
 <h3>Noncompliant code example</h3>
-<pre>
-class MyThread extends Thread{
+<pre data-diff-id="1" data-diff-type="noncompliant">
+class MyThread implements Runnable {
+  Object lock = new Object();
 
   @Override
-  public void run(){
-    synchronized(this){
+  public void run() {
+    synchronized(lock) {
       // ...
-      notify();  // Noncompliant
+      lock.notify();  // Noncompliant
     }
   }
 }
 </pre>
 <h3>Compliant solution</h3>
-<pre>
-class MyThread extends Thread{
+<pre data-diff-id="1" data-diff-type="compliant">
+class MyThread implements Runnable {
+  Object lock = new Object();
 
   @Override
-  public void run(){
-    synchronized(this){
+  public void run() {
+    synchronized(lock) {
       // ...
-      notifyAll();
+      lock.notifyAll();
     }
   }
 }
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2446.json b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2446.json
index 4d043bf44bd..b8d43e88e6b 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2446.json
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2446.json
@@ -1,5 +1,5 @@
 {
-  "title": "\"notifyAll\" should be used",
+  "title": "\"notifyAll()\" should be preferred over \"notify()\"",
   "type": "BUG",
   "status": "ready",
   "remediation": {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2447.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2447.html
index 73ed54d3a45..a0b5d2f9cc4 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2447.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2447.html
@@ -1,13 +1,39 @@
 <h2>Why is this an issue?</h2>
-<p>While <code>null</code> is technically a valid <code>Boolean</code> value, that fact, and the distinction between <code>Boolean</code> and
-<code>boolean</code> is easy to forget. So returning <code>null</code> from a <code>Boolean</code> method is likely to cause problems with callers'
-code.</p>
+<p>Callers of a <code>Boolean</code> method may be expecting to receive <code>true</code> or <code>false</code> in response. But <code>Boolean</code>
+objects can take <code>null</code> as a possible value. <code>Boolean</code> methods should not return <code>null</code> unless the code is annotated
+appropriately. With the proper annotation, the caller is aware that the returned value could be null.</p>
 <h3>Noncompliant code example</h3>
 <pre>
 public Boolean isUsable() {
   // ...
   return null;  // Noncompliant
 }
+
+public void caller() {
+  if (isUsable()) { // A NullPointerException might occur here
+    // ...
+  }
+}
+</pre>
+<h3>Compliant solution</h3>
+<pre>
+@javax.annotation.Nullable
+public Boolean isUsable() {
+  // ...
+  return null;
+}
+
+@javax.annotation.CheckForNull
+public Boolean isUsable() {
+  // ...
+  return null;
+}
+
+public void caller() {
+  if (Boolean.True.equals(isUsable())) { // This caller knows to check and avoid ambiguity
+    // ...
+  }
+}
 </pre>
 <h2>Resources</h2>
 <ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2447.json b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2447.json
index dd31977a7a4..78a7f5952d7 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2447.json
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2447.json
@@ -1,5 +1,5 @@
 {
-  "title": "Null should not be returned from a \"Boolean\" method",
+  "title": "\"null\" should not be returned from a \"Boolean\" method",
   "type": "CODE_SMELL",
   "status": "ready",
   "remediation": {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2583.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2583.html
index f1953883f94..925686c9d97 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2583.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2583.html
@@ -1,6 +1,6 @@
 <h2>Why is this an issue?</h2>
-<p>Conditional expressions which are always <code>true</code> or <code>false</code> can lead to dead code. Such code is always buggy and should never
-be used in production.</p>
+<p>Conditional expressions which are always <code>true</code> or <code>false</code> can lead to <a
+href="https://en.wikipedia.org/wiki/Unreachable_code">unreachable code</a>.</p>
 <h3>Noncompliant code example</h3>
 <pre>
 a = false;
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2629.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2629.html
index d914c824b40..b96e9f5c42c 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2629.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2629.html
@@ -1,6 +1,8 @@
 <h2>Why is this an issue?</h2>
+<p>Some method calls can effectively be "no-ops", meaning that the invoked method does nothing, based on the application’s configuration (eg: debug
+logs in production). However, even if the method effectively does nothing, its arguments may still need to evaluated before the method is called.</p>
 <p>Passing message arguments that require further evaluation into a Guava <code>com.google.common.base.Preconditions</code> check can result in a
-performance penalty. That’s because whether or not they’re needed, each argument must be resolved before the method is actually called.</p>
+performance penalty. That is because whether or not they’re needed, each argument must be resolved before the method is actually called.</p>
 <p>Similarly, passing concatenated strings into a logging method can also incur a needless performance hit because the concatenation will be performed
 every time the method is called, whether or not the log level is low enough to show the message.</p>
 <p>Instead, you should structure your code to pass static or pre-computed values into <code>Preconditions</code> conditions check and logging
@@ -23,12 +25,11 @@ <h3>Noncompliant code example</h3>
 </pre>
 <h3>Compliant solution</h3>
 <pre>
-logger.log(Level.SEVERE, "Something went wrong: {0} ", message);  // String formatting only applied if needed
+logger.log(Level.DEBUG, "Something went wrong: {0} ", message);  // String formatting only applied if needed
+logger.log(Level.SEVERE, () -&gt; "Something went wrong: " + message); // since Java 8, we can use Supplier , which will be evaluated lazily
 
 logger.fine("An exception occurred with message: {}", message);  // SLF4J, Log4j
 
-logger.log(Level.SEVERE, () -&gt; "Something went wrong: " + message); // since Java 8, we can use Supplier , which will be evaluated lazily
-
 LOG.error("Unable to open file {0}", csvPath, e);
 
 if (LOG.isDebugEnabled()) {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2681.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2681.html
index 684e83d9a94..a3fa534db5a 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2681.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2681.html
@@ -1,43 +1,32 @@
 <h2>Why is this an issue?</h2>
-<p>Curly braces can be omitted from a one-line block, such as with an <code>if</code> statement or <code>for</code> loop, but doing so can be
-misleading and induce bugs.</p>
-<p>This rule raises an issue when the whitespacing of the lines after a one line block indicates an intent to include those lines in the block, but
+<p>Having inconsistent indentation and omitting curly braces from a control structure, such as an <code>if</code> statement or <code>for</code> loop,
+is misleading and can induce bugs.</p>
+<p>This rule raises an issue when the indentation of the lines after a control structure indicates an intent to include those lines in the block, but
 the omission of curly braces means the lines will be unconditionally executed once.</p>
-<p>Note that this rule considers tab characters to be equivalent to 1 space. If you mix spaces and tabs you will sometimes see issues in code which
-look fine in your editor but are confusing when you change the size of tabs.</p>
-<h3>Noncompliant code example</h3>
+<p>The following patterns are recognized:</p>
 <pre>
 if (condition)
   firstActionInBlock();
-  secondAction();  // Noncompliant; executed unconditionally
+  secondAction();  // Noncompliant: secondAction is executed unconditionally
 thirdAction();
-
-if (condition) firstActionInBlock(); secondAction();  // Noncompliant; secondAction executed unconditionally
-
-if (condition) firstActionInBlock();  // Noncompliant
-  secondAction();  // Executed unconditionally
-
-if (condition); secondAction();  // Noncompliant; secondAction executed unconditionally
-
-String str = null;
-for (int i = 0; i &lt; array.length; i++)
-  str = array[i];
-  doTheThing(str);  // Noncompliant; executed only on last array element
 </pre>
-<h3>Compliant solution</h3>
 <pre>
-if (condition) {
-  firstActionInBlock();
-  secondAction();
-}
-thirdAction();
-
-String str = null;
-for (int i = 0; i &lt; array.length; i++) {
+if (condition) firstActionInBlock(); secondAction();  // Noncompliant: secondAction is executed unconditionally
+</pre>
+<pre>
+if (condition) firstActionInBlock();
+  secondAction();  // Noncompliant: secondAction is executed unconditionally
+</pre>
+<pre>
+if (condition); secondAction();  // Noncompliant: secondAction is executed unconditionally
+</pre>
+<pre>
+for (int i = 0; i &lt; array.length; i++)
   str = array[i];
-  doTheThing(str);
-}
+  doTheThing(str);  // Noncompliant: executed only on the last element
 </pre>
+<p>Note that this rule considers tab characters to be equivalent to 1 space. When mixing spaces and tabs, a code may look fine in one editor but be
+confusing in another configured differently.</p>
 <h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/483">MITRE, CWE-483</a> - Incorrect Block Delimitation </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2692.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2692.html
index 034d1ecfa67..b4959689047 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2692.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2692.html
@@ -1,45 +1,30 @@
 <h2>Why is this an issue?</h2>
-<p>Most checks against an <code>indexOf</code> value compare it with -1 because 0 is a valid index. Any checks which look for values &gt;0 ignore the
-first element, which is likely a bug. If the intent is merely to check inclusion of a value in a <code>String</code> or a <code>List</code>, consider
-using the <code>contains</code> method instead.</p>
-<p>This rule raises an issue when an <code>indexOf</code> value retrieved either from a <code>String</code> or a <code>List</code> is tested against
-<code>&gt;0</code>.</p>
-<h3>Noncompliant code example</h3>
+<p>Most checks against an <code>indexOf</code> value compare it with -1 because 0 is a valid index. Checking against <code>&gt; 0</code> ignores the
+first element, which is likely a bug.</p>
 <pre>
-String color = "blue";
 String name = "ishmael";
 
-List&lt;String&gt; strings = new ArrayList&lt;String&gt; ();
-strings.add(color);
-strings.add(name);
-
-if (strings.indexOf(color) &gt; 0) {  // Noncompliant
-  // ...
-}
 if (name.indexOf("ish") &gt; 0) { // Noncompliant
   // ...
 }
-if (name.indexOf("ae") &gt; 0) { // Noncompliant
-  // ...
-}
 </pre>
-<h3>Compliant solution</h3>
+<p>Moreover, if the intent is merely to check the inclusion of a value in a <code>String</code> or a <code>List</code>, consider using the
+<code>contains</code> method instead.</p>
 <pre>
-String color = "blue";
 String name = "ishmael";
 
-List&lt;String&gt; strings = new ArrayList&lt;String&gt; ();
-strings.add(color);
-strings.add(name);
-
-if (strings.indexOf(color) &gt; -1) {
+if (name.contains("ish") {
   // ...
 }
-if (name.indexOf("ish") &gt;= 0) {
-  // ...
-}
-if (name.contains("ae") {
+</pre>
+<p>If the intent is really to skip the first element, comparing it with <code>&gt;=1</code> will make it more straightforward.</p>
+<pre>
+String name = "ishmael";
+
+if (name.indexOf("ish") &gt;= 1) {
   // ...
 }
 </pre>
+<p>This rule raises an issue when an <code>indexOf</code> value retrieved from a <code>String</code> or a <code>List</code> is tested against
+<code>&gt; 0</code>.</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2757.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2757.html
index 25a5641d3e5..ce174525ffb 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2757.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2757.html
@@ -1,22 +1,27 @@
 <h2>Why is this an issue?</h2>
-<p>The use of operators pairs ( <code>=+</code>, <code>=-</code> or <code>=!</code> ) where the reversed, single operator was meant (<code>+=</code>,
-<code>-=</code> or <code>!=</code>) will compile and run, but not produce the expected results.</p>
-<p>This rule raises an issue when <code>=+</code>, <code>=-</code>, or <code>=!</code> is used without any spacing between the two operators and when
-there is at least one whitespace character after.</p>
-<h3>Noncompliant code example</h3>
+<p>Using operator pairs (<code>=+</code>, <code>=-</code>, or <code>=!</code>) that look like reversed single operators (<code>+=</code>,
+<code>-=</code> or <code>!=</code>) is confusing. They compile and run but do not produce the same result as their mirrored counterpart.</p>
 <pre>
 int target = -5;
 int num = 3;
 
-target =- num;  // Noncompliant; target = -3. Is that really what's meant?
-target =+ num; // Noncompliant; target = 3
+target =- num;  // Noncompliant: target = -3. Is that the intended behavior?
+target =+ num; // Noncompliant: target = 3
 </pre>
-<h3>Compliant solution</h3>
+<p>This rule raises an issue when <code>=+</code>, <code>=-</code>, or <code>=!</code> are used without any space between the operators and when there
+is at least one whitespace after.</p>
+<p>Replace the operators with a single one if that is the intention</p>
 <pre>
 int target = -5;
 int num = 3;
 
-target = -num;  // Compliant; intent to assign inverse value of num is clear
-target += num;
+target -= num;  // target = -8
+</pre>
+<p>Or fix the spacing to avoid confusion</p>
+<pre>
+int target = -5;
+int num = 3;
+
+target = -num;  // target = -3
 </pre>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2757.json b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2757.json
index bdf3a05503d..acd83d9f504 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2757.json
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2757.json
@@ -1,5 +1,5 @@
 {
-  "title": "\"\u003d+\" should not be used instead of \"+\u003d\"",
+  "title": "Non-existent operators like \"\u003d+\" should not be used",
   "type": "BUG",
   "status": "ready",
   "remediation": {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2761.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2761.html
index 3a00dc423d5..1bcffdda9b8 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2761.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2761.html
@@ -1,30 +1,31 @@
 <h2>Why is this an issue?</h2>
-<p>The needless repetition of an operator is usually a typo. There is no reason to write <code>!!!i</code> when <code>!i</code> will do.</p>
-<p>On the other hand, the repetition of increment and decrement operators may have been done on purpose, but doing so obfuscates the meaning, and
-should be simplified.</p>
-<p>This rule raises an issue for sequences of: <code>!</code>, <code>~</code>, <code>-</code>, and <code>+</code>.</p>
-<h3>Noncompliant code example</h3>
+<p>The repetition of a unary operator is usually a typo. The second operator invalidates the first one in most cases:</p>
 <pre>
 int i = 1;
 
-int j = - - -i;  // Noncompliant; just use -i
-int k = ~~~i;    // Noncompliant; same as i
-int m = + +i;    // Noncompliant; operators are useless here
+int j = - - -i;  // Noncompliant: equivalent to "-i"
+int k = ~~~i;    // Noncompliant: equivalent to "~i"
+int m = + +i;    // Noncompliant: equivalent to "i"
 
 boolean b = false;
 boolean c = !!!b;   // Noncompliant
 </pre>
-<h3>Compliant solution</h3>
+<p>On the other hand, while repeating the increment and decrement operators is technically correct, it obfuscates the meaning:</p>
 <pre>
-int i =  1;
-
-int j = -i;
-int k = ~i;
-int m =  i;
-
-boolean b = false;
-boolean c = !b;
+int i = 1;
+int j = ++ ++i;  // Noncompliant
+int k = i-- --; // Noncompliant
+</pre>
+<p>Using <code>+=</code> or <code>-=</code> improves readability:</p>
+<pre>
+int i = 1;
+i += 2;
+int j = i;
+int k = i;
+i -=2;
 </pre>
+<p>This rule raises an issue for repetitions of <code>!</code>, <code>~</code>, <code>-</code>, <code>+</code>, prefix increments <code>++</code> and
+prefix decrements <code>--</code>.</p>
 <h3>Exceptions</h3>
 <p>Overflow handling for GWT compilation using <code>~~</code> is ignored.</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2925.json b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2925.json
index 15d23fa6890..a979ac80297 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2925.json
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2925.json
@@ -14,5 +14,5 @@
   "ruleSpecification": "RSPEC-2925",
   "sqKey": "S2925",
   "scope": "Tests",
-  "quickfix": "unknown"
+  "quickfix": "infeasible"
 }
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2975.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2975.html
index fc7fffddfa0..34c5ee60e3b 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2975.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2975.html
@@ -1,38 +1,104 @@
+<p>This rule raises an issue when a class overrides the <code>Object.clone</code> method instead of resorting to a copy constructor or other copy
+mechanisms.</p>
 <h2>Why is this an issue?</h2>
-<p>Many consider <code>clone</code> and <code>Cloneable</code> broken in Java, largely because the rules for overriding <code>clone</code> are tricky
-and difficult to get right, according to Joshua Bloch:</p>
-<blockquote>
-  <p>Object’s clone method is very tricky. It’s based on field copies, and it’s "extra-linguistic." It creates an object without calling a
-  constructor. There are no guarantees that it preserves the invariants established by the constructors. There have been lots of bugs over the years,
-  both in and outside Sun, stemming from the fact that if you just call super.clone repeatedly up the chain until you have cloned an object, you have
-  a shallow copy of the object. The clone generally shares state with the object being cloned. If that state is mutable, you don’t have two
-  independent objects. If you modify one, the other changes as well. And all of a sudden, you get random behavior.</p>
-</blockquote>
-<p>A copy constructor or copy factory should be used instead.</p>
-<p>This rule raises an issue when <code>clone</code> is overridden, whether or not <code>Cloneable</code> is implemented.</p>
-<h3>Noncompliant code example</h3>
-<pre>
-public class MyClass {
-  // ...
-
-  public Object clone() { // Noncompliant
-    //...
+<p>The <code>Object.clone</code> / <code>java.lang.Cloneable</code> mechanism in Java should be considered broken for the following reasons and
+should, consequently, not be used:</p>
+<ul>
+  <li> <code>Cloneable</code> is a <em>marker interface</em> without API but with a contract about class behavior that the compiler cannot enforce.
+  This is a bad practice. </li>
+  <li> Classes are instantiated without calling their constructor, so possible preconditions cannot be enforced. </li>
+  <li> There are implementation flaws by design when overriding <code>Object.clone</code>, like type casts or the handling of
+  <code>CloneNotSupportedException</code> exceptions. </li>
+</ul>
+<h2>How to fix it</h2>
+<p>A copy constructor, copy factory or a custom copy function are suitable alternatives to the <code>Object.clone</code> /
+<code>java.lang.Cloneable</code> mechanism.</p>
+<p>Consider the following example:</p>
+<pre data-diff-id="1" data-diff-type="noncompliant">
+class Entity implements Cloneable { // Noncompliant, using `Cloneable`
+
+  public int value;
+  public List&lt;Entity&gt; children; // deep copy wanted
+
+  Entity() {
+    EntityManager.register(this); // invariant
+  }
+
+  @Override
+  public Entity clone() {
+    try {
+      Entity copy = (Entity) super.clone(); // invariant not enforced, because no constructor is caled
+      copy.children = children.stream().map(Entity::clone).toList();
+      return copy;
+    } catch (CloneNotSupportedException e) { // this will not happen due to behavioral contract
+      throw new AssertionError();
+    }
   }
 }
 </pre>
-<h3>Compliant solution</h3>
-<pre>
-public class MyClass {
-  // ...
+<p>The <code>Cloneable</code> / <code>Object.clone</code> mechanism could easily be replaced by copy constructor:</p>
+<pre data-diff-id="1" data-diff-type="compliant">
+class Entity { // Compliant
+
+  public int value;
+  public List&lt;Entity&gt; children; // deep copy wanted
+
+  Entity() {
+    EntityManager.register(this); // invariant
+  }
+
+  Entity(Entity template) {
+    value = template.value;
+    children = template.children.stream().map(Entity::new).toList();
+  }
+}
+</pre>
+<p>Or by a factory method:</p>
+<pre data-diff-id="1" data-diff-type="compliant">
+class Entity { // Compliant
+
+  public int value;
+  public List&lt;Entity&gt; children; // deep copy wanted
+
+  Entity() {
+    EntityManager.register(this); // invariant
+  }
+
+  public static Entity create(Entity template) {
+    Entity entity = new Entity();
+    entity.value = template.value;
+    entity.children = template.children.stream().map(Entity::new).toList();
+    return Entity;
+  }
+}
+</pre>
+<p>Or by a custom <code>copy</code> function:</p>
+<pre data-diff-id="1" data-diff-type="compliant">
+class Entity { // Compliant
+
+  public int value;
+  public List&lt;Entity&gt; children; // deep copy wanted
+
+  Entity() {
+    EntityManager.register(this); // invariant
+  }
 
-  MyClass (MyClass source) {
-    //...
+  public Entity copy() {
+    Entity entity = new Entity();
+    entity.value = value;
+    entity.children = children.stream().map(Entity::new).toList();
+    return Entity;
   }
 }
 </pre>
 <h2>Resources</h2>
+<h3>Documentation</h3>
 <ul>
-  <li> <a href="https://www.artima.com/intv/bloch13.html">Copy Constructor versus Cloning</a> </li>
+  <li> <a href="https://www.artima.com/intv/bloch13.html">Joshua Bloch - Copy Constructor versus Cloning</a> </li>
+  <li> <a href="https://docs.oracle.com/javase/8/docs/api/java/lang/Cloneable.html">Interface Cloneable - Java™ Platform, Standard Edition 8 API
+  Specification</a> </li>
+  <li> <a href="https://docs.oracle.com/javase/8/docs/api/java/lang/Object.html#clone--">Object.clone - Java™ Platform, Standard Edition 8 API
+  Specification</a> </li>
 </ul>
 <h3>Related rules</h3>
 <ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3011.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3011.html
index afbd05ec6dc..7435c7f0116 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3011.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3011.html
@@ -1,8 +1,8 @@
 <h2>Why is this an issue?</h2>
+<p>Altering or bypassing the accessibility of classes, methods, or fields through reflection violates the encapsulation principle. This can break the
+internal contracts of the accessed target and lead to maintainability issues and runtime errors.</p>
 <p>This rule raises an issue when reflection is used to change the visibility of a class, method or field, and when it is used to directly update a
-field value. Altering or bypassing the accessibility of classes, methods, or fields violates the encapsulation principle and could lead to run-time
-errors.</p>
-<h3>Noncompliant code example</h3>
+field value.</p>
 <pre>
 public void makeItPublic(String methodName) throws NoSuchMethodException {
 
@@ -14,7 +14,9 @@ <h3>Noncompliant code example</h3>
 }
 </pre>
 <h2>Resources</h2>
+<h3>Documentation</h3>
 <ul>
+  <li> <a href="https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)">Wikipedia definition of Encapsulation</a> </li>
   <li> <a href="https://wiki.sei.cmu.edu/confluence/x/_jZGBQ">CERT, SEC05-J.</a> - Do not use reflection to increase accessibility of classes,
   methods, or fields </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3358.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3358.html
index b8678c63e32..39b89c4ce00 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3358.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3358.html
@@ -1,15 +1,11 @@
 <h2>Why is this an issue?</h2>
-<p>Just because you <em>can</em> do something, doesn’t mean you should, and that’s the case with nested ternary operations. Nesting ternary operators
-results in the kind of code that may seem clear as day when you write it, but six months later will leave maintainers (or worse - future you)
-scratching their heads and cursing.</p>
-<p>Instead, err on the side of clarity, and use another line to express the nested operation as a separate statement.</p>
-<h3>Noncompliant code example</h3>
+<p>Nested ternaries are hard to read and can make the order of operations complex to understand.</p>
 <pre>
 public String getReadableStatus(Job j) {
   return j.isRunning() ? "Running" : j.hasErrors() ? "Failed" : "Succeeded";  // Noncompliant
 }
 </pre>
-<h3>Compliant solution</h3>
+<p>Instead, use another line to express the nested operation in a separate statement.</p>
 <pre>
 public String getReadableStatus(Job j) {
   if (j.isRunning()) {
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3776.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3776.html
index 73066d872eb..c69347fef18 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3776.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3776.html
@@ -3,8 +3,9 @@ <h2>Why is this an issue?</h2>
 difficult to maintain.</p>
 <h3>Exceptions</h3>
 <p><code>equals</code> and <code>hashCode</code> methods are ignored because they might be automatically generated and might end up being difficult to
-understand, especially in presence of many fields.</p>
+understand, especially in the presence of many fields.</p>
 <h2>Resources</h2>
+<h3>Documentation</h3>
 <ul>
   <li> <a href="https://www.sonarsource.com/docs/CognitiveComplexity.pdf">Cognitive Complexity</a> </li>
 </ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3923.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3923.html
index 762051617d9..caf4dbad6cb 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3923.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3923.html
@@ -1,7 +1,6 @@
 <h2>Why is this an issue?</h2>
-<p>Having all branches in a <code>switch</code> or <code>if</code> chain with the same implementation is an error. Either a copy-paste error was made
-and something different should be executed, or there shouldn’t be a <code>switch</code>/<code>if</code> chain at all.</p>
-<h3>Noncompliant code example</h3>
+<p>Having all branches of a <code>switch</code> or <code>if</code> chain with the same implementation indicates a problem.</p>
+<p>In the following code:</p>
 <pre>
 if (b == 0) {  // Noncompliant
   doOneMoreThing();
@@ -25,9 +24,9 @@ <h3>Noncompliant code example</h3>
     doSomething();
 }
 </pre>
+<p>Either there is a copy-paste error that needs fixing or an unnecessary <code>switch</code> or <code>if</code> chain that needs removing.</p>
 <h3>Exceptions</h3>
-<p>This rule does not apply to <code>if</code> chains without <code>else</code>-s, or to <code>switch</code>-es without <code>default</code>
-clauses.</p>
+<p>This rule does not apply to <code>if</code> chains without <code>else</code>, nor to <code>witch</code> without a <code>default</code> clause.</p>
 <pre>
 if(b == 0) {    //no issue, this could have been done on purpose to make the code more readable
   doSomething();
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3972.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3972.html
index b9a7ad8f6a8..e439ad34a8b 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3972.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3972.html
@@ -1,31 +1,30 @@
 <h2>Why is this an issue?</h2>
-<p>Code is clearest when each statement has its own line. Nonetheless, it is a common pattern to combine on the same line an <code>if</code> and its
-resulting <em>then</em> statement. However, when an <code>if</code> is placed on the same line as the closing <code>}</code> from a preceding
-<em>then</em>, <em>else</em> or <em>else if</em> part, it is either an error - <code>else</code> is missing - or the invitation to a future error as
-maintainers fail to understand that the two statements are unconnected.</p>
-<h3>Noncompliant code example</h3>
-<pre>
+<p>Placing an <code>if</code> statement on the same line as the closing <code>}</code> from a preceding <code>if</code>, <code>else</code>, or
+<code>else if</code> block can lead to confusion and potential errors. It may indicate a missing <code>else</code> statement or create ambiguity for
+maintainers who might fail to understand that the two statements are unconnected.</p>
+<p>The following code snippet is confusing:</p>
+<pre data-diff-id="1" data-diff-type="noncompliant">
 if (condition1) {
   // ...
 } if (condition2) {  // Noncompliant
   //...
 }
 </pre>
-<h3>Compliant solution</h3>
-<pre>
+<p>Either the two conditions are unrelated and they should be visually separated:</p>
+<pre data-diff-id="1" data-diff-type="compliant">
 if (condition1) {
   // ...
-} else if (condition2) {
+}
+
+if (condition2) {
   //...
 }
 </pre>
-<p>Or</p>
+<p>Or they were supposed to be exclusive and you should use <code>else if</code> instead:</p>
 <pre>
 if (condition1) {
   // ...
-}
-
-if (condition2) {
+} else if (condition2) {
   //...
 }
 </pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3973.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3973.html
index 43d0aee8aff..de6a23baac6 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3973.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S3973.html
@@ -1,25 +1,30 @@
 <h2>Why is this an issue?</h2>
-<p>In the absence of enclosing curly braces, the line immediately after a conditional is the one that is conditionally executed. By both convention
-and good practice, such lines are indented. In the absence of both curly braces and indentation the intent of the original programmer is entirely
-unclear and perhaps not actually what is executed. Additionally, such code is highly likely to be confusing to maintainers.</p>
-<h3>Noncompliant code example</h3>
+<p>When the line immediately after a conditional has neither curly braces nor indentation, the intent of the code is unclear and perhaps not what is
+executed. Additionally, such code is confusing to maintainers.</p>
 <pre>
 if (condition)  // Noncompliant
 doTheThing();
-
-doTheOtherThing();
-somethingElseEntirely();
-
-foo();
+doTheOtherThing(); // Was the intent to call this function unconditionally?
+</pre>
+<p>It becomes even more confusing and bug-prone if lines get commented out.</p>
+<pre>
+if (condition)  // Noncompliant
+//  doTheThing();
+doTheOtherThing(); // Was the intent to call this function conditionally?
 </pre>
-<h3>Compliant solution</h3>
+<p>Indentation alone or together with curly braces makes the intent clear.</p>
 <pre>
 if (condition)
   doTheThing();
+doTheOtherThing(); // Clear intent to call this function unconditionally
 
-doTheOtherThing();
-somethingElseEntirely();
+// or
 
-foo();
+if (condition) {
+  doTheThing();
+}
+doTheOtherThing(); // Clear intent to call this function unconditionally
 </pre>
+<p>This rule raises an issue if the line controlled by a conditional has the same indentation as the conditional and is not enclosed in curly
+braces.</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4143.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4143.html
index 00cab76d930..e1947bea91c 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4143.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4143.html
@@ -1,6 +1,6 @@
 <h2>Why is this an issue?</h2>
-<p>It is highly suspicious when a value is saved for a key or index and then unconditionally overwritten. Such replacements are likely errors.</p>
-<h3>Noncompliant code example</h3>
+<p>Storing a value inside a collection at a given key or index and then unconditionally overwriting it without reading the initial value is a case of
+"dead store".</p>
 <pre>
 letters.put("a", "Apple");
 letters.put("a", "Boy");  // Noncompliant
@@ -8,4 +8,5 @@ <h3>Noncompliant code example</h3>
 towns[i] = "London";
 towns[i] = "Chicago";  // Noncompliant
 </pre>
+<p>At best it is redundant and will confuse the reader, most often it is an error and not what the developer intended to do.</p>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4144.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4144.html
index 44cf6cc0be3..84c10192b09 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4144.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4144.html
@@ -1,9 +1,7 @@
 <h2>Why is this an issue?</h2>
-<p>When two methods have the same implementation, either it was a mistake - something else was intended - or the duplication was intentional, but may
-be confusing to maintainers. In the latter case, one implementation should invoke the other. Numerical and string literals are not taken into
-account.</p>
-<h3>Noncompliant code example</h3>
-<pre>
+<p>Two methods having the same implementation are suspicious. It might be that something else was intended. Or the duplication is intentional, which
+becomes a maintenance burden.</p>
+<pre data-diff-id="1" data-diff-type="noncompliant">
 private final static String CODE = "bounteous";
 
 public String calculateCode() {
@@ -11,13 +9,14 @@ <h3>Noncompliant code example</h3>
   return CODE;
 }
 
-public String getName() {  // Noncompliant
+public String getName() {  // Noncompliant: duplicates calculateCode
   doTheThing();
   return CODE;
 }
 </pre>
-<h3>Compliant solution</h3>
-<pre>
+<p>If the identical logic is intentional, the code should be refactored to avoid duplication. For example, by having both methods call the same method
+or by having one implementation invoke the other.</p>
+<pre data-diff-id="1" data-diff-type="compliant">
 private final static String CODE = "bounteous";
 
 public String getCode() {
@@ -25,7 +24,7 @@ <h3>Compliant solution</h3>
   return CODE;
 }
 
-public String getName() {
+public String getName() { // The intent is clear
   return getCode();
 }
 </pre>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4275.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4275.html
index 620e8b67618..e04f0b7814f 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4275.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4275.html
@@ -1,6 +1,6 @@
 <h2>Why is this an issue?</h2>
 <p>Getters and setters provide a way to enforce encapsulation by providing <code>public</code> methods that give controlled access to
-<code>private</code> fields. However in classes with multiple fields it is not unusual that copy and paste is used to quickly create the needed
+<code>private</code> fields. However, in classes with multiple fields, it is not unusual that copy and paste is used to quickly create the needed
 getters and setters, which can result in the wrong field being accessed by a getter or setter.</p>
 <p>This rule raises an issue in any of these cases:</p>
 <ul>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4275.json b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4275.json
index f425d894c97..e73880cedec 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4275.json
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4275.json
@@ -13,5 +13,5 @@
   "ruleSpecification": "RSPEC-4275",
   "sqKey": "S4275",
   "scope": "All",
-  "quickfix": "unknown"
+  "quickfix": "targeted"
 }
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4524.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4524.html
index 46258111fdd..a48cca82142 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4524.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S4524.html
@@ -1,16 +1,15 @@
 <h2>Why is this an issue?</h2>
 <p><code>switch</code> can contain a <code>default</code> clause for various reasons: to handle unexpected values, to show that all the cases were
-properly considered.</p>
-<p>For readability purpose, to help a developer to quickly find the default behavior of a <code>switch</code> statement, it is recommended to put the
-<code>default</code> clause at the end of the <code>switch</code> statement. This rule raises an issue if the <code>default</code> clause is not the
-last one of the <code>switch</code>'s cases.</p>
-<h3>Noncompliant code example</h3>
+properly considered, etc.</p>
+<p>For readability purposes, to help a developer quickly spot the default behavior of a <code>switch</code> statement, it is recommended to put the
+<code>default</code> clause at the end of the <code>switch</code> statement.</p>
+<p>This rule raises an issue if the <code>default</code> clause is not the last one of the <code>switch</code>'s cases.</p>
 <pre>
 switch (param) {
   case 0:
     doSomething();
     break;
-  default: // default clause should be the last one
+  default: // Noncompliant: default clause should be the last one
     error();
     break;
   case 1:
@@ -18,18 +17,4 @@ <h3>Noncompliant code example</h3>
     break;
 }
 </pre>
-<h3>Compliant solution</h3>
-<pre>
-switch (param) {
-  case 0:
-    doSomething();
-    break;
-  case 1:
-    doSomethingElse();
-    break;
-  default:
-    error();
-    break;
-}
-</pre>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5547.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5547.html
index 6ea8c186971..429f5662275 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5547.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5547.html
@@ -1,63 +1,71 @@
+<p>This vulnerability makes it possible that the cleartext of the encrypted message might be recoverable without prior knowledge of the key.</p>
 <h2>Why is this an issue?</h2>
-<p><a href="https://en.wikipedia.org/wiki/Strong_cryptography">Strong cipher algorithms</a> are cryptographic systems resistant to cryptanalysis, they
-are not vulnerable to well-known attacks like brute force attacks for example.</p>
-<p>A general recommendation is to only use cipher algorithms intensively tested and promoted by the cryptographic community.</p>
-<p>More specifically for block cipher, it’s not recommended to use algorithm with a block size inferior than 128 bits.</p>
-<h3>Noncompliant code example</h3>
-<pre>
+<p>Encryption algorithms are essential for protecting sensitive information and ensuring secure communication in various domains. They are used for
+several important reasons:</p>
+<ul>
+  <li> Confidentiality, privacy, and intellectual property protection. </li>
+  <li> Security during transmission or on storage devices. </li>
+  <li> Data integrity, general trust, and authentication. </li>
+</ul>
+<p>When selecting encryption algorithms, tools, or combinations, you should also consider two things:</p>
+<ol>
+  <li> No encryption is unbreakable. </li>
+  <li> The strength of an encryption algorithm is usually measured by the effort required to crack it within a reasonable time frame. </li>
+</ol>
+<p>For these reasons, as soon as cryptography is included in a project, it is important to choose encryption algorithms that are considered strong and
+secure by the cryptography community.</p>
+<h3>What is the potential impact?</h3>
+<p>The cleartext of an encrypted message might be recoverable. Additionally, it might be possible to modify the cleartext of an encrypted message.</p>
+<p>Below are some real-world scenarios that illustrate some impacts of an attacker exploiting the vulnerability.</p>
+<h4>Theft of sensitive data</h4>
+<p>The encrypted message might contain data that is considered sensitive and should not be known to third parties.</p>
+<p>By using a weak algorithm the likelihood that an attacker might be able to recover the cleartext drastically increases.</p>
+<h4>Additional attack surface</h4>
+<p>By modifying the cleartext of the encrypted message it might be possible for an attacker to trigger other vulnerabilities in the code. Encrypted
+values are often considered trusted, since under normal circumstances it would not be possible for a third party to modify them.</p>
+<h2>How to fix it in Java Cryptographic Extension</h2>
+<h3>Code examples</h3>
+<p>The following code contains examples of algorithms that are not considered highly resistant to cryptanalysis and thus should be avoided.</p>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="1" data-diff-type="noncompliant">
 import javax.crypto.Cipher;
 import java.security.NoSuchAlgorithmException;
 import javax.crypto.NoSuchPaddingException;
 
-public class test {
-
-    public static void main(String[] args) {
-      try
-      {
-        Cipher c1 = Cipher.getInstance("DES"); // Noncompliant: DES works with 56-bit keys allow attacks via exhaustive search
-        Cipher c7 = Cipher.getInstance("DESede"); // Noncompliant: Triple DES is vulnerable to meet-in-the-middle attack
-        Cipher c13 = Cipher.getInstance("RC2"); // Noncompliant: RC2 is vulnerable to a related-key attack
-        Cipher c19 = Cipher.getInstance("RC4"); // Noncompliant: vulnerable to several attacks (see https://en.wikipedia.org/wiki/RC4#Security)
-        Cipher c25 = Cipher.getInstance("Blowfish"); // Noncompliant: Blowfish use a 64-bit block size makes it vulnerable to birthday attacks
-
-        NullCipher nc = new NullCipher(); // Noncompliant: the NullCipher class provides an "identity cipher" one that does not transform or encrypt the plaintext in any way.
-      }
-      catch(NoSuchAlgorithmException|NoSuchPaddingException e)
-      {
-      }
+public static void main(String[] args) {
+    try {
+        Cipher des = Cipher.getInstance("DES"); // Noncompliant
+    } catch(NoSuchAlgorithmException|NoSuchPaddingException e) {
+        // ...
     }
 }
 </pre>
-<h3>Compliant solution</h3>
-<pre>
+<h4>Compliant solution</h4>
+<pre data-diff-id="1" data-diff-type="compliant">
 import javax.crypto.Cipher;
 import java.security.NoSuchAlgorithmException;
 import javax.crypto.NoSuchPaddingException;
 
-public class test {
-
-    public static void main(String[] args) {
-      try
-      {
-        Cipher c31 = Cipher.getInstance("AES/GCM/NoPadding"); // Compliant
-      }
-      catch(NoSuchAlgorithmException|NoSuchPaddingException e)
-      {
-      }
+public static void main(String[] args) {
+    try {
+        Cipher aes = Cipher.getInstance("AES/GCM/NoPadding");
+    } catch(NoSuchAlgorithmException|NoSuchPaddingException e) {
+        // ...
     }
 }
 </pre>
+<h3>How does this work?</h3>
+<h4>Use a secure algorithm</h4>
+<p>It is highly recommended to use an algorithm that is currently considered secure by the cryptographic community. A common choice for such an
+algorithm is the Advanced Encryption Standard (AES).</p>
+<p>For block ciphers, it is not recommended to use algorithms with a block size that is smaller than 128 bits.</p>
 <h2>Resources</h2>
+<h3>Standards</h3>
 <ul>
   <li> <a href="https://owasp.org/Top10/A02_2021-Cryptographic_Failures/">OWASP Top 10 2021 Category A2</a> - Cryptographic Failures </li>
   <li> <a href="https://www.owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data
   Exposure </li>
-  <li> <a href="https://mobile-security.gitbook.io/masvs/security-requirements/0x08-v3-cryptography_verification_requirements">Mobile AppSec
-  Verification Standard</a> - Cryptography Requirements </li>
-  <li> <a href="https://owasp.org/www-project-mobile-top-10/2016-risks/m5-insufficient-cryptography">OWASP Mobile Top 10 2016 Category M5</a> -
-  Insufficient Cryptography </li>
   <li> <a href="https://cwe.mitre.org/data/definitions/327">MITRE, CWE-327</a> - Use of a Broken or Risky Cryptographic Algorithm </li>
-  <li> <a href="https://wiki.sei.cmu.edu/confluence/x/hDdGBQ">CERT, MSC61-J.</a> - Do not use insecure or weak cryptographic algorithms </li>
   <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
 </ul>
 
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6418.html b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6418.html
index 8d64a9934f3..32360ef0271 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6418.html
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6418.html
@@ -1,12 +1,3 @@
-<p>Secrets should not be hard-coded in source code, instead be stored outside of the source code in a configuration file or a management service for
-secrets.</p>
-<p>There would be a risk, if any of the following apply to you:</p>
-<ul>
-  <li> The secret allows access to a sensitive component like a database, a file storage, an API, or a service. </li>
-  <li> The secret is used in a production environment. </li>
-  <li> Application re-distribution is required before updating the secret. </li>
-</ul>
-<h2>Why is this an issue?</h2>
 <p>Because it is easy to extract strings from an application source code or binary, secrets should not be hard-coded. This is particularly true for
 applications that are distributed or that are open-source.</p>
 <p>In the past, it has led to the following vulnerabilities:</p>
@@ -14,17 +5,24 @@ <h2>Why is this an issue?</h2>
   <li> <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-25510">CVE-2022-25510</a> </li>
   <li> <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-42635">CVE-2021-42635</a> </li>
 </ul>
+<p>Secrets should be stored outside of the source code in a configuration file or a management service for secrets.</p>
 <p>This rule detects variables/fields having a name matching a list of words (secret, token, credential, auth, api[_.-]?key) being assigned a
 pseudorandom hard-coded value. The pseudorandomness of the hard-coded value is based on its entropy and the probability to be human-readable. The
 randomness sensibility can be adjusted if needed. Lower values will detect less random values, raising potentially more false positives.</p>
-<h2>How to fix it</h2>
+<h2>Ask Yourself Whether</h2>
+<ul>
+  <li> The secret allows access to a sensitive component like a database, a file storage, an API, or a service. </li>
+  <li> The secret is used in a production environment. </li>
+  <li> Application re-distribution is required before updating the secret. </li>
+</ul>
+<p>There would be a risk if you answered yes to any of those questions.</p>
+<h2>Recommended Secure Coding Practices</h2>
 <ul>
   <li> Store the secret in a configuration file that is not pushed to the code repository. </li>
   <li> Use your cloud provider’s service for managing secrets. </li>
   <li> If a secret has been disclosed through the source code: revoke it and create a new one. </li>
 </ul>
-<h3>Code examples</h3>
-<h4>Noncompliant code example</h4>
+<h2>Sensitive Code Example</h2>
 <pre>
 private static final String MY_SECRET = "47828a8dd77ee1eb9dde2d5e93cb221ce8c32b37";
 
@@ -32,7 +30,7 @@ <h4>Noncompliant code example</h4>
   MyClass.callMyService(MY_SECRET);
 }
 </pre>
-<h4>Compliant solution</h4>
+<h2>Compliant Solution</h2>
 <p>Using <a href="https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/javav2/example_code/secretsmanager">AWS Secrets Manager</a>:</p>
 <pre>
 import software.amazon.awssdk.services.secretsmanager.model.GetSecretValueRequest;
@@ -82,12 +80,7 @@ <h4>Compliant solution</h4>
   MyClass.callMyService(secret);
 }
 </pre>
-<h3>How does this work?</h3>
-<p>This rule detects variables/fields having a name matching a list of words (secret, token, credential, auth, api[_.-]?key) being assigned a
-pseudorandom hard-coded value. The pseudorandomness of the hard-coded value is based on its entropy and the probability to be human-readable. The
-randomness sensibility can be adjusted if needed. Lower values will detect less random values, raising potentially more false positives.</p>
-<h2>Resources</h2>
-<h3>Documentation</h3>
+<h2>See</h2>
 <ul>
   <li> <a href="https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/">OWASP Top 10 2021 Category A7</a> - Identification and
   Authentication Failures </li>
diff --git a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/Sonar_way_profile.json b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/Sonar_way_profile.json
index 6a6538ada36..667ffc5bf56 100644
--- a/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/Sonar_way_profile.json
+++ b/java-checks/src/main/resources/org/sonar/l10n/java/rules/java/Sonar_way_profile.json
@@ -28,7 +28,6 @@
     "S1110",
     "S1111",
     "S1113",
-    "S1114",
     "S1116",
     "S1117",
     "S1118",
@@ -99,7 +98,6 @@
     "S1602",
     "S1604",
     "S1607",
-    "S1610",
     "S1611",
     "S1612",
     "S1640",
diff --git a/sonarpedia.json b/sonarpedia.json
index fd1d7f229bf..1045cf54e11 100644
--- a/sonarpedia.json
+++ b/sonarpedia.json
@@ -3,7 +3,7 @@
   "languages": [
     "JAVA"
   ],
-  "latest-update": "2023-05-30T12:09:42.962798Z",
+  "latest-update": "2023-06-16T15:45:52.052413Z",
   "options": {
     "no-language-in-filenames": true,
     "preserve-filenames": false