@critiq/rules 0.3.0 → 0.4.0

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`.

package/rules/java/java.correctness.unsupported-method-call.rule.yaml

@@ -0,0 +1,42 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.unsupported-method-call
+  title: Call to method that always throws UnsupportedOperationException
+  summary: A final method that throws UnsupportedOperationException is called from another method, which will always fail at runtime.
+  rationale: If a method is declared as final (or is in a final class) and its body throws UnsupportedOperationException, calling that method will always result in an exception. This represents dead code or a logic error in the caller.
+  tags:
+    - correctness
+    - java
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+  aliases:
+    - JAVA-E1048
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.unsupported-method-call
+    bind: issue
+emit:
+  finding:
+    category: correctness.api-usage
+    severity: high
+    confidence: 0.85
+    tags:
+      - correctness
+      - java
+  message:
+    title: Call to method that throws UnsupportedOperationException
+    summary: "`${captures.issue.text}` calls a final method that always throws UnsupportedOperationException."
+  remediation:
+    summary: Remove the call or implement the throwing method properly.

package/rules/java/java.correctness.unsync-static-lazy-init.rule.yaml

@@ -0,0 +1,42 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.unsync-static-lazy-init
+  title: Unsynchronized lazy initialization of static value
+  summary: Static field lazy initialization without synchronization can expose partially constructed objects to other threads.
+  rationale: Without synchronization or a holder class, one thread may see a partially initialized static field due to the Java Memory Model.
+  tags:
+    - correctness
+    - java
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+  aliases:
+    - JAVA-E1053
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.unsync-static-lazy-init
+    bind: issue
+emit:
+  finding:
+    category: correctness.concurrency
+    severity: critical
+    confidence: 0.75
+    tags:
+      - correctness
+      - java
+  message:
+    title: Unsynchronized static lazy initialization
+    summary: The static field is lazily initialized without synchronization, risking visibility of a partially constructed object.
+  remediation:
+    summary: Use a synchronized block, a synchronized method, or the holder-class idiom for thread-safe lazy initialization.

package/rules/java/java.correctness.unsynchronized-wait-notify.rule.yaml

@@ -0,0 +1,45 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.unsynchronized-wait-notify
+  title: wait()/notify() called without synchronization
+  summary: Object.wait(), notify(), or notifyAll() called outside a synchronized block.
+  rationale: "Calling wait(), notify(), or notifyAll() without holding the object's monitor throws IllegalMonitorStateException and indicates a concurrency bug."
+  detection:
+    kind: pattern
+  aliases:
+    - JAVA-E0288
+  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.unsynchronized-wait-notify
+    bind: issue
+emit:
+  finding:
+    category: correctness.concurrency
+    severity: high
+    confidence: 0.90
+    tags:
+      - correctness
+      - java
+  message:
+    title: wait()/notify() called without synchronization
+    summary: The call to `wait()`, `notify()`, or `notifyAll()` is not inside a synchronized block, which will throw IllegalMonitorStateException.
+  remediation:
+    summary: Wrap the call in a synchronized block on the same object, e.g. `synchronized (obj) { obj.wait(); }`

package/rules/java/java.correctness.unterminated-assertion-chain.rule.yaml

@@ -0,0 +1,39 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.unterminated-assertion-chain
+  title: "Assertion chain methods must be terminated with an assertion"
+  summary: "Calls to `assertThat()` or `verify()` must include a chained assertion (e.g. `.isEqualTo()`, `.isGreaterThan()`) or the test assertion is silently ignored."
+  rationale: "Calling `assertThat(value)` or `verify(mock)` without a terminal assertion method creates an assertion object but never checks it, causing the test to silently pass regardless of the actual value. This is a common mistake when refactoring or writing assertions from scratch."
+  aliases:
+    - JAVA-E1109
+  tags:
+    - correctness
+    - java
+    - testing
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+match:
+  fact:
+    kind: java.correctness.unterminated-assertion-chain
+    bind: issue
+emit:
+  finding:
+    category: correctness.bug-risk
+    severity: high
+    confidence: 0.90
+    tags:
+      - correctness
+      - java
+  message:
+    title: "Unterminated assertion chain in `${captures.issue.text}`"
+    summary: "The call to `assertThat()` or `verify()` is not followed by a terminal assertion method. The assertion is initialized but never checked. Add a terminal assertion like `.isEqualTo(expected)` or `.isTrue()` to complete the chain."
+  remediation:
+    summary: "Terminate the assertion chain with a check method. For AssertJ: use `.isEqualTo()`, `.isGreaterThan()`, or any terminal assertion method. For Mockito: chain `.someMethod()` to specify what behavior to verify."