@critiq/rules 0.3.0 → 0.4.0

package/rules/java/java.performance.explicit-gc.rule.yaml

@@ -0,0 +1,43 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.performance.explicit-gc
+  title: "Explicit invocation of garbage collection is detrimental"
+  summary: "Explicit calls to `System.gc()` or `Runtime.getRuntime().gc()` trigger full GC cycles that degrade performance."
+  rationale: "Explicit garbage collection calls force a stop-the-world full GC cycle, which is detrimental to application performance outside of specific benchmarking or diagnostic scenarios. The JVM is better equipped to decide when GC should run. Remove explicit GC calls to let the JVM manage memory efficiently."
+  aliases:
+    - JAVA-P0065
+  tags:
+    - performance
+    - java
+    - allocation
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.performance.explicit-gc
+    bind: issue
+emit:
+  finding:
+    category: performance.allocation
+    severity: high
+    confidence: 0.95
+    tags:
+      - performance
+      - java
+  message:
+    title: "Explicit GC call in `${captures.issue.text}` is detrimental"
+    summary: "`${captures.issue.text}` triggers a full stop-the-world garbage collection cycle. Remove this call and let the JVM manage memory."
+  remediation:
+    summary: "Remove the explicit `System.gc()` or `Runtime.getRuntime().gc()` call."

package/rules/java/java.performance.inefficient-string-constructor.rule.yaml

@@ -0,0 +1,44 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.performance.inefficient-string-constructor
+  title: "Inefficient use of String constructor"
+  summary: "`new String(String)` creates an unnecessary copy; use the string literal directly."
+  rationale: "The `String(String)` constructor creates a copy of the argument string, which is almost never needed. String literals are interned and can be used directly. Using `new String(\"literal\")` allocates an unnecessary object and should be replaced with the literal itself."
+  aliases:
+    - JAVA-P0062
+    - JAVA-S0062
+  tags:
+    - performance
+    - java
+    - allocation
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.performance.inefficient-string-constructor
+    bind: issue
+emit:
+  finding:
+    category: performance.allocation
+    severity: high
+    confidence: 0.90
+    tags:
+      - performance
+      - java
+  message:
+    title: "Unnecessary String copy in `${captures.issue.text}`"
+    summary: "`${captures.issue.text}` creates an unnecessary copy of a string literal. Use the literal directly."
+  remediation:
+    summary: "Replace `new String(\"...\")` with the string literal `\"...\"` directly."

package/rules/java/java.performance.keyset-instead-of-entryset.rule.yaml

@@ -0,0 +1,49 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.performance.keyset-instead-of-entryset
+  title: "Inefficient Map iteration with keySet() and get()"
+  summary: "Iterating over `Map.keySet()` and calling `Map.get(key)` for each key performs redundant hash lookups."
+  rationale: "Using `keySet()` + `get()` iterates the map keys and performs a separate hash lookup for each element. This is O(2n) instead of O(n). Use `entrySet()` to access both key and value directly without the extra lookup."
+  detection:
+    kind: pattern
+  references:
+    - kind: cwe
+      id: CWE-400
+      title: Uncontrolled Resource Consumption
+  aliases:
+    - JAVA-P0361
+  tags:
+    - performance
+    - java
+    - collections
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.performance.keyset-instead-of-entryset
+    bind: issue
+emit:
+  finding:
+    category: performance.collections
+    severity: high
+    confidence: 0.80
+    tags:
+      - performance
+      - java
+  message:
+    title: "Use `entrySet()` instead of `keySet()` + `get()` in `${captures.issue.text}`"
+    summary: "`${captures.issue.text}` iterates keySet() and calls get() for each key. Use entrySet() to avoid redundant hash lookups."
+  remediation:
+    summary: "Replace the iteration with `for (Map.Entry<K, V> entry : map.entrySet())` and access both key and value via `entry.getKey()` and `entry.getValue()`."

package/rules/java/java.performance.non-zero-to-array.rule.yaml

@@ -0,0 +1,49 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.performance.non-zero-to-array
+  title: "Collection.toArray() with non-zero sized array argument"
+  summary: "Passing a non-zero sized array to `Collection.toArray(T[])` is less efficient than passing a zero-sized array."
+  rationale: "Passing a pre-sized array to `toArray()` incurs an unnecessary allocation and reflection overhead. In modern JVMs, `toArray(new T[0])` is faster because it avoids the need to resize the array and can use intrinsified code paths."
+  detection:
+    kind: pattern
+  references:
+    - kind: cwe
+      id: CWE-400
+      title: Uncontrolled Resource Consumption
+  aliases:
+    - JAVA-P0335
+  tags:
+    - performance
+    - java
+    - allocation
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.performance.non-zero-to-array
+    bind: issue
+emit:
+  finding:
+    category: performance.allocation
+    severity: high
+    confidence: 0.93
+    tags:
+      - performance
+      - java
+  message:
+    title: "Use `toArray(new T[0])` instead of pre-sized array in `${captures.issue.text}`"
+    summary: "`${captures.issue.text}` passes a non-zero sized array to toArray(). Use `toArray(new T[0])` for better performance."
+  remediation:
+    summary: "Replace the array argument with `new T[0]` where T is the element type to let the JVM allocate the correctly-sized array."

package/rules/java/java.performance.pattern-compile-in-loop.rule.yaml

@@ -0,0 +1,49 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.performance.pattern-compile-in-loop
+  title: "Pattern.compile() inside a loop"
+  summary: "Calling `Pattern.compile()` inside a loop causes repeated regex compilation, leading to performance degradation."
+  rationale: "Regex compilation is expensive. `Pattern.compile()` should be moved outside loops and reused with `matcher()` to avoid recompiling the same pattern on every iteration."
+  detection:
+    kind: pattern
+  references:
+    - kind: cwe
+      id: CWE-400
+      title: Uncontrolled Resource Consumption
+  aliases:
+    - JAVA-P0331
+  tags:
+    - performance
+    - java
+    - allocation
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.performance.pattern-compile-in-loop
+    bind: issue
+emit:
+  finding:
+    category: performance.allocation
+    severity: critical
+    confidence: 0.92
+    tags:
+      - performance
+      - java
+  message:
+    title: "Move `Pattern.compile()` outside the loop in `${captures.issue.text}`"
+    summary: "`${captures.issue.text}` calls Pattern.compile() inside a loop. Hoist it before the loop to avoid repeated regex compilation."
+  remediation:
+    summary: "Move `Pattern.compile()` before the loop and call `matcher()` inside with the loop variable."

package/rules/java/java.performance.removeall-to-clear.rule.yaml

@@ -0,0 +1,49 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.performance.removeall-to-clear
+  title: "removeAll should not be used to clear a collection"
+  summary: "Calling `collection.removeAll(collection)` is equivalent to `collection.clear()` but performs unnecessary iteration and element comparisons."
+  rationale: "`removeAll(collection)` on a collection with itself as the argument removes all elements that are contained in itself — effectively clearing the collection. However, this is O(n²) or worse depending on collection type, while `clear()` is O(1). Replace `collection.removeAll(collection)` with `collection.clear()`."
+  detection:
+    kind: pattern
+  references:
+    - kind: cwe
+      id: CWE-1079
+      title: Inefficient Algorithm
+  aliases:
+    - JAVA-P1005
+  tags:
+    - performance
+    - java
+    - collections
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.performance.removeall-to-clear
+    bind: issue
+emit:
+  finding:
+    category: performance.collections
+    severity: critical
+    confidence: 0.85
+    tags:
+      - performance
+      - java
+  message:
+    title: "Use `clear()` instead of `removeAll(self)` in `${captures.issue.text}`"
+    summary: "`removeAll(collection)` with the collection itself as argument performs an O(n²) self-removal when `clear()` is O(1)."
+  remediation:
+    summary: "Replace `collection.removeAll(collection)` with `collection.clear()`."

package/rules/java/java.performance.replaceall-instead-of-replace.rule.yaml

@@ -0,0 +1,49 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.performance.replaceall-instead-of-replace
+  title: "String.replaceAll() with literal string argument"
+  summary: "Using `String.replaceAll()` with a literal (non-regex) string argument is less efficient than `String.replace()`."
+  rationale: "`replaceAll()` interprets its first argument as a regex pattern, incurring unnecessary compilation overhead even when the argument contains no special regex characters. `String.replace()` treats the first argument as a literal character sequence and has optimized intrinsic implementations."
+  detection:
+    kind: pattern
+  references:
+    - kind: cwe
+      id: CWE-400
+      title: Uncontrolled Resource Consumption
+  aliases:
+    - JAVA-P1001
+  tags:
+    - performance
+    - java
+    - strings
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.performance.replaceall-instead-of-replace
+    bind: issue
+emit:
+  finding:
+    category: performance.strings
+    severity: high
+    confidence: 0.90
+    tags:
+      - performance
+      - java
+  message:
+    title: "Use `String.replace()` instead of `replaceAll()` for literal strings in `${captures.issue.text}`"
+    summary: "`${captures.issue.text}` uses replaceAll() with a non-regex argument. Use replace() for literal string replacement."
+  remediation:
+    summary: "Replace `replaceAll(literal, replacement)` with `replace(literal, replacement)` to avoid unnecessary regex compilation."

package/rules/java/java.performance.single-char-string-indexof.rule.yaml

@@ -0,0 +1,49 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.performance.single-char-string-indexof
+  title: "Single-character string literal in indexOf/lastIndexOf/contains"
+  summary: "Using a single-character `String` literal in `indexOf()`, `lastIndexOf()`, or `contains()` is less efficient than using a `char` literal."
+  rationale: "When searching for a single character, using the char overload (e.g., `s.indexOf('.')`) avoids creating a temporary String object and can use optimized intrinsic implementations. The String overload creates unnecessary garbage and performs worse."
+  detection:
+    kind: pattern
+  references:
+    - kind: cwe
+      id: CWE-400
+      title: Uncontrolled Resource Consumption
+  aliases:
+    - JAVA-P1004
+  tags:
+    - performance
+    - java
+    - strings
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.performance.single-char-string-indexof
+    bind: issue
+emit:
+  finding:
+    category: performance.strings
+    severity: high
+    confidence: 0.92
+    tags:
+      - performance
+      - java
+  message:
+    title: "Use char literal instead of single-character String in `${captures.issue.text}`"
+    summary: "`${captures.issue.text}` uses a single-character string literal. Use a char literal (single quotes) for better performance."
+  remediation:
+    summary: "Replace the single-character string literal with a char literal (e.g., replace `\".\"` with `'.'`)."

package/rules/java/java.performance.string-concat-in-loop.rule.yaml

@@ -0,0 +1,49 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.performance.string-concat-in-loop
+  title: "String concatenation using `+` inside a loop"
+  summary: "String concatenation using `+=` or `= ... + ...` inside a loop creates many intermediate String objects, degrading performance."
+  rationale: "In Java, String is immutable. Each `+=` or `+` concatenation creates a new String object, copying the previous content. Inside a loop, this results in O(n²) memory allocation and copying. Use `StringBuilder.append()` instead, which grows the buffer efficiently. Note: Java 9+ invokes dynamic string concatenation via `invokedynamic`, reducing object allocation, but the pattern remains suboptimal for many iterations."
+  detection:
+    kind: pattern
+  references:
+    - kind: cwe
+      id: CWE-400
+      title: Uncontrolled Resource Consumption
+  aliases:
+    - JAVA-P1006
+  tags:
+    - performance
+    - java
+    - strings
+    - rules-catalog
+  stability: stable
+  appliesTo: function
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.performance.string-concat-in-loop
+    bind: issue
+emit:
+  finding:
+    category: performance.strings
+    severity: high
+    confidence: 0.75
+    tags:
+      - performance
+      - java
+  message:
+    title: "Use `StringBuilder.append()` instead of `+` concatenation inside loop in `${captures.issue.text}`"
+    summary: "String concatenation with `+` or `+=` inside a loop creates O(n²) temporary String objects."
+  remediation:
+    summary: "Declare a `StringBuilder` before the loop and use `append()` inside the loop body."

package/rules/java/java.performance.string-to-string.rule.yaml

@@ -0,0 +1,43 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.performance.string-to-string
+  title: "toString invoked on a string value is useless"
+  summary: "Calling `toString()` on a string literal or string variable creates an unnecessary identity copy."
+  rationale: "Invoking `toString()` on a `String` value is a no-op — it simply returns `this`. The call is unnecessary and may indicate confusion about the runtime type of a value. Remove the `.toString()` call to clarify intent and avoid misleading readers."
+  aliases:
+    - JAVA-P0064
+  tags:
+    - performance
+    - java
+    - allocation
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.performance.string-to-string
+    bind: issue
+emit:
+  finding:
+    category: performance.allocation
+    severity: high
+    confidence: 0.88
+    tags:
+      - performance
+      - java
+  message:
+    title: "Unnecessary `.toString()` call on string value in `${captures.issue.text}`"
+    summary: "`${captures.issue.text}` invokes `toString()` on a value that is already a String. This call is a no-op and should be removed."
+  remediation:
+    summary: "Remove the `.toString()` call — the value is already a String."

package/rules/java/java.performance.thread-as-runnable.rule.yaml

@@ -0,0 +1,44 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.performance.thread-as-runnable
+  title: "Thread passed where Runnable expected"
+  summary: "Passing `new Thread(runnable)` to an executor or scheduler creates unnecessary Thread objects."
+  rationale: "ExecutorService, ScheduledExecutorService, and similar APIs accept Runnable directly. Wrapping a Runnable in a new Thread() adds object allocation overhead and bypasses the executor's thread pool management. Pass the Runnable directly instead."
+  aliases:
+    - JAVA-E0056
+    - JAVA-S0056
+  tags:
+    - performance
+    - java
+    - concurrency
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.performance.thread-as-runnable
+    bind: issue
+emit:
+  finding:
+    category: performance.concurrency
+    severity: high
+    confidence: 0.72
+    tags:
+      - performance
+      - java
+  message:
+    title: "Pass Runnable directly to `${captures.issue.text}` instead of wrapping in new Thread()"
+    summary: "`${captures.issue.text}` creates an unnecessary Thread object. Executor services already manage pooled threads; pass the Runnable directly."
+  remediation:
+    summary: "Replace `executor.submit(new Thread(task))` with `executor.submit(task)` and similar patterns."

package/rules/java/java.performance.url-in-collection.rule.yaml

@@ -0,0 +1,44 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.performance.url-in-collection
+  title: "Maps and Sets of URLs can be performance hogs"
+  summary: "`java.net.URL` performs DNS resolution on `equals()` and `hashCode()`, making Map and Set operations unexpectedly expensive."
+  rationale: "The `URL` class resolves the hostname to an IP address during `equals()` and `hashCode()` calls (CWE-400). This means every Map lookup, insertion, or Set membership test involving URLs performs a potentially blocking network call. Use `URI` or `String` instead of `URL` as collection key types to avoid DNS resolution overhead."
+  aliases:
+    - JAVA-P0057
+    - JAVA-S0057
+  tags:
+    - performance
+    - java
+    - allocation
+    - rules-catalog
+  stability: stable
+  appliesTo: file
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+    exclude:
+      - "**/src/test/**"
+      - "**/tests/**"
+      - "**/*Test.java"
+match:
+  fact:
+    kind: java.performance.url-in-collection
+    bind: issue
+emit:
+  finding:
+    category: performance.allocation
+    severity: critical
+    confidence: 0.95
+    tags:
+      - performance
+      - java
+  message:
+    title: "Use `URI` or `String` instead of `URL` as Map/Set key type in `${captures.issue.text}`"
+    summary: "`${captures.issue.text}` uses URL as a key type. URL.equals() performs DNS resolution, causing severe performance degradation in collections."
+  remediation:
+    summary: "Replace `URL` with `URI` or `String` in Map and Set type parameters to avoid DNS resolution on equals() and hashCode()."

package/rules/java/java.quality.c-style-array-declaration.rule.yaml

@@ -0,0 +1,41 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.quality.c-style-array-declaration
+  title: C-style array declaration must not be used
+  summary: Array brackets should be placed with the type, not the variable name.
+  rationale: Java-style `int[] arr` is clearer, consistent with the language convention, and avoids confusion between `int[] arr, values` (two arrays) and `int arr[], values` (one array, one int).
+  detection:
+    kind: pattern
+  aliases:
+    - JAVA-C1000
+  tags:
+    - quality
+    - java
+    - code-style
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+match:
+  fact:
+    kind: java.quality.c-style-array-declaration
+    bind: issue
+emit:
+  finding:
+    category: quality.code-style
+    severity: low
+    confidence: 0.85
+    tags:
+      - quality
+      - java
+  message:
+    title: Use Java-style array declaration
+    summary: "`${captures.issue.text}` places brackets after the variable name. Use `Type[] name` instead."
+  remediation:
+    summary: Move the brackets to follow the type (e.g., `int[] arr` instead of `int arr[]`).

package/rules/java/java.quality.multiple-variables-same-line.rule.yaml

@@ -0,0 +1,41 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: java.quality.multiple-variables-same-line
+  title: Multiple variables must not be declared on the same line
+  summary: Declaring multiple variables on one line reduces readability and can hide initialization bugs.
+  rationale: One declaration per line makes the code easier to read, review, and refactor. It also avoids confusion between array and scalar declarations.
+  detection:
+    kind: pattern
+  aliases:
+    - JAVA-C1003
+  tags:
+    - quality
+    - java
+    - code-style
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - java
+  paths:
+    include:
+      - "**/*.java"
+match:
+  fact:
+    kind: java.quality.multiple-variables-same-line
+    bind: issue
+emit:
+  finding:
+    category: quality.code-style
+    severity: low
+    confidence: 0.90
+    tags:
+      - quality
+      - java
+  message:
+    title: Declare variables on separate lines
+    summary: "`${captures.issue.text}` declares multiple variables on the same line."
+  remediation:
+    summary: Split into separate declarations (e.g., `int a;\nint b = 5;` instead of `int a, b = 5;`).