@critiq/rules 0.3.0 → 0.4.0

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.

package/rules/java/java.correctness.sync-on-nullable-field.rule.yaml

@@ -0,0 +1,42 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.sync-on-nullable-field
+  title: Possibly null fields synchronized on
+  summary: Synchronizing on a field that may be null will throw NullPointerException at runtime.
+  rationale: The field has no initializer and is used as a synchronization lock. If the field is null when synchronized is reached, a NullPointerException is thrown.
+  tags:
+    - correctness
+    - java
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+  aliases:
+    - JAVA-E1060
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.sync-on-nullable-field
+    bind: issue
+emit:
+  finding:
+    category: correctness.concurrency
+    severity: critical
+    confidence: 0.65
+    tags:
+      - correctness
+      - java
+  message:
+    title: Synchronizing on a nullable field
+    summary: The field used as a lock may be null, causing NullPointerException at runtime.
+  remediation:
+    summary: Initialize the lock field at declaration, or guard with Objects.requireNonNull() before synchronizing.

package/rules/java/java.correctness.sync-on-public-field.rule.yaml

@@ -0,0 +1,42 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.sync-on-public-field
+  title: Public fields synchronized on
+  summary: Synchronizing on a public field allows external code to interfere with synchronization.
+  rationale: A public field used as a lock is visible to all code, which can synchronize on the same object and cause deadlock or interfere with locking contracts.
+  tags:
+    - correctness
+    - java
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+  aliases:
+    - JAVA-E1061
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.sync-on-public-field
+    bind: issue
+emit:
+  finding:
+    category: correctness.concurrency
+    severity: high
+    confidence: 0.70
+    tags:
+      - correctness
+      - java
+  message:
+    title: Synchronizing on a public field
+    summary: External code can synchronize on the same public lock, potentially causing deadlock or interference.
+  remediation:
+    summary: Use a private lock object for internal synchronization.

package/rules/java/java.correctness.sync-on-string-literal.rule.yaml

@@ -5,6 +5,8 @@ metadata:
   title: Do not synchronize on string literals
   summary: String literals are interned and shared across the JVM.
   rationale: Synchronizing on interned strings can cause unexpected deadlocks.
+  aliases:
+    - JAVA-E1081
   tags:
     - correctness
     - java

package/rules/java/java.correctness.system-exit.rule.yaml

@@ -0,0 +1,43 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.system-exit
+  title: "System.exit() should only be invoked within application entry points"
+  summary: "Calling `System.exit()` outside of `main()` or framework entry points makes code hard to test and may terminate the JVM unexpectedly."
+  rationale: "`System.exit()` terminates the JVM immediately. When called from libraries, utility methods, or non-entry-point code it prevents cleanup, makes unit testing impossible (tests exit prematurely), and couples callers to a specific runtime behavior. Consider throwing a meaningful exception or returning a status code instead."
+  aliases:
+    - JAVA-S0060
+  tags:
+    - correctness
+    - java
+    - control-flow
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.system-exit
+    bind: issue
+emit:
+  finding:
+    category: correctness.control-flow
+    severity: high
+    confidence: 0.60
+    tags:
+      - correctness
+      - java
+  message:
+    title: "Unexpected System.exit() call in `${captures.issue.text}`"
+    summary: "`${captures.issue.text}` terminates the JVM. Prefer throwing an exception or returning a status code."
+  remediation:
+    summary: "Replace `System.exit()` with a thrown exception or a meaningful return value to allow callers to handle the error gracefully."

package/rules/java/java.correctness.thread-sleep-with-lock.rule.yaml

@@ -0,0 +1,45 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.thread-sleep-with-lock
+  title: Thread.sleep() should not be called while a lock is held
+  summary: Calling Thread.sleep() inside a synchronized block keeps the lock held, causing contention or deadlocks.
+  rationale: Thread.sleep() does not release the monitor lock. If called inside synchronized, other threads are blocked for the full sleep duration. Use wait(timeout) instead, which releases the lock.
+  detection:
+    kind: pattern
+  aliases:
+    - JAVA-E0410
+  tags:
+    - correctness
+    - java
+    - concurrency
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.thread-sleep-with-lock
+    bind: issue
+emit:
+  finding:
+    category: correctness.concurrency
+    severity: critical
+    confidence: 0.70
+    tags:
+      - correctness
+      - java
+  message:
+    title: Thread.sleep() inside synchronized block
+    summary: Calling Thread.sleep() while holding a lock blocks all other threads waiting for the same monitor.
+  remediation:
+    summary: Replace Thread.sleep() inside synchronized blocks with wait(timeout). If waiting outside synchronized is acceptable, move the sleep call outside the block.