[build] Add java:local_dev rake task for IntelliJ IDEA project setup

[titusfortner]

🔗 Related Issues

Closes #17765

💥 What does this PR do?

Adds a java:local_dev rake task (alongside rb:local_dev / py:local_dev) that copies the Bazel-built dependency jars the IntelliJ modules compile against into ./java-libs, so the repo can be developed with standard Java tooling — running, debugging, profiling, running individual tests — without the Bazel plugin.

It also updates the checked-in IntelliJ project so the repo opens and compiles cleanly out of the box: a java-libs project library, and a split of the Java module into java (released code, Java 11) and java-dev (tests + src/dev tooling, Java 17), with the project SDK set to JDK 25. These files are read only by IntelliJ, so they don't affect Bazel-plugin users or other editors.

🔧 Implementation Notes

• java-libs is scoped to the modules' resolved compile+runtime classpath — via cquery over JavaInfo.transitive_runtime_jars plus the in-tree java_binary tools' runtime_classpath — not the full pinned set. Unused transitives (e.g. javacc's test-only junit-4) are excluded by construction rather than by a name list.
• Generated CDP classes are copied as v<NN>-libcdp.jar and picked up by the library's directory scan, so version bumps need no maintenance. This replaces the hand-updated .idea/libraries/libcdp.xml (removed here), which had drifted to stale versions.
• The Bazel runfiles jar comes from the built external/ tree, so there's no dependency on the IntelliJ Bazel plugin.
• The library points at the java-libs directory, so it stays empty and inert until the task is run — an accidental check-in of the wiring can't break anyone's setup.
• The module split keeps released code in a Java 11 module so the IDE flags Java 17 usage that would break the release; tests and src/dev (compiled at --release 17) live in a Java 17 module. The project SDK is JDK 25 to match remotejdk_25 (required by ErrorProne). Bazel stays the source of truth for the actual --release targets.

🤖 AI assistance

• AI assisted (complete below)
  • Tool(s): Claude Code
  • What was generated: the rake task and IntelliJ project wiring, ported and reworked from the shell script in Selenium java project in IDEA #17765
  • I reviewed all AI output and can explain the change

💡 Additional Considerations

No automated test: this is a dev-tooling rake task that shells out to a live Bazel build, matching rb:local_dev / py:local_dev (also untested). Verified by reproducing the IDE's symbol resolution — every import in java/src + java/test resolves against the generated java-libs (0 unresolved).

🔄 Types of changes

• New feature (build/dev tooling; no automated test — see note above)

[qodo-code-review]

PR Summary by Qodo

Add java:local_dev rake task and IntelliJ wiring for non-Bazel Java IDE setup

✨ Enhancement ⚙️ Configuration changes 🕐 20-40 Minutes

AI Description

• Add java:local_dev rake task to materialize Bazel Java test dependency jars into ./java-libs.
• Check in IntelliJ library + module order entry to resolve java-libs jars automatically.
• Filter copied jars to match java_test deps and avoid redundant JUnit runtime jars.

Diagram

graph TD
  A["Developer"] --> B["rake java:local_dev"] --> C["Bazel build //java/test/..."] --> D["Bazel cquery deps(java_test)"] --> E["Copy jars from execroot"] --> F[("java-libs/")] --> G["IntelliJ project library"] --> H["Java module classpath"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Generate IntelliJ files instead of checking them in

• ➕ Avoids committing .idea/.iml wiring into the repo
• ➕ Allows per-user customization without churn
• ➖ Requires additional onboarding steps and documentation
• ➖ More moving parts (generator + versioning) for relatively simple wiring

2. Derive jars from IntelliJ Bazel plugin outputs (`.ijwb`)

• ➕ Leverages existing Bazel-IDE integration artifacts
• ➕ Potentially closer to what IDEA resolves under the plugin
• ➖ Couples local-dev workflow to the plugin being installed and producing outputs
• ➖ Harder to make deterministic and editor-agnostic

3. Use Bazel `aquery`/`--output_groups` to copy artifacts

• ➕ Can target specific output groups more explicitly than path filtering
• ➕ May reduce reliance on Starlark string filtering rules
• ➖ More Bazel-specific complexity and harder to keep stable across Bazel versions
• ➖ Often requires deeper knowledge of action graphs and output groups

Recommendation: Current approach is a good tradeoff: it’s editor-agnostic, deterministic (Bazel cquery over java_test deps), and keeps IntelliJ wiring inert until java-libs/ is populated. If .idea churn becomes a concern, revisit generating IDEA wiring on demand, but it’s likely not worth the overhead right now.

Files changed (3) +51 / -0

Enhancement (1) +39 / -0

java.rakeAdd 'java:local_dev' task to copy Bazel dependency jars into 'java-libs/' +39/-0

Add 'java:local_dev' task to copy Bazel dependency jars into 'java-libs/'

• Adds a Starlark expression used by 'bazel cquery' to enumerate jar files needed by 'java_test' dependencies while excluding JUnit runtime jars and retaining 'librunfiles.jar'. Implements 'java:local_dev' to build '//java/test/...', compute the Bazel execution root, query dependency jars, and copy binaries/sources into 'java-libs/' and 'java-libs/sources'.

rake_tasks/java.rake

Other (2) +12 / -0

java-libs.xmlAdd IntelliJ project library pointing at 'java-libs/' +11/-0

Add IntelliJ project library pointing at 'java-libs/'

• Introduces a 'java-libs' project library that resolves jars from './java-libs' and source jars from './java-libs/sources'. This enables IntelliJ to pick up locally-copied Bazel dependency jars without requiring the Bazel plugin.

.idea/libraries/java-libs.xml

java.imlWire 'java-libs' library into the Java module classpath +1/-0

Wire 'java-libs' library into the Java module classpath

• Adds a module order entry referencing the 'java-libs' IntelliJ project library. This ensures the Java module resolves the copied dependency jars automatically once present.

java/java.iml

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (1) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Bazel output parsed unsafely ✓ Resolved 🐞 Bug ☼ Reliability

Description

java:local_dev uses Bazel.execute output directly for execroot and jar paths, but Bazel.execute
captures combined stdout+stderr, so INFO/progress lines can be included and then treated as
filesystem paths. This can produce invalid execroot/jar entries and make FileUtils.cp fail during
the copy loop.

Code

rake_tasks/java.rake[R166-173]

+  execroot = nil
+  Bazel.execute('info', [], 'execution_root') { |out| execroot = out.strip }
+
+  jars = []
+  Bazel.execute('cquery', ['--output=starlark', "--starlark:expr=#{JAVA_LIBS_STARLARK}"],
+                'deps(kind("java_test", //java/test/...))') do |out|
+    jars = out.lines.map(&:strip).reject(&:empty?).uniq
+  end

Evidence

Bazel.execute captures combined stdout+stderr and passes the entire combined output string to the
provided block; local_dev then uses out.strip and out.lines without filtering. The same file
already demonstrates the need to filter Bazel output in another task, but local_dev does not.

rake_tasks/bazel.rb[22-54]
rake_tasks/java.rake[53-55]
rake_tasks/java.rake[166-173]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`java:local_dev` assumes `bazel info` and `bazel cquery` output is “just data”, but `Bazel.execute` merges stdout and stderr, so diagnostic/progress lines can be mixed in. The task then treats those lines as paths (execroot and jar relpaths), which can break path joins and cause `FileUtils.cp` to raise.

### Issue Context
- `Bazel.execute` uses `Open3.popen2e` (and `2>&1` on Windows) so stdout/stderr are combined.
- Other code in `java.rake` already filters Bazel output to the expected format, but `local_dev` currently does not.

### Fix Focus Areas
- rake_tasks/java.rake[166-173]
- rake_tasks/bazel.rb[22-54]

### What to change
- For `execution_root`: extract a single directory path line (e.g., `out.lines.map(&:strip).find { |l| File.directory?(l) }` or select directory candidates and take the last).
- For `cquery` jar list: filter to lines that look like jar paths (e.g., `end_with?(".jar")`) and ideally also `File.exist?(File.join(execroot, rel))`.
- Optionally add Bazel flags to reduce noise (if supported in this repo), but still keep parsing robust.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. java:local_dev lacks tests 📘 Rule violation ▣ Testability

Description

The PR introduces the new java:local_dev rake task but does not add or update any automated tests
to cover this new behavior. This violates the requirement that all new functionality include tests
with assertions guarding the added behavior.

Code

rake_tasks/java.rake[R162-185]

+desc 'Copy Bazel-built dependency jars to ./java-libs for local development'
+task :local_dev do
+  Bazel.execute('build', [], '//java/test/...')
+
+  execroot = nil
+  Bazel.execute('info', [], 'execution_root') { |out| execroot = out.strip }
+
+  jars = []
+  Bazel.execute('cquery', ['--output=starlark', "--starlark:expr=#{JAVA_LIBS_STARLARK}"],
+                'deps(kind("java_test", //java/test/...))') do |out|
+    jars = out.lines.map(&:strip).reject(&:empty?).uniq
+  end
+
+  lib = File.join(Dir.pwd, 'java-libs')
+  sources = File.join(lib, 'sources')
+  FileUtils.rm_rf(lib)
+  FileUtils.mkdir_p(sources)
+
+  jars.each do |rel|
+    base = File.basename(rel)
+    dir = base.end_with?('-sources.jar', '-src.jar') ? sources : lib
+    FileUtils.cp(File.join(execroot, rel), File.join(dir, base))
+  end
+end

Evidence

PR Compliance ID 389273 requires new functionality to include automated tests. The diff adds the
java:local_dev task implementation in rake_tasks/java.rake without any accompanying test
additions in the change set.

Rule 389273: Require tests for all new functionality and bug fixes
rake_tasks/java.rake[162-185]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A new rake task (`java:local_dev`) was added, but no automated tests were added/updated to validate its behavior (e.g., Bazel invocation, jar selection, and copy destination layout).

## Issue Context
Compliance requires tests for all new functionality; this task affects local developer setup and is easy to regress (e.g., wrong cquery expression, wrong destination paths, or failing to copy sources jars to `java-libs/sources`).

## Fix Focus Areas
- rake_tasks/java.rake[162-185]
- rb/spec/unit/rake_tasks/java_local_dev_spec.rb[1-200]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Unignored IDE output dir ✓ Resolved 🐞 Bug ➹ Performance ⭐ New

Description

java/java-dev.iml now writes IntelliJ compiler output to java/build/dev, but .bazelignore only
ignores java/build/production, so Bazel workspace/package scanning may traverse IDE-generated
outputs and waste time or cause occasional discovery surprises during bazel query/build runs.

Code

java/java-dev.iml[4]

+    <output url="file://$MODULE_DIR$/build/dev" />

Evidence

The IntelliJ module output directory was changed/introduced to java/build/dev, while Bazel’s
ignore list only includes the pre-existing production output directory, leaving the new directory
uncovered.

java/java-dev.iml[3-6]
.bazelignore[10-15]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
IntelliJ’s `java-dev` module outputs compiled classes into `java/build/dev`, but Bazel is only configured to ignore `java/build/production`. This can cause Bazel to scan IDE-generated output directories.

### Issue Context
The `java-dev.iml` output directory is new/updated in this PR.

### Fix Focus Areas
- .bazelignore[10-15]
- java/java-dev.iml[3-6]

### Suggested fix
Add `java/build/dev` to `.bazelignore` (or, if safe for this repo, ignore `java/build` entirely to cover all IntelliJ outputs).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

4. No production output configured ✓ Resolved 🐞 Bug ≡ Correctness

Description

java/java-dev.iml declares a non-test source root (src/dev) but configures only output-test
and neither sets a production <output ...> nor enables inherit-compiler-output, which can leave
IntelliJ with an unresolved/misconfigured production compiler output for that module.

Code

java/java-dev.iml[R3-5]

+  <component name="NewModuleRootManager" LANGUAGE_LEVEL="JDK_17">
+    <output-test url="file://$MODULE_DIR$/build/test" />
+    <exclude-output />

Evidence

java-dev.iml contains a non-test source folder but lacks any production output configuration,
whereas other modules in this repo either explicitly configure <output ...> (java module) or set
inherit-compiler-output="true" (e.g., common-web). This inconsistency is introduced by the new
module file and can lead to IntelliJ not having a defined production output path for compiling
src/dev.

java/java-dev.iml[3-11]
java/java.iml[6-12]
common/common-web.iml[6-10]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new `java-dev` IntelliJ module has production sources (`src/dev`) but does not specify a production compiler output directory.

## Issue Context
In this repo, the existing Java module (`java/java.iml`) explicitly sets a production output, while other modules opt into project output via `inherit-compiler-output="true"`. `java-dev.iml` currently sets only `<output-test ...>`.

## Fix Focus Areas
- java/java-dev.iml[3-11]

### Suggested fix
Pick one consistent approach:
1) Add a production output:
  - Add `<output url="file://$MODULE_DIR$/build/production" />` (or a distinct folder like `build/production-dev`) alongside the existing `<output-test ...>`.

OR
2) Inherit project compiler output:
  - Set `inherit-compiler-output="true"` on `NewModuleRootManager` and remove/adjust output entries as appropriate for IntelliJ.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

5. Jar basename overwrites 🐞 Bug ≡ Correctness

Description

java:local_dev flattens all copied jars into java-libs/ (and java-libs/sources) using
File.basename(rel), so two distinct jar paths with the same basename will overwrite each other. This
can silently drop dependencies and lead to missing/incorrect classes in the IDE.

Code

rake_tasks/java.rake[R180-184]

+  jars.each do |rel|
+    base = File.basename(rel)
+    dir = base.end_with?('-sources.jar', '-src.jar') ? sources : lib
+    FileUtils.cp(File.join(execroot, rel), File.join(dir, base))
+  end

Evidence

The task derives the destination filename from File.basename(rel) and copies into a single
directory per type, so distinct rel values that share a basename will collide and overwrite
because uniq is applied before basename mapping.

rake_tasks/java.rake[169-184]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The copy loop uses `File.basename(rel)` as the destination filename, which loses uniqueness information. If two different jars share the same basename, the later copy overwrites the former, producing an incomplete `java-libs` set.

### Issue Context
The jar list is deduped by full relative path (`uniq`), not by basename, so basename collisions are not prevented.

### Fix Focus Areas
- rake_tasks/java.rake[180-184]
- .idea/libraries/java-libs.xml[1-11]

### What to change
Choose one approach:
1) **Preserve relative paths** under `java-libs` (e.g., copy to `java-libs/<rel>` and mkdir_p parent dirs). Update `.idea/libraries/java-libs.xml` jarDirectory entries to `recursive="true"` so IntelliJ picks up jars in subdirectories.
2) **Make filenames unique** in the flat directory (e.g., prefix with a short hash of `rel`), and optionally add a collision check that raises if a destination already exists with different content.

Either way, ensure both class jars and source jars cannot overwrite each other within their respective directories.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Previous review results

Review updated until commit 77d01de

Results up to commit 6c81653

🐞 Bugs (1) 📘 Rule violations (1) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Bazel output parsed unsafely ✓ Resolved 🐞 Bug ☼ Reliability

Description

java:local_dev uses Bazel.execute output directly for execroot and jar paths, but Bazel.execute
captures combined stdout+stderr, so INFO/progress lines can be included and then treated as
filesystem paths. This can produce invalid execroot/jar entries and make FileUtils.cp fail during
the copy loop.

Code

rake_tasks/java.rake[R166-173]

+  execroot = nil
+  Bazel.execute('info', [], 'execution_root') { |out| execroot = out.strip }
+
+  jars = []
+  Bazel.execute('cquery', ['--output=starlark', "--starlark:expr=#{JAVA_LIBS_STARLARK}"],
+                'deps(kind("java_test", //java/test/...))') do |out|
+    jars = out.lines.map(&:strip).reject(&:empty?).uniq
+  end

Evidence

Bazel.execute captures combined stdout+stderr and passes the entire combined output string to the
provided block; local_dev then uses out.strip and out.lines without filtering. The same file
already demonstrates the need to filter Bazel output in another task, but local_dev does not.

rake_tasks/bazel.rb[22-54]
rake_tasks/java.rake[53-55]
rake_tasks/java.rake[166-173]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`java:local_dev` assumes `bazel info` and `bazel cquery` output is “just data”, but `Bazel.execute` merges stdout and stderr, so diagnostic/progress lines can be mixed in. The task then treats those lines as paths (execroot and jar relpaths), which can break path joins and cause `FileUtils.cp` to raise.

### Issue Context
- `Bazel.execute` uses `Open3.popen2e` (and `2>&1` on Windows) so stdout/stderr are combined.
- Other code in `java.rake` already filters Bazel output to the expected format, but `local_dev` currently does not.

### Fix Focus Areas
- rake_tasks/java.rake[166-173]
- rake_tasks/bazel.rb[22-54]

### What to change
- For `execution_root`: extract a single directory path line (e.g., `out.lines.map(&:strip).find { |l| File.directory?(l) }` or select directory candidates and take the last).
- For `cquery` jar list: filter to lines that look like jar paths (e.g., `end_with?(".jar")`) and ideally also `File.exist?(File.join(execroot, rel))`.
- Optionally add Bazel flags to reduce noise (if supported in this repo), but still keep parsing robust.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. java:local_dev lacks tests 📘 Rule violation ▣ Testability

Description

The PR introduces the new java:local_dev rake task but does not add or update any automated tests
to cover this new behavior. This violates the requirement that all new functionality include tests
with assertions guarding the added behavior.

Code

rake_tasks/java.rake[R162-185]

+desc 'Copy Bazel-built dependency jars to ./java-libs for local development'
+task :local_dev do
+  Bazel.execute('build', [], '//java/test/...')
+
+  execroot = nil
+  Bazel.execute('info', [], 'execution_root') { |out| execroot = out.strip }
+
+  jars = []
+  Bazel.execute('cquery', ['--output=starlark', "--starlark:expr=#{JAVA_LIBS_STARLARK}"],
+                'deps(kind("java_test", //java/test/...))') do |out|
+    jars = out.lines.map(&:strip).reject(&:empty?).uniq
+  end
+
+  lib = File.join(Dir.pwd, 'java-libs')
+  sources = File.join(lib, 'sources')
+  FileUtils.rm_rf(lib)
+  FileUtils.mkdir_p(sources)
+
+  jars.each do |rel|
+    base = File.basename(rel)
+    dir = base.end_with?('-sources.jar', '-src.jar') ? sources : lib
+    FileUtils.cp(File.join(execroot, rel), File.join(dir, base))
+  end
+end

Evidence

PR Compliance ID 389273 requires new functionality to include automated tests. The diff adds the
java:local_dev task implementation in rake_tasks/java.rake without any accompanying test
additions in the change set.

Rule 389273: Require tests for all new functionality and bug fixes
rake_tasks/java.rake[162-185]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A new rake task (`java:local_dev`) was added, but no automated tests were added/updated to validate its behavior (e.g., Bazel invocation, jar selection, and copy destination layout).

## Issue Context
Compliance requires tests for all new functionality; this task affects local developer setup and is easy to regress (e.g., wrong cquery expression, wrong destination paths, or failing to copy sources jars to `java-libs/sources`).

## Fix Focus Areas
- rake_tasks/java.rake[162-185]
- rb/spec/unit/rake_tasks/java_local_dev_spec.rb[1-200]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Jar basename overwrites 🐞 Bug ≡ Correctness

Description

java:local_dev flattens all copied jars into java-libs/ (and java-libs/sources) using
File.basename(rel), so two distinct jar paths with the same basename will overwrite each other. This
can silently drop dependencies and lead to missing/incorrect classes in the IDE.

Code

rake_tasks/java.rake[R180-184]

+  jars.each do |rel|
+    base = File.basename(rel)
+    dir = base.end_with?('-sources.jar', '-src.jar') ? sources : lib
+    FileUtils.cp(File.join(execroot, rel), File.join(dir, base))
+  end

Evidence

The task derives the destination filename from File.basename(rel) and copies into a single
directory per type, so distinct rel values that share a basename will collide and overwrite
because uniq is applied before basename mapping.

rake_tasks/java.rake[169-184]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The copy loop uses `File.basename(rel)` as the destination filename, which loses uniqueness information. If two different jars share the same basename, the later copy overwrites the former, producing an incomplete `java-libs` set.

### Issue Context
The jar list is deduped by full relative path (`uniq`), not by basename, so basename collisions are not prevented.

### Fix Focus Areas
- rake_tasks/java.rake[180-184]
- .idea/libraries/java-libs.xml[1-11]

### What to change
Choose one approach:
1) **Preserve relative paths** under `java-libs` (e.g., copy to `java-libs/<rel>` and mkdir_p parent dirs). Update `.idea/libraries/java-libs.xml` jarDirectory entries to `recursive="true"` so IntelliJ picks up jars in subdirectories.
2) **Make filenames unique** in the flat directory (e.g., prefix with a short hash of `rel`), and optionally add a collision check that raises if a destination already exists with different content.

Either way, ensure both class jars and source jars cannot overwrite each other within their respective directories.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Results up to commit a45d812

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. No production output configured ✓ Resolved 🐞 Bug ≡ Correctness

Description

java/java-dev.iml declares a non-test source root (src/dev) but configures only output-test
and neither sets a production <output ...> nor enables inherit-compiler-output, which can leave
IntelliJ with an unresolved/misconfigured production compiler output for that module.

Code

java/java-dev.iml[R3-5]

+  <component name="NewModuleRootManager" LANGUAGE_LEVEL="JDK_17">
+    <output-test url="file://$MODULE_DIR$/build/test" />
+    <exclude-output />

Evidence

java-dev.iml contains a non-test source folder but lacks any production output configuration,
whereas other modules in this repo either explicitly configure <output ...> (java module) or set
inherit-compiler-output="true" (e.g., common-web). This inconsistency is introduced by the new
module file and can lead to IntelliJ not having a defined production output path for compiling
src/dev.

java/java-dev.iml[3-11]
java/java.iml[6-12]
common/common-web.iml[6-10]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new `java-dev` IntelliJ module has production sources (`src/dev`) but does not specify a production compiler output directory.

## Issue Context
In this repo, the existing Java module (`java/java.iml`) explicitly sets a production output, while other modules opt into project output via `inherit-compiler-output="true"`. `java-dev.iml` currently sets only `<output-test ...>`.

## Fix Focus Areas
- java/java-dev.iml[3-11]

### Suggested fix
Pick one consistent approach:
1) Add a production output:
  - Add `<output url="file://$MODULE_DIR$/build/production" />` (or a distinct folder like `build/production-dev`) alongside the existing `<output-test ...>`.

OR
2) Inherit project compiler output:
  - Set `inherit-compiler-output="true"` on `NewModuleRootManager` and remove/adjust output entries as appropriate for IntelliJ.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[qodo-code-review]

Code review by qodo was updated up to the latest commit d9eeb3b

[Copilot]

Pull request overview

Adds Java local-development tooling to the Selenium monorepo by introducing a java:local_dev rake task and IntelliJ IDEA project wiring so contributors can work in IDEA without relying on the Bazel plugin, using jars materialized into ./java-libs.

Changes:

• Add java:local_dev rake task to build and copy Bazel-derived dependency jars into ./java-libs (with a sources/ subdir).
• Wire IntelliJ to resolve a new project-level java-libs library and add it to the java module.
• Ignore the generated ./java-libs directory in git.

Reviewed changes

Copilot reviewed 2 out of 4 changed files in this pull request and generated 4 comments.

File	Description
rake_tasks/java.rake	Adds the java:local_dev task and the Starlark cquery expression used to collect dependency jars.
java/java.iml	Adds a module order entry referencing the new java-libs IDEA project library.
.idea/libraries/java-libs.xml	Defines the IDEA project library pointing at java-libs/ and java-libs/sources/.
.gitignore	Ignores the generated java-libs directory.

Files not reviewed (1)

• .idea/libraries/java-libs.xml: Generated file

[qodo-code-review]

Code review by qodo was updated up to the latest commit d004a02

[Copilot]

Pull request overview

Copilot reviewed 2 out of 4 changed files in this pull request and generated 1 comment.

Files not reviewed (1)

• .idea/libraries/java-libs.xml: Generated file

[qodo-code-review]

Code review by qodo was updated up to the latest commit 74c91e3

[asolntsev]

@titusfortner Thanks, it almost works!

Few problems:

1. src/dev/selenium/tools doesn't compile

2. Java tests don't compile.
   The simplest solution is to set Java Level to 17 for the whole Java module.
   A bit more complex solution is to have 2 separate IDEA modules: "Java production code" (Java level 11) and "Java tests" (Java level 17).

3. "Errorprone" dependency requires JDK 21:

java: An exception has occurred in the compiler (17.0.14). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com) after checking the Bug Database (https://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
java: java.lang.UnsupportedClassVersionError: com/google/errorprone/ErrorProneJavacPlugin has been compiled by a more recent version of the Java Runtime (class file version 65.0), this version of the Java Runtime only recognizes class file versions up to 61.0

So we need to set Project SDK to JDK 21.

[titusfortner]

@asolntsev I went with the more complex solution so that we keep the IDE enforcement of Java 11, but I think that should work

[qodo-code-review]

Code review by qodo was updated up to the latest commit a45d812

[qodo-code-review]

Code review by qodo was updated up to the latest commit fb1cf9c

[qodo-code-review]

Code review by qodo was updated up to the latest commit c3a7c09

[asolntsev]

@titusfortner I tried to fresh-clone the branch - still getting an error in IDEA:

[qodo-code-review]

Code review by qodo was updated up to the latest commit 87ad213

[titusfortner]

@asolntsev
the task now also builds and queries //java/src/dev/..., and the filter keeps libzip.jar
Hopefully, this solves it all

[asolntsev]

@titusfortner Now it's failing with a new error :)
Clearing Bazel cache doesn't help.

./go java:local_dev  
Executing: bazel build //java/test/... --pin_browsers=false
Executing: bazel build //java/src/dev/... --pin_browsers=false
Executing: bazel info execution_root
Executing: bazel cquery deps(kind("java_test", //java/test/...)) + deps(//java/src/dev/...) --pin_browsers=false --output=starlark --starlark:expr="\n".join([ f.path for f in target.files.to_list() if f.path.endswith(".jar") and ("-exec/" not in f.path) and (f.path.startswith("external/") or "/genfiles/" in f.path or f.path.endswith("librunfiles.jar") or f.path.endswith("libzip.jar") or ("/devtools/v" in f.path and f.path.endswith("-project.jar"))) and (not "junit-jupiter-engine" in f.path) and (not "junit-platform-engine" in f.path) and (not "junit-platform-launcher" in f.path) and (not "junit-platform-reporting" in f.path) ])
go aborted!
Errno::ENOENT: No such file or directory - /Users/andrei/Library/Caches/bazel/_bazel_andrei/70d0c8b422baff5efbd4ce50da98605a/execroot/_main/external/rules_jvm_external++maven+org_junit_jupiter_junit_jupiter_params_6_1_1/file/v1/org/junit/jupiter/junit-jupiter-params/6.1.1/junit-jupiter-params-6.1.1.jar
/Users/andrei/temp/selenium/rake_tasks/java.rake:192:in `block in <main>'
/Users/andrei/temp/selenium/rake_tasks/java.rake:187:in `block in <main>'
org/jruby/ext/monitor/Monitor.java:82:in `synchronize'
Tasks: TOP => java:local_dev
(See full trace by running task with --trace)`

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (3) 📘 Rule violations (1) 📜 Skill insights (0)

1. Processed jars skipped 🐞 Bug ≡ Correctness

Description

resolved_third_party_jars strips processed_/header_ from Maven jar basenames, but
java:local_dev later filters copied jars using the unstripped File.basename(path), so Bazel
outputs with these prefixes will be excluded and required dependencies won’t be copied to
java-libs. This can leave IntelliJ missing classes at compile/runtime even though the cquery
reported them as needed.

Code

rake_tasks/java.rake[R209-213]

+    base = File.basename(path)
+    # Third-party jars are scoped to the resolved classpath; Selenium's generated jars pass through.
+    if path.include?(maven_tree)
+      stem = base.sub(/-(?:sources|src)\.jar$/, '.jar')
+      next unless needed.include?(base) || needed.include?(stem)

Evidence

The cquery result list is normalized by stripping processed_/header_, but the later inclusion
check is against the raw basename, so any jar present on the resolved classpath with these prefixes
will never satisfy needed.include?(...) and will be skipped.

rake_tasks/java.rake[157-171]
rake_tasks/java.rake[208-217]
java/src/dev/selenium/tools/modules/ModuleGenerator.java[179-193]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`resolved_third_party_jars` normalizes Maven jar basenames by removing `processed_`/`header_`, but the later copy loop compares `needed` against the *raw* basename (still containing those prefixes). This mismatch causes prefixed jars to be filtered out and not copied.

### Issue Context
This primarily impacts jars produced by `rules_jvm_external` that commonly carry `processed_`/`header_` prefixes. The codebase already acknowledges these prefixes elsewhere (e.g., tooling that strips `processed_`).

### Fix Focus Areas
- rake_tasks/java.rake[165-171]
- rake_tasks/java.rake[208-217]

### Suggested fix
In the copy loop, compute a normalized name (same normalization as `resolved_third_party_jars`) for *matching* only, while keeping the original filename for copying:
- `raw_base = File.basename(path)`
- `match_base = raw_base.sub(/\A(?:processed|header)_/, '')`
- `stem = match_base.sub(/-(?:sources|src)\.jar$/, '.jar')`
- `next unless needed.include?(match_base) || needed.include?(stem)`

Optionally, also apply the same normalization when rejecting `JAVA_LIBS_IDE_TEST_RUNTIME` so `processed_junit-...` is filtered as intended.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. local_dev can succeed empty ✓ Resolved 🐞 Bug ☼ Reliability

Description

java:local_dev deletes ./java-libs and then copies whatever jars match several Dir.glob
patterns, but it never validates that any usable jars were found/copied. If the glob patterns don’t
match (or everything is filtered out later), the task finishes “successfully” with an empty
java-libs/, leaving IntelliJ without required dependencies.

Code

rake_tasks/java.rake[R173-184]

+  jars = Dir.glob([
+                    File.join(bin, 'external/rules_jvm_external++maven+maven/**/*.jar'),
+                    File.join(bin, 'java/src/org/openqa/selenium/devtools/v*/v*-project.jar'),
+                    File.join(bin, 'external/rules_java+/**/librunfiles.jar'),
+                    File.join(bin, 'external/rules_jvm_external+/**/libzip.jar')
+                  ]).reject { |path| path.include?('-exec/') }
+
+  lib = File.join(Dir.pwd, 'java-libs')
+  sources = File.join(lib, 'sources')
+  FileUtils.rm_rf(lib)
+  FileUtils.mkdir_p(sources)
+

Evidence

The task builds targets, computes jars = Dir.glob(...), then unconditionally rm_rf’s java-libs
and iterates jars.each without any guard; if jars is empty, nothing is copied and the task still
ends normally.

rake_tasks/java.rake[169-194]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`java:local_dev` can complete without errors while producing an empty `java-libs/` directory because it never checks whether the jar globbing step found any artifacts. Since the task also unconditionally deletes the previous `java-libs/`, this can turn a previously working setup into a broken one.

### Issue Context
`Dir.glob([...])` returns `[]` when patterns match nothing. The task then runs `FileUtils.rm_rf(lib)` and creates the directories, but `jars.each` becomes a no-op.

### Fix Focus Areas
- rake_tasks/java.rake[169-194]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Bazel output parsed unsafely ✓ Resolved 🐞 Bug ☼ Reliability

Description

java:local_dev uses Bazel.execute output directly for execroot and jar paths, but Bazel.execute
captures combined stdout+stderr, so INFO/progress lines can be included and then treated as
filesystem paths. This can produce invalid execroot/jar entries and make FileUtils.cp fail during
the copy loop.

Code

rake_tasks/java.rake[R166-173]

+  execroot = nil
+  Bazel.execute('info', [], 'execution_root') { |out| execroot = out.strip }
+
+  jars = []
+  Bazel.execute('cquery', ['--output=starlark', "--starlark:expr=#{JAVA_LIBS_STARLARK}"],
+                'deps(kind("java_test", //java/test/...))') do |out|
+    jars = out.lines.map(&:strip).reject(&:empty?).uniq
+  end

Evidence

Bazel.execute captures combined stdout+stderr and passes the entire combined output string to the
provided block; local_dev then uses out.strip and out.lines without filtering. The same file
already demonstrates the need to filter Bazel output in another task, but local_dev does not.

rake_tasks/bazel.rb[22-54]
rake_tasks/java.rake[53-55]
rake_tasks/java.rake[166-173]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`java:local_dev` assumes `bazel info` and `bazel cquery` output is “just data”, but `Bazel.execute` merges stdout and stderr, so diagnostic/progress lines can be mixed in. The task then treats those lines as paths (execroot and jar relpaths), which can break path joins and cause `FileUtils.cp` to raise.

### Issue Context
- `Bazel.execute` uses `Open3.popen2e` (and `2>&1` on Windows) so stdout/stderr are combined.
- Other code in `java.rake` already filters Bazel output to the expected format, but `local_dev` currently does not.

### Fix Focus Areas
- rake_tasks/java.rake[166-173]
- rake_tasks/bazel.rb[22-54]

### What to change
- For `execution_root`: extract a single directory path line (e.g., `out.lines.map(&:strip).find { |l| File.directory?(l) }` or select directory candidates and take the last).
- For `cquery` jar list: filter to lines that look like jar paths (e.g., `end_with?(".jar")`) and ideally also `File.exist?(File.join(execroot, rel))`.
- Optionally add Bazel flags to reduce noise (if supported in this repo), but still keep parsing robust.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

View more (1)

4. java:local_dev lacks tests 📘 Rule violation ▣ Testability

Description

The PR introduces the new java:local_dev rake task but does not add or update any automated tests
to cover this new behavior. This violates the requirement that all new functionality include tests
with assertions guarding the added behavior.

Code

rake_tasks/java.rake[R162-185]

+desc 'Copy Bazel-built dependency jars to ./java-libs for local development'
+task :local_dev do
+  Bazel.execute('build', [], '//java/test/...')
+
+  execroot = nil
+  Bazel.execute('info', [], 'execution_root') { |out| execroot = out.strip }
+
+  jars = []
+  Bazel.execute('cquery', ['--output=starlark', "--starlark:expr=#{JAVA_LIBS_STARLARK}"],
+                'deps(kind("java_test", //java/test/...))') do |out|
+    jars = out.lines.map(&:strip).reject(&:empty?).uniq
+  end
+
+  lib = File.join(Dir.pwd, 'java-libs')
+  sources = File.join(lib, 'sources')
+  FileUtils.rm_rf(lib)
+  FileUtils.mkdir_p(sources)
+
+  jars.each do |rel|
+    base = File.basename(rel)
+    dir = base.end_with?('-sources.jar', '-src.jar') ? sources : lib
+    FileUtils.cp(File.join(execroot, rel), File.join(dir, base))
+  end
+end

Evidence

PR Compliance ID 389273 requires new functionality to include automated tests. The diff adds the
java:local_dev task implementation in rake_tasks/java.rake without any accompanying test
additions in the change set.

Rule 389273: Require tests for all new functionality and bug fixes
rake_tasks/java.rake[162-185]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A new rake task (`java:local_dev`) was added, but no automated tests were added/updated to validate its behavior (e.g., Bazel invocation, jar selection, and copy destination layout).

## Issue Context
Compliance requires tests for all new functionality; this task affects local developer setup and is easy to regress (e.g., wrong cquery expression, wrong destination paths, or failing to copy sources jars to `java-libs/sources`).

## Fix Focus Areas
- rake_tasks/java.rake[162-185]
- rb/spec/unit/rake_tasks/java_local_dev_spec.rb[1-200]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

5. IDE API mismatch risk 🐞 Bug ≡ Correctness

Description

The IntelliJ project SDK is changed to JDK 25 while both Java modules inherit that SDK, so IntelliJ
will resolve Java 25 platform APIs even for modules set to language levels 11/17. This can allow
code to compile/run in the IDE but fail under Bazel’s --release 11/17 builds due to using newer
JDK APIs.

Code

.idea/misc.xml[7]

+  <component name="ProjectRootManager" version="2" languageLevel="JDK_11" default="false" project-jdk-name="25" project-jdk-type="JavaSDK">

Evidence

The project SDK is now 25, and both modules explicitly inherit the project JDK; there is no
IntelliJ compiler configuration in-repo that constrains the bootclasspath/API level to Java 11/17,
so API incompatibilities can be missed locally.

.idea/misc.xml[7-9]
java/java.iml[6-18]
java/java-dev.iml[3-18]
.idea/compiler.xml[1-31]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
IntelliJ is configured with project SDK `25`, and both `java` (LANGUAGE_LEVEL=JDK_11) and `java-dev` (LANGUAGE_LEVEL=JDK_17) modules use `<orderEntry type="inheritedJdk" />`. Language level limits syntax, but the inherited SDK controls the platform API classpath, so developers may accidentally use Java APIs added after 11/17 without IDE errors.

### Issue Context
This PR’s stated goal is to keep released code constrained to Java 11 and dev/test code to Java 17. With inherited JDK 25, IntelliJ will not reliably enforce those API baselines.

### Fix Focus Areas
- .idea/misc.xml[7-9]
- java/java.iml[6-18]
- java/java-dev.iml[3-18]

### Suggested fix
Either:
1) Set the `java` module to use a Java 11 SDK and `java-dev` module to use a Java 17 SDK (replace `inheritedJdk` with explicit `jdk` entries), while keeping project SDK as desired, **or**
2) Keep SDK 25 but add IntelliJ compiler/bytecode target configuration to enforce `--release 11` for `java` and `--release 17` for `java-dev` (so API resolution matches Bazel).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

6. java-libs not bazelignored ✓ Resolved 🐞 Bug ➹ Performance

Description

java:local_dev generates a workspace-local java-libs/ directory full of jar files, but
.bazelignore doesn’t exclude it, so Bazel package discovery may do unnecessary filesystem
traversal after the task is run. This can add avoidable overhead to local bazel query/build
workflows on machines that have run the task.

Code

.bazelignore[R12-15]

+java/build
java/client/build
java/server/build
javascript/atoms/node_modules

Evidence

.bazelignore lists other generated/large directories to skip but does not include java-libs,
while the new rake task explicitly deletes and repopulates java-libs with copied .jar files and
.gitignore now ignores java-libs as a generated directory.

.bazelignore[1-19]
.gitignore[1-17]
rake_tasks/java.rake[155-193]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The new `java:local_dev` task populates `./java-libs` with many jars, but `.bazelignore` does not list `java-libs`, so Bazel may traverse this generated directory during package discovery.

### Issue Context
`java-libs` is intentionally generated/ephemeral (already added to `.gitignore`). Adding it to `.bazelignore` keeps Bazel from spending time scanning a jar-heavy directory that contains no Bazel packages.

### Fix Focus Areas
- .bazelignore[1-19]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

7. Unignored IDE output dir ✓ Resolved 🐞 Bug ➹ Performance

Description

java/java-dev.iml now writes IntelliJ compiler output to java/build/dev, but .bazelignore only
ignores java/build/production, so Bazel workspace/package scanning may traverse IDE-generated
outputs and waste time or cause occasional discovery surprises during bazel query/build runs.

Code

java/java-dev.iml[4]

+    <output url="file://$MODULE_DIR$/build/dev" />

Evidence

The IntelliJ module output directory was changed/introduced to java/build/dev, while Bazel’s
ignore list only includes the pre-existing production output directory, leaving the new directory
uncovered.

java/java-dev.iml[3-6]
.bazelignore[10-15]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
IntelliJ’s `java-dev` module outputs compiled classes into `java/build/dev`, but Bazel is only configured to ignore `java/build/production`. This can cause Bazel to scan IDE-generated output directories.

### Issue Context
The `java-dev.iml` output directory is new/updated in this PR.

### Fix Focus Areas
- .bazelignore[10-15]
- java/java-dev.iml[3-6]

### Suggested fix
Add `java/build/dev` to `.bazelignore` (or, if safe for this repo, ignore `java/build` entirely to cover all IntelliJ outputs).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

View more (2)

8. No production output configured ✓ Resolved 🐞 Bug ≡ Correctness

Description

java/java-dev.iml declares a non-test source root (src/dev) but configures only output-test
and neither sets a production <output ...> nor enables inherit-compiler-output, which can leave
IntelliJ with an unresolved/misconfigured production compiler output for that module.

Code

java/java-dev.iml[R3-5]

+  <component name="NewModuleRootManager" LANGUAGE_LEVEL="JDK_17">
+    <output-test url="file://$MODULE_DIR$/build/test" />
+    <exclude-output />

Evidence

java-dev.iml contains a non-test source folder but lacks any production output configuration,
whereas other modules in this repo either explicitly configure <output ...> (java module) or set
inherit-compiler-output="true" (e.g., common-web). This inconsistency is introduced by the new
module file and can lead to IntelliJ not having a defined production output path for compiling
src/dev.

java/java-dev.iml[3-11]
java/java.iml[6-12]
common/common-web.iml[6-10]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new `java-dev` IntelliJ module has production sources (`src/dev`) but does not specify a production compiler output directory.

## Issue Context
In this repo, the existing Java module (`java/java.iml`) explicitly sets a production output, while other modules opt into project output via `inherit-compiler-output="true"`. `java-dev.iml` currently sets only `<output-test ...>`.

## Fix Focus Areas
- java/java-dev.iml[3-11]

### Suggested fix
Pick one consistent approach:
1) Add a production output:
  - Add `<output url="file://$MODULE_DIR$/build/production" />` (or a distinct folder like `build/production-dev`) alongside the existing `<output-test ...>`.

OR
2) Inherit project compiler output:
  - Set `inherit-compiler-output="true"` on `NewModuleRootManager` and remove/adjust output entries as appropriate for IntelliJ.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

9. Jar basename overwrites 🐞 Bug ≡ Correctness

Description

java:local_dev flattens all copied jars into java-libs/ (and java-libs/sources) using
File.basename(rel), so two distinct jar paths with the same basename will overwrite each other. This
can silently drop dependencies and lead to missing/incorrect classes in the IDE.

Code

rake_tasks/java.rake[R180-184]

+  jars.each do |rel|
+    base = File.basename(rel)
+    dir = base.end_with?('-sources.jar', '-src.jar') ? sources : lib
+    FileUtils.cp(File.join(execroot, rel), File.join(dir, base))
+  end

Evidence

The task derives the destination filename from File.basename(rel) and copies into a single
directory per type, so distinct rel values that share a basename will collide and overwrite
because uniq is applied before basename mapping.

rake_tasks/java.rake[169-184]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The copy loop uses `File.basename(rel)` as the destination filename, which loses uniqueness information. If two different jars share the same basename, the later copy overwrites the former, producing an incomplete `java-libs` set.

### Issue Context
The jar list is deduped by full relative path (`uniq`), not by basename, so basename collisions are not prevented.

### Fix Focus Areas
- rake_tasks/java.rake[180-184]
- .idea/libraries/java-libs.xml[1-11]

### What to change
Choose one approach:
1) **Preserve relative paths** under `java-libs` (e.g., copy to `java-libs/<rel>` and mkdir_p parent dirs). Update `.idea/libraries/java-libs.xml` jarDirectory entries to `recursive="true"` so IntelliJ picks up jars in subdirectories.
2) **Make filenames unique** in the flat directory (e.g., prefix with a short hash of `rel`), and optionally add a collision check that raises if a destination already exists with different content.

Either way, ensure both class jars and source jars cannot overwrite each other within their respective directories.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

10. Windows path separator bug ✓ Resolved 🐞 Bug ☼ Reliability

Description

java:local_dev tries to filter out -exec outputs using path.include?('-exec/'), which is
Unix-path specific and won’t match backslash-separated paths. On Windows this can make the filter
ineffective and may copy unintended Bazel outputs into java-libs.

Code

rake_tasks/java.rake[R173-178]

+  jars = Dir.glob([
+                    File.join(bin, 'external/rules_jvm_external++maven+maven/**/*.jar'),
+                    File.join(bin, 'java/src/org/openqa/selenium/devtools/v*/v*-project.jar'),
+                    File.join(bin, 'external/rules_java+/**/librunfiles.jar'),
+                    File.join(bin, 'external/rules_jvm_external+/**/libzip.jar')
+                  ]).reject { |path| path.include?('-exec/') }

Evidence

The new rake task hardcodes a Unix -exec/ substring check, while the shared Bazel helper
explicitly supports Windows execution, so this filter is an inconsistent portability point.

rake_tasks/java.rake[172-179]
rake_tasks/bazel.rb[9-33]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`java:local_dev` filters globbed jar paths with `path.include?('-exec/')`. On Windows, `Dir.glob` commonly yields paths with `\`, so the intended filter may not match.

### Issue Context
The rake Bazel wrapper has explicit Windows behavior, implying these tasks should work cross-platform.

### Fix Focus Areas
- rake_tasks/java.rake[172-179]

### Suggested fix
Normalize separators before filtering (e.g., `normalized = path.tr('\\', '/')`) or use a separator-agnostic regex, e.g.:
- `reject { |p| p.match?(/-exec[\\/]/) }`
so the filter behaves consistently across platforms.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[qodo-code-review]

Code review by qodo was updated up to the latest commit 02f1b83

[qodo-code-review]

Code review by qodo was updated up to the latest commit f8931fa

[qodo-code-review]

Code review by qodo was updated up to the latest commit 8dddc3d

[titusfortner]

@asolntsev ok, try now, thanks

[asolntsev]

Still compilation errors:

Another problem: IDEA shows billion of changed files - though I haven't changed any files:

[qodo-code-review]

Code review by qodo was updated up to the latest commit cdfeea4

[Copilot]

Pull request overview

Copilot reviewed 5 out of 10 changed files in this pull request and generated 1 comment.

Files not reviewed (4)

• .idea/libraries/java-libs.xml: Generated file
• .idea/libraries/libcdp.xml: Generated file
• .idea/misc.xml: Generated file
• .idea/modules.xml: Generated file

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[qodo-code-review]

Code review by qodo was updated up to the latest commit 77d01de

[titusfortner]

@asolntsev ok I spent more time on rewriting this a bit so it doesn't start seeming like a hack on top of another. This seems to work locally in all the ways I tested it.