@critiq/rules 0.2.0 → 0.4.0

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.

package/rules/java/java.correctness.servlet-mutable-fields.rule.yaml

@@ -0,0 +1,45 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.servlet-mutable-fields
+  title: Mutable fields in HttpServlet subclasses
+  summary: Mutable fields in an HttpServlet subclass can cause thread-safety issues because servlets are typically shared across requests.
+  rationale: Servlets are singletons — a single instance handles multiple concurrent requests. Non-final mutable fields accessed without synchronization can produce corrupted state and unpredictable behavior.
+  detection:
+    kind: pattern
+  aliases:
+    - JAVA-E0128
+    - JAVA-E0370
+  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.servlet-mutable-fields
+    bind: issue
+emit:
+  finding:
+    category: correctness.concurrency
+    severity: high
+    confidence: 0.75
+    tags:
+      - correctness
+      - java
+  message:
+    title: Mutable field in HttpServlet subclass
+    summary: "Field `${captures.issue.text}` in a servlet subclass is mutable and accessed without synchronization. Servlets are singletons shared across threads."
+  remediation:
+    summary: "Declare the field as `final` and use local variables or synchronization when accessing mutable state from servlet methods."

package/rules/java/java.correctness.shift-out-of-range.rule.yaml

@@ -0,0 +1,44 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.shift-out-of-range
+  title: Shift amounts outside the valid range may produce unexpected results
+  summary: Bit-shift operations with out-of-range amounts produce undefined or unexpected behavior for int and long operands.
+  rationale: Shifting an int by >= 32 or by a negative amount yields implementation-defined results. Long shifts must be in [0, 63].
+  detection:
+    kind: pattern
+  aliases:
+    - JAVA-E0399
+  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.shift-out-of-range
+    bind: issue
+emit:
+  finding:
+    category: correctness.arithmetic
+    severity: high
+    confidence: 0.85
+    tags:
+      - correctness
+      - java
+  message:
+    title: Shift amount outside valid range
+    summary: Shift amount is outside the valid bit-width range for the left operand type (0-31 for int, 0-63 for long).
+  remediation:
+    summary: Ensure shift amounts are non-negative and within the bit-width of the left operand (0-31 for int, 0-63 for long).

package/rules/java/java.correctness.static-date-field.rule.yaml

@@ -0,0 +1,42 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.static-date-field
+  title: Public or protected static date/time formatter field
+  summary: A non-thread-safe date/time formatter or calendar is declared as a public/protected static field.
+  rationale: SimpleDateFormat, DateFormat, and Calendar are not thread-safe. Shared mutable access from multiple threads can cause erratic behavior or exceptions.
+  tags:
+    - correctness
+    - java
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+  aliases:
+    - JAVA-E1024
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.static-date-field
+    bind: issue
+emit:
+  finding:
+    category: correctness.concurrency
+    severity: high
+    confidence: 0.85
+    tags:
+      - correctness
+      - java
+  message:
+    title: Public/protected static date formatter field
+    summary: A non-thread-safe date/time formatter is shared across threads via a static field, risking corrupted output or exceptions.
+  remediation:
+    summary: Use a ThreadLocal wrapper, DateTimeFormatter (Java 8+), or a local instance per use.

package/rules/java/java.correctness.stream-reuse.rule.yaml

@@ -0,0 +1,42 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.stream-reuse
+  title: Stream consumed more than once
+  summary: A Stream variable has multiple terminal operations invoked on it.
+  rationale: Java Streams are single-use; after a terminal operation the stream is consumed and throws IllegalStateException on reuse.
+  tags:
+    - correctness
+    - java
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+  aliases:
+    - JAVA-E1019
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.stream-reuse
+    bind: issue
+emit:
+  finding:
+    category: correctness.streams
+    severity: high
+    confidence: 0.8
+    tags:
+      - correctness
+      - java
+  message:
+    title: Stream is consumed more than once
+    summary: A terminal operation is called on a Stream that has already been consumed, causing IllegalStateException.
+  remediation:
+    summary: Create a new Stream for each terminal operation, or collect the stream into a collection first.

package/rules/java/java.correctness.string-format-arg-mismatch.rule.yaml

@@ -0,0 +1,45 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.string-format-arg-mismatch
+  title: Arguments to String.format must match the provided format string
+  summary: The number of format specifiers in the format string does not match the number of arguments provided.
+  rationale: A mismatch causes MissingFormatArgumentException (too few arguments) or silently ignored extra arguments (too many).
+  detection:
+    kind: pattern
+  aliases:
+    - JAVA-E1001
+  tags:
+    - correctness
+    - java
+    - input-validation
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.string-format-arg-mismatch
+    bind: issue
+emit:
+  finding:
+    category: correctness.api-usage
+    severity: critical
+    confidence: 0.85
+    tags:
+      - correctness
+      - java
+  message:
+    title: String.format argument count mismatch
+    summary: The format string contains a different number of format specifiers than the number of arguments provided.
+  remediation:
+    summary: Ensure the format string specifier count matches the argument count. Use %n$s positional specifiers for reordering.

package/rules/java/java.correctness.stringbuilder-char-ctor.rule.yaml

@@ -0,0 +1,42 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.stringbuilder-char-ctor
+  title: StringBuilder or StringBuffer constructed with a char literal
+  summary: StringBuilder/StringBuffer constructed with a single char argument behaves as a capacity argument, not a string value.
+  rationale: In Java, StringBuilder(char) calls StringBuilder(int) via char-to-int widening, creating a builder with capacity equal to the char's numeric value instead of containing the character.
+  tags:
+    - correctness
+    - java
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+  aliases:
+    - JAVA-E1023
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.stringbuilder-char-ctor
+    bind: issue
+emit:
+  finding:
+    category: correctness.types
+    severity: critical
+    confidence: 0.95
+    tags:
+      - correctness
+      - java
+  message:
+    title: StringBuilder/StringBuffer constructed with char literal
+    summary: A char literal argument to StringBuilder/StringBuffer is widened to int and used as a capacity. Use a String literal instead.
+  remediation:
+    summary: Replace the char literal with a String literal, e.g. `new StringBuilder("a")` instead of `new StringBuilder('a')`.

package/rules/java/java.correctness.switch-statement-labels.rule.yaml

@@ -0,0 +1,44 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.switch-statement-labels
+  title: Switch blocks must not contain statement labels
+  summary: Statement labels inside switch blocks are confusing and likely unintended.
+  rationale: Traditional Java switch blocks allow arbitrary statement labels, but they are error-prone and easily confused with case labels. Switch expressions and modern switch blocks do not permit them.
+  detection:
+    kind: pattern
+  aliases:
+    - JAVA-E1005
+  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.switch-statement-labels
+    bind: issue
+emit:
+  finding:
+    category: correctness.control-flow
+    severity: critical
+    confidence: 0.85
+    tags:
+      - correctness
+      - java
+  message:
+    title: Statement label inside switch block
+    summary: "`${captures.issue.text}` is a statement label inside a switch block. Only case and default labels are expected."
+  remediation:
+    summary: Remove the statement label or restructure the switch block to avoid non-case labels.

package/rules/java/java.correctness.sync-boxed-primitive.rule.yaml

@@ -0,0 +1,45 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.sync-boxed-primitive
+  title: Do not synchronize on boxed primitives
+  summary: Synchronizing on a boxed primitive (Integer, Long, Boolean, etc.) is unsafe due to interning and caching.
+  rationale: Boxed primitive objects can be interned or cached by the JVM (e.g., Integer.valueOf(0) returns a cached instance). Synchronizing on such objects can cause unexpected contention and deadlocks across unrelated code paths that happen to use the same cached value.
+  detection:
+    kind: pattern
+  aliases:
+    - JAVA-E0150
+  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.sync-boxed-primitive
+    bind: issue
+emit:
+  finding:
+    category: correctness.concurrency
+    severity: medium
+    confidence: 0.90
+    tags:
+      - correctness
+      - java
+  message:
+    title: Avoid synchronizing on a boxed primitive
+    summary: "`${captures.issue.text}` locks on a boxed primitive, which may be interned or cached by the JVM."
+  remediation:
+    summary: Synchronize on a dedicated `private final Object` lock instead.

package/rules/java/java.correctness.sync-on-get-class.rule.yaml

@@ -0,0 +1,42 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.sync-on-get-class
+  title: Synchronizing on the result of getClass()
+  summary: Synchronizing on `getClass()` locks on the runtime Class object, which can vary for subclasses.
+  rationale: The Class object returned by getClass() is the actual runtime class, which may differ across subclasses and cause unexpected lock behavior.
+  tags:
+    - correctness
+    - java
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+  aliases:
+    - JAVA-E1021
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.sync-on-get-class
+    bind: issue
+emit:
+  finding:
+    category: correctness.concurrency
+    severity: high
+    confidence: 0.95
+    tags:
+      - correctness
+      - java
+  message:
+    title: Avoid synchronizing on getClass()
+    summary: Locking on `getClass()` binds the lock to the runtime class, not a fixed object, making synchronization unreliable across class hierarchies.
+  remediation:
+    summary: Synchronize on a private final lock object or on `ClassName.class` for a fixed lock.

package/rules/java/java.correctness.sync-on-lock-primitive.rule.yaml

@@ -0,0 +1,45 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.sync-on-lock-primitive
+  title: Synchronization on a Lock/concurrency primitive
+  summary: Synchronizing on a ReentrantLock or other lock primitive defeats the lock's purpose.
+  rationale: "Lock objects (ReentrantLock, ReadWriteLock, StampedLock) are designed for lock-based concurrency, not intrinsic synchronization. Using `synchronized(lock)` on a Lock instance is incorrect and indicates a concurrency design flaw."
+  detection:
+    kind: pattern
+  aliases:
+    - JAVA-E0321
+  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.sync-on-lock-primitive
+    bind: issue
+emit:
+  finding:
+    category: correctness.concurrency
+    severity: medium
+    confidence: 0.90
+    tags:
+      - correctness
+      - java
+  message:
+    title: Synchronizing on a Lock primitive
+    summary: "`${captures.issue.text}` synchronizes on a Lock/concurrency primitive, which is incorrect. Lock instances are designed for explicit locking via `lock()`/`unlock()`, not intrinsic synchronization."
+  remediation:
+    summary: Use `lock()` and `unlock()` on the Lock instance instead of `synchronized(lock){}`.

package/rules/java/java.correctness.sync-on-mutable-ref.rule.yaml

@@ -0,0 +1,42 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.sync-on-mutable-ref
+  title: Synchronizing on a mutable reference
+  summary: Synchronizing on a non-final field means the lock object can be reassigned, breaking synchronization guarantees.
+  rationale: Synchronizing on a non-final field is unsafe because the field can be reassigned at runtime, causing threads to synchronize on different objects.
+  tags:
+    - correctness
+    - java
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+  aliases:
+    - JAVA-E1051
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.sync-on-mutable-ref
+    bind: issue
+emit:
+  finding:
+    category: correctness.concurrency
+    severity: high
+    confidence: 0.70
+    tags:
+      - correctness
+      - java
+  message:
+    title: Avoid synchronizing on a non-final field
+    summary: The lock object can be reassigned at runtime, making synchronization unreliable.
+  remediation:
+    summary: Use a private final lock object or make the field final.