@critiq/rules 0.3.0 → 0.4.0

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

@@ -0,0 +1,42 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.double-assignment
+  title: Double assignment of variable detected
+  summary: A local variable is assigned twice consecutively without being read between the assignments.
+  rationale: The first assignment value is overwritten before being used, indicating dead code or a logic error.
+  tags:
+    - correctness
+    - java
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+  aliases:
+    - JAVA-E1063
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.double-assignment
+    bind: issue
+emit:
+  finding:
+    category: correctness.general
+    severity: high
+    confidence: 0.60
+    tags:
+      - correctness
+      - java
+  message:
+    title: Double assignment without intervening read
+    summary: The first assigned value is never read before being overwritten, indicating dead code or a logic error.
+  remediation:
+    summary: Remove the first assignment if unused, or verify the intended logic is correct.

package/rules/java/java.correctness.double-checked-locking.rule.yaml

@@ -0,0 +1,42 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.double-checked-locking
+  title: Double-checked locking without volatile field
+  summary: A double-checked locking pattern on a non-volatile field is unsafe.
+  rationale: Without volatile, the JVM may reorder writes so that a thread sees a partially constructed object.
+  tags:
+    - correctness
+    - java
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+  aliases:
+    - JAVA-E1018
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.double-checked-locking
+    bind: issue
+emit:
+  finding:
+    category: correctness.concurrency
+    severity: high
+    confidence: 0.7
+    tags:
+      - correctness
+      - java
+  message:
+    title: Double-checked locking on non-volatile field
+    summary: The double-checked locking pattern is used on a field that is not declared volatile, which is unsafe under the Java memory model.
+  remediation:
+    summary: Declare the field as volatile, or use an inner static holder class for lazy initialization.

package/rules/java/java.correctness.duplicate-binary-argument.rule.yaml

@@ -0,0 +1,45 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.duplicate-binary-argument
+  title: Duplicate arguments in binary expression
+  summary: Same expression appears on both sides of a binary operator — likely a copy-paste bug.
+  rationale: When both sides of a `||` or `&&` are identical, one branch is dead or the condition is incorrect.
+  detection:
+    kind: pattern
+  aliases:
+    - JAVA-E0034
+  tags:
+    - correctness
+    - java
+    - logic-error
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.duplicate-binary-argument
+    bind: issue
+emit:
+  finding:
+    category: correctness.logic-error
+    severity: medium
+    confidence: 0.75
+    tags:
+      - correctness
+      - java
+  message:
+    title: Duplicate binary expression argument
+    summary: "`${captures.issue.text}` repeats the same expression on both sides of a binary operator — likely a copy-paste bug."
+  remediation:
+    summary: Review the condition — likely a copy-paste error where the second operand should be different.

package/rules/java/java.correctness.duration-with-nanos-misuse.rule.yaml

@@ -0,0 +1,42 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.duration-with-nanos-misuse
+  title: "Use `Duration.withNanos()` with caution"
+  summary: "Calling `Duration.withNanos()` may produce unexpected results because it only sets the nanos-of-second component, not the total duration."
+  rationale: "`Duration.withNanos(long nanos)` sets only the fractional second portion (0-999999999). Developers often expect it to set the total duration, but it does not change the seconds component. Use `Duration.ofNanos()`, `Duration.ofMillis()`, or `Duration.ofSeconds()` to create a duration with the intended total length."
+  aliases:
+    - JAVA-E1087
+  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.duration-with-nanos-misuse
+    bind: issue
+emit:
+  finding:
+    category: correctness.api-misuse
+    severity: high
+    confidence: 0.88
+    tags:
+      - correctness
+      - java
+  message:
+    title: "`Duration.withNanos()` may not behave as expected in `${captures.issue.text}`"
+    summary: "`Duration.withNanos()` sets only the fractional second portion, not the total nanoseconds. The seconds component of the duration is unchanged."
+  remediation:
+    summary: "Use `Duration.ofNanos()`, `Duration.ofMillis()`, or `Duration.ofSeconds()` to create a duration with the intended total length."

package/rules/java/java.correctness.enum-equals-method.rule.yaml

@@ -0,0 +1,45 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.enum-equals-method
+  title: equals method defined for enumeration
+  summary: "An enum should not define an `equals()` method — enum equality is determined by identity."
+  rationale: The JVM guarantees that each enum constant is a singleton. Defining `equals()` in an enum is unnecessary and can break the contract if not implemented carefully.
+  detection:
+    kind: pattern
+  aliases:
+    - JAVA-E0096
+  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.enum-equals-method
+    bind: issue
+emit:
+  finding:
+    category: correctness.types
+    severity: high
+    confidence: 0.90
+    tags:
+      - correctness
+      - java
+  message:
+    title: equals() defined in enum
+    summary: "The enum defines an `equals()` method. Enum constants are singletons — `equals()` is inherited from Object and should not be overridden."
+  remediation:
+    summary: "Remove the `equals()` method from the enum. Enum identity is sufficient."

package/rules/java/java.correctness.enum-get-class.rule.yaml

@@ -0,0 +1,42 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.enum-get-class
+  title: getClass should not be used with enums whose members have custom bodies
+  summary: Calling getClass() inside an enum body returns the anonymous subclass for constants with custom bodies, not the enum class itself. Prefer getDeclaringClass().
+  rationale: When an enum constant has a custom body, getClass() returns the anonymous subclass rather than the enum class. The safe alternative getDeclaringClass() always returns the enum class regardless of custom bodies.
+  tags:
+    - correctness
+    - java
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+  aliases:
+    - JAVA-E1106
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.enum-get-class
+    bind: issue
+emit:
+  finding:
+    category: correctness.general
+    severity: medium
+    confidence: 0.75
+    tags:
+      - correctness
+      - java
+  message:
+    title: getClass() called inside enum body
+    summary: Calling getClass() inside an enum body can return unexpected results. Use getDeclaringClass() to reliably get the enum class.
+  remediation:
+    summary: Replace getClass() with getDeclaringClass() to always obtain the correct enum class regardless of custom constant bodies.

package/rules/java/java.correctness.equals-inherits-parent.rule.yaml

@@ -0,0 +1,45 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.equals-inherits-parent
+  title: equals method inherits parent without overriding
+  summary: A class defines an overloaded `equals` but does not override `equals(Object)`, so the parent's equals semantics are silently inherited.
+  rationale: When a subclass adds an `equals(SubType)` overload without overriding `equals(Object)`, collections and utility methods will use the parent's equals logic (often identity), which may differ from the subclass's intended comparison behavior.
+  detection:
+    kind: pattern
+  aliases:
+    - JAVA-E0099
+  tags:
+    - correctness
+    - java
+    - types
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.equals-inherits-parent
+    bind: issue
+emit:
+  finding:
+    category: correctness.types
+    severity: medium
+    confidence: 0.85
+    tags:
+      - correctness
+      - java
+  message:
+    title: Equals is overloaded, not overridden — inherits parent behavior
+    summary: "`${captures.issue.text}` overloads equals without overriding `equals(Object)`. The parent's equals implementation will be used."
+  remediation:
+    summary: "Add an `@Override public boolean equals(Object obj)` method to properly override equals."

package/rules/java/java.correctness.equals-null-check.rule.yaml

@@ -0,0 +1,45 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.equals-null-check
+  title: equals method without null check
+  summary: "An `equals(Object)` implementation accesses fields or methods without a preceding null guard, risking NullPointerException."
+  rationale: "If the argument to equals is null, accessing its fields or calling methods on it will throw a NullPointerException. Always start equals with `if (o == null) return false;` or a null-safe pattern."
+  detection:
+    kind: pattern
+  aliases:
+    - JAVA-E0110
+  tags:
+    - correctness
+    - java
+    - null-safety
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.equals-null-check
+    bind: issue
+emit:
+  finding:
+    category: correctness.null-safety
+    severity: high
+    confidence: 0.90
+    tags:
+      - correctness
+      - java
+  message:
+    title: equals() without null check
+    summary: "`${captures.issue.text}` does not guard against null before accessing members. Add a null check."
+  remediation:
+    summary: "Add `if (o == null) return false;` at the start of equals, or use `Objects.equals()` for field comparisons."

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

@@ -0,0 +1,45 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.equals-null
+  title: Avoid using equals() to compare against null
+  summary: "Calling `.equals(null)` always returns false and may throw NullPointerException."
+  rationale: "If the receiver is null, a NullPointerException is thrown. Use `== null` for null checks."
+  detection:
+    kind: pattern
+  aliases:
+    - JAVA-E0051
+  tags:
+    - correctness
+    - java
+    - null-safety
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.equals-null
+    bind: issue
+emit:
+  finding:
+    category: correctness.null-safety
+    severity: high
+    confidence: 0.90
+    tags:
+      - correctness
+      - java
+  message:
+    title: equals() compared against null
+    summary: "Calling `.equals(null)` is dangerous — use `== null` instead."
+  remediation:
+    summary: "Use `variable == null` instead of `variable.equals(null)`."

package/rules/java/java.correctness.equals-on-array.rule.yaml

@@ -5,6 +5,10 @@ metadata:
   title: Compare arrays with Arrays.equals
   summary: Array.equals compares references, not contents.
   rationale: Reference equality on arrays is almost always a logic bug.
+  aliases:
+    - JAVA-S0348
+    - JAVA-S0349
+    - JAVA-E0348
   tags:
     - correctness
     - java

package/rules/java/java.correctness.explicit-finalizer-invocation.rule.yaml

@@ -0,0 +1,45 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.explicit-finalizer-invocation
+  title: Finalizers must not be explicitly invoked
+  summary: "Calling `.finalize()` explicitly is dangerous and deprecated."
+  rationale: Explicit finalizer invocation can resurrect objects, cause resource leaks, and produce unpredictable behavior. The JVM manages finalization automatically.
+  detection:
+    kind: pattern
+  aliases:
+    - JAVA-E0094
+  tags:
+    - correctness
+    - java
+    - resource-management
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.explicit-finalizer-invocation
+    bind: issue
+emit:
+  finding:
+    category: correctness.resource-management
+    severity: high
+    confidence: 0.90
+    tags:
+      - correctness
+      - java
+  message:
+    title: Explicit finalizer invocation
+    summary: "`${captures.issue.text}` is an explicit call to finalize(). The JVM manages finalization — never call it directly."
+  remediation:
+    summary: "Remove the explicit `.finalize()` call. Implement `AutoCloseable` and use try-with-resources instead."

package/rules/java/java.correctness.for-loop-mismatched-increment.rule.yaml

@@ -0,0 +1,45 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.for-loop-mismatched-increment
+  title: For loop checks one variable but increments another
+  summary: The loop condition checks one variable but a different variable is being incremented.
+  rationale: "A for-loop that checks variable `i` in its condition but increments variable `j` is likely a bug. The loop may never terminate or may terminate early."
+  detection:
+    kind: pattern
+  aliases:
+    - JAVA-E0214
+  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.for-loop-mismatched-increment
+    bind: issue
+emit:
+  finding:
+    category: correctness.logic
+    severity: medium
+    confidence: 0.90
+    tags:
+      - correctness
+      - java
+  message:
+    title: For-loop increment variable does not match condition variable
+    summary: "`${captures.issue.text}` — the condition uses one variable but the increment changes a different variable."
+  remediation:
+    summary: Ensure the loop increment updates the same variable used in the condition.

package/rules/java/java.correctness.getter-setter-sync-mismatch.rule.yaml

@@ -0,0 +1,42 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.getter-setter-sync-mismatch
+  title: Getter and setter method synchronization does not match
+  summary: One of a getter/setter pair is synchronized and the other is not.
+  rationale: When one accessor is synchronized and the other is not, concurrent access is not properly guarded, leading to potential data races and visibility issues.
+  aliases:
+    - JAVA-E1074
+  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.getter-setter-sync-mismatch
+    bind: issue
+emit:
+  finding:
+    category: correctness.concurrency
+    severity: high
+    confidence: 0.88
+    tags:
+      - correctness
+      - java
+  message:
+    title: Sync mismatch for getter/setter pair `${captures.issue.text}`
+    summary: "One accessor is synchronized but the other is not."
+  remediation:
+    summary: Either synchronize both the getter and setter, or use volatile or atomic fields for safe concurrent access.

package/rules/java/java.correctness.hashcode-on-array.rule.yaml

@@ -0,0 +1,42 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.hashcode-on-array
+  title: hashCode() called on an array
+  summary: Calling hashCode() directly on an array uses Object's identity-based hashCode rather than a content-based hash code.
+  rationale: Arrays inherit Object.hashCode(), which returns the identity hash code, not a hash derived from array contents. This means two arrays with identical elements will have different hash codes. Use Arrays.hashCode() instead.
+  tags:
+    - correctness
+    - java
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+  aliases:
+    - JAVA-E1044
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.hashcode-on-array
+    bind: issue
+emit:
+  finding:
+    category: correctness.equality
+    severity: high
+    confidence: 0.95
+    tags:
+      - correctness
+      - java
+  message:
+    title: hashCode() called on array
+    summary: "`${captures.issue.text}` calls hashCode() directly on an array, using identity-based hash instead of content-based hash."
+  remediation:
+    summary: Use `Arrays.hashCode(array)` instead of `array.hashCode()`.

package/rules/java/java.correctness.hashtable-contains-value.rule.yaml

@@ -0,0 +1,42 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.hashtable-contains-value
+  title: "Hashtable/ConcurrentHashMap.contains() checks for values, not keys"
+  summary: "`.contains()` on `Hashtable` and `ConcurrentHashMap` checks for value existence. Use `.containsKey()` to check for key existence."
+  rationale: "In `Hashtable` and `ConcurrentHashMap`, `.contains(Object)` checks whether a **value** exists in the map, not a key. This differs from `Map.containsKey()` which checks for keys. Developers migrating from `Map` or from other collection types may mistakenly use `.contains()` thinking it checks keys. Use `.containsKey()` for key lookup and `.containsValue()` for value lookup."
+  aliases:
+    - JAVA-E1098
+  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.hashtable-contains-value
+    bind: issue
+emit:
+  finding:
+    category: correctness.api-misuse
+    severity: critical
+    confidence: 0.60
+    tags:
+      - correctness
+      - java
+  message:
+    title: "Hashtable/ConcurrentHashMap.contains() checks value existence, not keys in `${captures.issue.text}`"
+    summary: "`.contains()` on Hashtable/ConcurrentHashMap checks value existence. Use `.containsKey()` to check for key existence."
+  remediation:
+    summary: "Replace `.contains(key)` with `.containsKey(key)` to check for key existence, or use `.containsValue(value)` explicitly for value lookup."

package/rules/java/java.correctness.hasnext-invokes-next.rule.yaml

@@ -0,0 +1,45 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.correctness.hasnext-invokes-next
+  title: Iterator hasNext should not invoke next
+  summary: Calling .next() inside a hasNext() implementation mutates iterator state during a query operation.
+  rationale: hasNext() is a query method and should not advance the iterator. Calling next() inside it skips elements and breaks iteration contracts.
+  detection:
+    kind: pattern
+  aliases:
+    - JAVA-E0409
+  tags:
+    - correctness
+    - java
+    - collections
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.correctness.hasnext-invokes-next
+    bind: issue
+emit:
+  finding:
+    category: correctness.logic
+    severity: high
+    confidence: 0.70
+    tags:
+      - correctness
+      - java
+  message:
+    title: hasNext() should not call next()
+    summary: Calling .next() inside hasNext() advances the iterator during a query, which breaks the iteration contract.
+  remediation:
+    summary: Remove the .next() call from hasNext(). Use a peek/check method or restructure the iterator to track state without consuming elements.