@critiq/rules 0.3.0 → 0.4.0

package/rules/java/java.correctness.overloaded-equals.rule.yaml

@@ -0,0 +1,45 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.overloaded-equals
+  title: equals method is overloaded but not overridden
+  summary: A method named `equals` with a non-Object parameter type overloads rather than overrides equals.
+  rationale: Using `equals(SomeType obj)` instead of `equals(Object obj)` overloads the equals method without overriding it, so collections and utility methods will use Object.equals (identity) instead of the intended comparison logic.
+  detection:
+    kind: pattern
+  aliases:
+    - JAVA-E0098
+  tags:
+    - correctness
+    - java
+    - types
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.overloaded-equals
+    bind: issue
+emit:
+  finding:
+    category: correctness.types
+    severity: medium
+    confidence: 0.85
+    tags:
+      - correctness
+      - java
+  message:
+    title: equals() is overloaded, not overridden
+    summary: "`${captures.issue.text}` overloads equals without overriding it. Change the parameter type to `Object`."
+  remediation:
+    summary: "Change the parameter type from a specific type to `Object` to properly override equals."

package/rules/java/java.correctness.parameter-reassignment.rule.yaml

@@ -0,0 +1,46 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.parameter-reassignment
+  title: Parameter reassignment
+  summary: Reassigning a method parameter is confusing and can mask bugs; prefer a local variable.
+  rationale: Reassigning a method parameter makes the code harder to read and debug because the parameter's value changes within the method body. This is a well-known best practice violation (similar to why `final` is recommended for parameters). Create a separate local variable instead.
+  detection:
+    kind: pattern
+  aliases:
+    - JAVA-S0352
+    - JAVA-E0352
+  tags:
+    - correctness
+    - java
+    - defensive-programming
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.parameter-reassignment
+    bind: issue
+emit:
+  finding:
+    category: correctness.defensive-programming
+    severity: low
+    confidence: 0.88
+    tags:
+      - correctness
+      - java
+  message:
+    title: Reassign method parameter in `${captures.issue.text}`
+    summary: "`${captures.issue.text}` reassigns a method parameter. Use a local variable instead."
+  remediation:
+    summary: "Declare a new local variable instead of reassigning the parameter (e.g. `var newValue = parameter`)"

package/rules/java/java.correctness.possible-null-access-exception.rule.yaml

@@ -0,0 +1,42 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.possible-null-access-exception
+  title: Avoid possible null access in catch or finally blocks
+  summary: Dereferencing a variable in a catch or finally block may throw a NullPointerException if the variable was assigned from a failed operation.
+  rationale: Variables assigned before or during a try block may be null when the catch or finally block executes, leading to a secondary NullPointerException that masks the original failure.
+  aliases:
+    - JAVA-E1084
+  tags:
+    - correctness
+    - java
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.possible-null-access-exception
+    bind: issue
+emit:
+  finding:
+    category: correctness.null-safety
+    severity: critical
+    confidence: 0.65
+    tags:
+      - correctness
+      - java
+  message:
+    title: Possible null access in exception handler from `${captures.issue.text}`
+    summary: "A variable is dereferenced in a catch or finally block without a null check, which may throw a NullPointerException when the handler runs."
+  remediation:
+    summary: Add a null check before dereferencing variables in catch and finally blocks, or initialize them to safe defaults before the try block.

package/rules/java/java.correctness.possible-null-access.rule.yaml

@@ -0,0 +1,42 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.possible-null-access
+  title: Avoid possible null access on collection or map lookups
+  summary: Chaining a method call on a `.get()`, `.poll()`, or `.peek()` result may throw a NullPointerException.
+  rationale: Collection and map lookups can return null for missing keys; dereferencing the result without a null check will throw a NullPointerException at runtime.
+  aliases:
+    - JAVA-E1083
+  tags:
+    - correctness
+    - java
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.possible-null-access
+    bind: issue
+emit:
+  finding:
+    category: correctness.null-safety
+    severity: critical
+    confidence: 0.72
+    tags:
+      - correctness
+      - java
+  message:
+    title: Possible null access from `${captures.issue.text}`
+    summary: "The result of a `.get()`, `.poll()`, or `.peek()` call is dereferenced without a null check, which may throw a NullPointerException."
+  remediation:
+    summary: Assign the result to a local variable, check for null, and handle the absent case before dereferencing.

package/rules/java/java.correctness.prepared-statement-in-loop.rule.yaml

@@ -0,0 +1,52 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.prepared-statement-in-loop
+  title: PreparedStatement creation inside a loop
+  summary: Creating PreparedStatement or CallableStatement inside a loop causes repeated database parsing and compilation, leading to performance degradation and potential resource exhaustion.
+  rationale: PreparedStatements should be created outside loops and reused with different parameters to avoid repeated SQL parsing and compilation. Creating them inside loops can also exhaust the database statement cache.
+  detection:
+    kind: pattern
+  references:
+    - kind: cwe
+      id: CWE-400
+      title: Uncontrolled Resource Consumption
+  aliases:
+    - JAVA-S0329
+    - JAVA-P1003
+  tags:
+    - correctness
+    - java
+    - jdbc
+    - performance
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.prepared-statement-in-loop
+    bind: issue
+emit:
+  finding:
+    category: correctness.jdbc
+    severity: medium
+    confidence: 0.85
+    tags:
+      - correctness
+      - java
+      - jdbc
+  message:
+    title: Move PreparedStatement creation outside the loop in `${captures.issue.text}`
+    summary: "`${captures.issue.text}` creates a PreparedStatement or CallableStatement inside a loop. Move it outside and reuse with different parameters."
+  remediation:
+    summary: "Create the PreparedStatement before the loop and set parameters inside using `setString`, `setInt`, etc."

package/rules/java/java.correctness.prepared-statement-index-zero.rule.yaml

@@ -0,0 +1,44 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.prepared-statement-index-zero
+  title: PreparedStatement parameter set with index 0
+  summary: JDBC PreparedStatement parameters use 1-based indexing; index 0 is invalid.
+  rationale: Setting a parameter at index 0 will always throw SQLException. JDBC parameter indices start at 1.
+  detection:
+    kind: pattern
+  aliases:
+    - JAVA-E0344
+  tags:
+    - correctness
+    - java
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.prepared-statement-index-zero
+    bind: issue
+emit:
+  finding:
+    category: correctness.api-usage
+    severity: critical
+    confidence: 0.95
+    tags:
+      - correctness
+      - java
+  message:
+    title: PreparedStatement parameter set with index 0
+    summary: "`${captures.issue.text}` uses PreparedStatement with index 0, but JDBC parameters start at 1. This will always throw SQLException."
+  remediation:
+    summary: Use 1-based parameter index (e.g., `setString(1, value)` for the first parameter).

package/rules/java/java.correctness.random-coerced-to-zero.rule.yaml

@@ -0,0 +1,44 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.random-coerced-to-zero
+  title: Casting Math.random() to int without scaling always returns zero
+  summary: Casting Math.random() to int directly (without multiplying) always yields zero.
+  rationale: "Math.random() returns a double in range [0.0, 1.0). Casting to int truncates to zero every time. Multiply by the desired range before casting."
+  detection:
+    kind: pattern
+  aliases:
+    - JAVA-E1068
+  tags:
+    - correctness
+    - java
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.random-coerced-to-zero
+    bind: issue
+emit:
+  finding:
+    category: correctness.logic
+    severity: low
+    confidence: 0.85
+    tags:
+      - correctness
+      - java
+  message:
+    title: Random value coerced to zero
+    summary: "`${captures.issue.text}` truncates the random value to zero. Multiply by the desired bound before casting."
+  remediation:
+    summary: Multiply Math.random() by the desired range before casting, e.g. `(int) (Math.random() * max)`. Or for integer ranges use `new Random().nextInt(bound)`.

package/rules/java/java.correctness.read-resolve-return-type.rule.yaml

@@ -0,0 +1,42 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.read-resolve-return-type
+  title: readResolve must return Object
+  summary: The readResolve method in a Serializable class must have a return type of Object. A non-Object return type will cause the method to be silently ignored during deserialization.
+  rationale: Java's serialization mechanism uses readResolve to replace the deserialized object. Per the Java Object Serialization Specification (§3.6), readResolve must be declared as `ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException`. A covariant return type may work in some JVM implementations but is not guaranteed.
+  tags:
+    - correctness
+    - java
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+  aliases:
+    - JAVA-E1032
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.read-resolve-return-type
+    bind: issue
+emit:
+  finding:
+    category: correctness.serialization
+    severity: high
+    confidence: 0.90
+    tags:
+      - correctness
+      - java
+  message:
+    title: readResolve method must return Object
+    summary: "`${captures.issue.text}` has a non-Object return type. The serialization mechanism requires `Object` as the return type for `readResolve`."
+  remediation:
+    summary: Change the return type of `readResolve` to `Object` and cast the return value inside the method body.

package/rules/java/java.correctness.readline-without-null-check.rule.yaml

@@ -0,0 +1,45 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.readline-without-null-check
+  title: readLine() result used without null check
+  summary: The result of `readLine()` is dereferenced without a null check.
+  rationale: "BufferedReader.readLine() returns null when the end of the stream is reached. Using the result without checking for null will throw a NullPointerException."
+  detection:
+    kind: pattern
+  aliases:
+    - JAVA-E0220
+  tags:
+    - correctness
+    - java
+    - null-safety
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.readline-without-null-check
+    bind: issue
+emit:
+  finding:
+    category: correctness.null-safety
+    severity: high
+    confidence: 0.80
+    tags:
+      - correctness
+      - java
+  message:
+    title: readLine() result used without null check
+    summary: The result of `readLine()` may be null — dereferencing it without a check will cause a NullPointerException.
+  remediation:
+    summary: Add a null check before using the result, e.g. `String s = r.readLine(); if (s != null) { s.trim(); }`

package/rules/java/java.correctness.result-set-index-zero.rule.yaml

@@ -0,0 +1,44 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.result-set-index-zero
+  title: ResultSet accessed with index 0
+  summary: JDBC ResultSet methods use 1-based indexing; index 0 is invalid.
+  rationale: Calling getString(0) or updateInt(0) on a ResultSet always throws SQLException. JDBC column indices start at 1.
+  detection:
+    kind: pattern
+  aliases:
+    - JAVA-E0343
+  tags:
+    - correctness
+    - java
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.result-set-index-zero
+    bind: issue
+emit:
+  finding:
+    category: correctness.api-usage
+    severity: critical
+    confidence: 0.95
+    tags:
+      - correctness
+      - java
+  message:
+    title: ResultSet accessed with index 0
+    summary: "`${captures.issue.text}` uses JDBC ResultSet with index 0, but JDBC indices start at 1. This will always throw SQLException."
+  remediation:
+    summary: Use 1-based column index (e.g., `getString(1)` for the first column).

package/rules/java/java.correctness.runfinalizers-on-exit.rule.yaml

@@ -0,0 +1,45 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.runfinalizers-on-exit
+  title: System.runFinalizersOnExit/Runtime.runFinalizersOnExit is unsafe
+  summary: Calling `System.runFinalizersOnExit()` or `Runtime.runFinalizersOnExit()` is inherently unsafe.
+  rationale: These methods are deprecated and dangerous — they invoke finalizers on live objects during VM shutdown, potentially causing thread-safety issues and unpredictable behavior.
+  detection:
+    kind: pattern
+  aliases:
+    - JAVA-E0061
+  tags:
+    - correctness
+    - java
+    - unsafe-api
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.runfinalizers-on-exit
+    bind: issue
+emit:
+  finding:
+    category: correctness.unsafe-api
+    severity: critical
+    confidence: 0.95
+    tags:
+      - correctness
+      - java
+  message:
+    title: Unsafe runFinalizersOnExit call
+    summary: "`${captures.issue.text}` is an unsafe deprecated API that should never be called."
+  remediation:
+    summary: "Remove the call entirely. Use `Runtime.addShutdownHook()` for JVM shutdown logic instead."

package/rules/java/java.correctness.runnable-run-direct.rule.yaml

@@ -0,0 +1,45 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.runnable-run-direct
+  title: Runnable's run() method called directly instead of using Thread.start()
+  summary: Calling `run()` on a Thread or Runnable directly bypasses the new thread and executes in the caller's thread.
+  rationale: Invoking `run()` directly instead of `start()` executes the Runnable's code synchronously in the current thread, defeating the purpose of threading. This is almost always a bug; use `start()` to launch a new thread.
+  detection:
+    kind: pattern
+  aliases:
+    - JAVA-E0135
+  tags:
+    - correctness
+    - java
+    - concurrency
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.runnable-run-direct
+    bind: issue
+emit:
+  finding:
+    category: correctness.concurrency
+    severity: medium
+    confidence: 0.85
+    tags:
+      - correctness
+      - java
+  message:
+    title: Direct call to run() instead of start()
+    summary: "`${captures.issue.text}` calls `run()` directly on a Thread or Runnable. Use `start()` to execute in a new thread."
+  remediation:
+    summary: "Replace `thread.run()` with `thread.start()` to execute the Runnable in a new thread."

package/rules/java/java.correctness.self-assignment.rule.yaml

@@ -0,0 +1,45 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.self-assignment
+  title: Self assignment of local variable
+  summary: A local variable is assigned to itself, which has no effect.
+  rationale: "`x = x;` is a no-op and indicates either a typo or dead code. If the intent was to assign from a field, `this.x = x;` should be used."
+  detection:
+    kind: pattern
+  aliases:
+    - JAVA-E0291
+  tags:
+    - correctness
+    - java
+    - logic
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.self-assignment
+    bind: issue
+emit:
+  finding:
+    category: correctness.logic
+    severity: high
+    confidence: 0.90
+    tags:
+      - correctness
+      - java
+  message:
+    title: Self assignment of local variable
+    summary: "`${captures.issue.text}` assigns a variable to itself, which is a no-op."
+  remediation:
+    summary: Remove the self-assignment or use `this.x = x` if you intended to assign a parameter to a field.

package/rules/java/java.correctness.serializable-superclass.rule.yaml

@@ -0,0 +1,42 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.serializable-superclass
+  title: Serializable class with non-serializable superclass and no default constructor
+  summary: A Serializable class has a non-serializable superclass that may lack a no-arg constructor, which will cause deserialization to fail with InvalidClassException.
+  rationale: During deserialization, the JVM instantiates the first non-serializable superclass using its no-arg constructor. If that constructor does not exist, deserialization fails. Every non-serializable superclass of a Serializable class must provide a no-arg constructor accessible to the subclass.
+  tags:
+    - correctness
+    - java
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+  aliases:
+    - JAVA-E1034
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.serializable-superclass
+    bind: issue
+emit:
+  finding:
+    category: correctness.serialization
+    severity: high
+    confidence: 0.85
+    tags:
+      - correctness
+      - java
+  message:
+    title: Potential deserialization issue with non-serializable superclass
+    summary: The class `${captures.issue.text}` implements Serializable but extends a non-serializable superclass. If the superclass lacks a no-arg constructor, deserialization will fail with `InvalidClassException`.
+  remediation:
+    summary: Ensure the non-serializable superclass has a no-arg constructor, or make it implement Serializable. Note that this finding is heuristic and requires manual verification of the superclass constructor.

package/rules/java/java.correctness.serialization-method-signature.rule.yaml

@@ -0,0 +1,42 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.serialization-method-signature
+  title: Custom serialization method declared with incorrect signature
+  summary: Serializable classes declaring writeObject, readObject, or readObjectNoData must use exactly the correct signatures expected by the serialization API.
+  rationale: Java's serialization mechanism calls writeObject, readObject, and readObjectNoData by reflection using exact signature matching. If the access modifier, return type, or parameter types are wrong, the method is silently ignored and default serialization behavior applies.
+  tags:
+    - correctness
+    - java
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+  aliases:
+    - JAVA-E1033
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.serialization-method-signature
+    bind: issue
+emit:
+  finding:
+    category: correctness.serialization
+    severity: high
+    confidence: 0.90
+    tags:
+      - correctness
+      - java
+  message:
+    title: Incorrect serialization method signature
+    summary: The serialization method `${captures.issue.text}` does not match the required signature. writeObject must be `private void writeObject(java.io.ObjectOutputStream out) throws IOException`, readObject must be `private void readObject(java.io.ObjectInputStream in) throws IOException`, and readObjectNoData must be `private void readObjectNoData() throws ObjectStreamException`.
+  remediation:
+    summary: Correct the method signature to match the expected pattern. Ensure private access, void return type, correct parameter types, and the proper throws clause.