@critiq/rules 0.2.0 → 0.4.0

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.

package/rules/java/java.correctness.thread-static-misuse.rule.yaml

@@ -0,0 +1,42 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.thread-static-misuse
+  title: Thread instance calling static Thread methods
+  summary: Calling static Thread methods like sleep(), yield(), or interrupted() on a Thread instance is misleading because they operate on the current thread, not the instance.
+  rationale: Thread.sleep(), Thread.yield(), and Thread.interrupted() are static methods that always act on the current thread. Calling them on a Thread instance suggests they affect that instance, which is incorrect.
+  tags:
+    - correctness
+    - java
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+  aliases:
+    - JAVA-E1062
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.thread-static-misuse
+    bind: issue
+emit:
+  finding:
+    category: correctness.general
+    severity: critical
+    confidence: 0.95
+    tags:
+      - correctness
+      - java
+  message:
+    title: Static Thread method called on instance
+    summary: The static method operates on the current thread, not the instance it appears to be called on.
+  remediation:
+    summary: Call `Thread.sleep(...)` directly instead of calling through a Thread instance.

package/rules/java/java.correctness.threadgroup-deprecated-methods.rule.yaml

@@ -0,0 +1,43 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.threadgroup-deprecated-methods
+  title: Avoid using deprecated ThreadGroup methods
+  summary: ThreadGroup.stop(), .suspend(), .resume(), .destroy(), and related methods are deprecated and unsafe.
+  rationale: ThreadGroup methods can cause deadlocks, resource leaks, and data races. Use java.util.concurrent alternatives.
+  aliases:
+    - JAVA-E1108
+  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.threadgroup-deprecated-methods
+    bind: issue
+emit:
+  finding:
+    category: correctness.concurrency
+    severity: high
+    confidence: 0.95
+    tags:
+      - correctness
+      - java
+  message:
+    title: Deprecated ThreadGroup method call
+    summary: "The ThreadGroup method stop(), suspend(), resume(), destroy(), or a related deprecated method should not be used."
+  remediation:
+    summary: Replace ThreadGroup usage with java.util.concurrent executors and thread pools (ExecutorService, ThreadPoolExecutor). Avoid managing thread groups directly.

package/rules/java/java.correctness.throw-null.rule.yaml

@@ -0,0 +1,42 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.throw-null
+  title: "Avoid throwing null"
+  summary: "`throw null;` throws a `NullPointerException` at the throw site instead of communicating intent. Throw a proper exception instance."
+  rationale: "Java allows `throw null;` because the JVM specification requires the operand to be a reference type, and null is a valid reference. However, this throws a `NullPointerException` rather than the intended exception type, making debugging harder and obscuring developer intent. Always throw a meaningful exception type."
+  aliases:
+    - JAVA-E1097
+  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.throw-null
+    bind: issue
+emit:
+  finding:
+    category: correctness.exceptions
+    severity: critical
+    confidence: 0.95
+    tags:
+      - correctness
+      - java
+  message:
+    title: "throw null will produce NullPointerException in `${captures.issue.text}`"
+    summary: "`throw null;` throws a NullPointerException instead of a meaningful exception. Replace with a proper exception type."
+  remediation:
+    summary: 'Replace `throw null;` with `throw new AppropriateException("message");` using a meaningful exception type.'

package/rules/java/java.correctness.timezone-invalid-id.rule.yaml

@@ -0,0 +1,42 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.timezone-invalid-id
+  title: "TimeZone.getTimeZone() should be passed correct timezone IDs"
+  summary: "`TimeZone.getTimeZone()` silently returns GMT for unrecognized IDs instead of throwing. Hardcoded strings should be valid timezone IDs."
+  rationale: "Unlike `ZoneId.of()`, `TimeZone.getTimeZone()` does not throw for invalid IDs — it silently returns GMT. This makes it easy to miss typos in timezone strings. Always validate timezone IDs or use `TimeZone.getAvailableIDs()` to check."
+  aliases:
+    - JAVA-E1093
+  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.timezone-invalid-id
+    bind: issue
+emit:
+  finding:
+    category: correctness.api-misuse
+    severity: high
+    confidence: 0.40
+    tags:
+      - correctness
+      - java
+  message:
+    title: "TimeZone.getTimeZone() is called with a hardcoded string in `${captures.issue.text}`"
+    summary: "Unrecognized timezone IDs silently return GMT. Verify the ID is valid or use `ZoneId.of()` which throws on invalid input."
+  remediation:
+    summary: "Use `TimeZone.getAvailableIDs()` to check if the ID is valid, or use `ZoneId.of()` with a valid IANA timezone ID."

package/rules/java/java.correctness.two-lock-wait.rule.yaml

@@ -0,0 +1,45 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.two-lock-wait
+  title: wait() called while holding two locks
+  summary: Calling `wait()` while holding multiple locks can cause confusing monitor state and hard-to-diagnose deadlocks.
+  rationale: When `wait()` is called inside nested synchronized blocks, it releases only the lock associated with the object being waited on, keeping the outer lock held. The thread resumes with both locks re-acquired, increasing deadlock risk and making the locking protocol harder to reason about.
+  detection:
+    kind: pattern
+  aliases:
+    - JAVA-E0139
+  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.two-lock-wait
+    bind: issue
+emit:
+  finding:
+    category: correctness.concurrency
+    severity: high
+    confidence: 0.85
+    tags:
+      - correctness
+      - java
+  message:
+    title: wait() called while holding two locks
+    summary: "`${captures.issue.text}` calls `wait()` inside nested synchronized blocks. Only the lock on the waited object is released; the outer lock remains held."
+  remediation:
+    summary: "Restructure to hold only one lock when calling `wait()`, or use `java.util.concurrent` primitives like `ReentrantLock` and `Condition`."

package/rules/java/java.correctness.unconditional-recursion.rule.yaml

@@ -0,0 +1,42 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.unconditional-recursion
+  title: Unconditional recursive call in method body
+  summary: A method calls itself without a conditional guard, causing infinite recursion.
+  rationale: Unconditional self-recursion will always execute, leading to a StackOverflowError at runtime.
+  tags:
+    - correctness
+    - java
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+  aliases:
+    - JAVA-E1017
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.unconditional-recursion
+    bind: issue
+emit:
+  finding:
+    category: correctness.recursion
+    severity: critical
+    confidence: 0.7
+    tags:
+      - correctness
+      - java
+  message:
+    title: "Method `${captures.issue.text}` recursively calls itself unconditionally"
+    summary: A method recursively calls itself without an if/while/for guard, which will always cause infinite recursion at runtime.
+  remediation:
+    summary: Add a base-case guard (if/while/for condition) before the recursive call.

package/rules/java/java.correctness.unescaped-whitespace.rule.yaml

@@ -0,0 +1,42 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.unescaped-whitespace
+  title: Whitespace escape sequences should be properly escaped in regex patterns
+  summary: Whitespace escape sequences like \n, \t, \r, \f, \b in Pattern.compile or String.matches arguments should be double-escaped (\\n, \\t, etc.) to be interpreted as regex escapes rather than Java string escapes.
+  rationale: In Java string literals, \n, \t, \r, \f, and \b are interpreted as actual whitespace characters. When these are passed to regex methods, the regex engine receives the literal character, not the expected escape sequence. Double-escaped sequences (\\n, \\t) pass the regex engine the intended escape.
+  tags:
+    - correctness
+    - java
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+  aliases:
+    - JAVA-E1029
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.unescaped-whitespace
+    bind: issue
+emit:
+  finding:
+    category: correctness.types
+    severity: critical
+    confidence: 0.95
+    tags:
+      - correctness
+      - java
+  message:
+    title: Unescaped whitespace escape sequence in regex pattern
+    summary: The regex pattern contains a single-escaped whitespace character (\n, \t, \r, \f, or \b) that will be interpreted as a Java string escape rather than a regex escape. Use double escaping (\\\\n, \\\\t, etc.) for regex escape sequences.
+  remediation:
+    summary: Replace single-escaped whitespace sequences with double-escaped versions. For example, `\n` becomes `\\n` in a regex pattern string.

package/rules/java/java.correctness.unimplementable-interface.rule.yaml

@@ -0,0 +1,42 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.unimplementable-interface
+  title: Interface method clashes with Object method
+  summary: An interface declares a method that clashes with a final or differently-typed method in Object, making the interface impossible to implement correctly.
+  rationale: Certain Object methods (wait, notify, notifyAll, getClass) are final and cannot be overridden. Others (toString, clone, equals, hashCode, finalize) have specific contract requirements. Declaring them with wrong signatures in an interface creates a contract that can never be satisfied by any implementation.
+  tags:
+    - correctness
+    - java
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+  aliases:
+    - JAVA-E1041
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.unimplementable-interface
+    bind: issue
+emit:
+  finding:
+    category: correctness.typing
+    severity: high
+    confidence: 0.9
+    tags:
+      - correctness
+      - java
+  message:
+    title: Interface method clashes with Object method
+    summary: "`${captures.issue.text}` in an interface clashes with a method inherited from Object and cannot be implemented correctly."
+  remediation:
+    summary: Rename the method or change its signature so it does not conflict with Object's final or contract-restricted methods.

package/rules/java/java.correctness.unsafe-collection-downcast.rule.yaml

@@ -0,0 +1,42 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.unsafe-collection-downcast
+  title: Unsafe collection downcast to concrete type
+  summary: Casting a collection interface reference to a concrete implementation type without an instanceof check may cause ClassCastException at runtime.
+  rationale: Downcasting a collection-typed variable (List, Set, Map, etc.) to a concrete implementation without a prior instanceof check is unsafe. If the runtime type does not match, a ClassCastException is thrown. Always guard downcasts with an instanceof check.
+  tags:
+    - correctness
+    - java
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+  aliases:
+    - JAVA-E1037
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.unsafe-collection-downcast
+    bind: issue
+emit:
+  finding:
+    category: correctness.typing
+    severity: high
+    confidence: 0.85
+    tags:
+      - correctness
+      - java
+  message:
+    title: Unsafe collection downcast
+    summary: "`${captures.issue.text}` downcasts a collection without an instanceof guard, risking ClassCastException."
+  remediation:
+    summary: Add an instanceof check before the cast, or use the interface type throughout.

package/rules/java/java.correctness.unsafe-getresource.rule.yaml

@@ -0,0 +1,45 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.unsafe-getresource
+  title: Unsafe usage of getResource with relative path
+  summary: Using `getClass().getResource()` with a relative path may fail in subclasses.
+  rationale: "`getResource()` on a Class instance resolves relative to that class's package. Use absolute paths or `ClassLoader.getResource()`."
+  detection:
+    kind: pattern
+  aliases:
+    - JAVA-E0029
+  tags:
+    - correctness
+    - java
+    - resource-loading
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.unsafe-getresource
+    bind: issue
+emit:
+  finding:
+    category: correctness.resource-loading
+    severity: medium
+    confidence: 0.85
+    tags:
+      - correctness
+      - java
+  message:
+    title: Unsafe relative getResource call
+    summary: "`${captures.issue.text}` uses a relative path with getResource. This may fail when called on a subclass."
+  remediation:
+    summary: Prefer absolute path starting with `/` or use `Thread.currentThread().getContextClassLoader().getResource()`.

package/rules/java/java.correctness.unsupported-jdk-api.rule.yaml

@@ -0,0 +1,46 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.unsupported-jdk-api
+  title: Unsupported JDK-internal APIs should not be used
+  summary: Importing or using sun.* or com.sun.* internal APIs introduces portability issues and risks breakage across JDK versions.
+  rationale: Internal JDK APIs (sun.*, com.sun.* packages) are undocumented, unsupported, and may change or be removed without notice. Java 9 introduced module system restrictions that prevent access to many of these APIs. Use public replacement APIs instead.
+  references:
+    - kind: cwe
+      id: CWE-1104
+      title: Use of Unmaintained Third-Party Components
+  tags:
+    - correctness
+    - java
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+  aliases:
+    - JAVA-E1030
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.unsupported-jdk-api
+    bind: issue
+emit:
+  finding:
+    category: correctness.portability
+    severity: high
+    confidence: 0.90
+    tags:
+      - correctness
+      - java
+  message:
+    title: Use of internal JDK API
+    summary: The code imports or references an unsupported internal JDK API (`sun.*` or `com.sun.*`). These are not part of the public Java specification and may break across JDK versions.
+  remediation:
+    summary: Replace the internal API call with the public equivalent. For example, use `java.util.Base64` instead of `sun.misc.BASE64Encoder`.