[PR #5204] [CLOSED] fix(android): select Windows JADX java.exe from PATH, not the working directory #6810

Closed
opened 2026-11-01 21:43:12 +00:00 by bsakaguchi · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/5204
Author: @ranmori
Created: 10/19/2026
Status: ❌ Closed

Base: main ← Head: fix/jadx-windows-path-java


📝 Commits (2)

  • 0b92dc4 fix(android): select Windows JADX java.exe from PATH, not the working directory
  • 0c599b9 Merge branch 'main' into fix/jadx-windows-path-java

📊 Changes

2 files changed (+74 additions, -29 deletions)

View changed files

📝 src/android/JadxConfiguration.ts (+44 -28)
📝 tests/boundary/android/jadxConfiguration.test.ts (+30 -1)

📄 Description

Summary

Fixes #5096.

With JAVA_HOME absent, Windows JADX configuration searched the process working directory before the selected PATH. A stray java.exe there therefore won over the JDK the caller selected, even when that directory was not on PATH. This PR searches only the PATH entries, as docs/android-analysis.md already describes ("resolves java.exe on the selected Windows PATH").

The issue was source-only; this PR adds a native Windows reproduction of the bug and of the fix.

Problem and expected behaviora

Trigger: Windows x64, JAVA_HOME unset, a java.exe in the process working directory, and a different JDK selected through PATH.

  • Before: resolveJava iterated [process.cwd(), ...PATH entries] and returned the first readable java.exe, so the working-directory file was probed and used for the engine session.
  • A second route to the same result: an empty PATH entry, such as the trailing ; common in real Windows PATH values, resolved through resolve("", "java.exe") to the working directory as well.
  • After: only non-empty PATH entries are searched, in order. A caller who lists the working directory (for example .) still selects it, and an absolute JAVA_HOME still takes precedence.

Change and scope

  • The Windows PATH search moves out of resolveJava into an exported findWindowsPathJava(path, signal) in src/android/JadxConfiguration.ts. It drops the process.cwd() candidate and skips empty entries. Quote stripping, the readable/executable/regular-file checks, canonicalization, and the runtime_missing failure for an uninspectable candidate are unchanged.
  • resolveJava calls it and keeps its existing "Cannot find java.exe on the selected Windows PATH" failure when nothing is found.

Not included: the non-Windows path (java resolved by the spawn) and JAVA_HOME handling are untouched. There is no fallback to another PATH JDK when the first one later fails validation; the issue mentions that only as a consequence of the working-directory selection.

Contract and boundary impact

  • Semantic owner and earliest changed stage: src/android/JadxConfiguration.ts, Java selection during JADX configuration.
  • CLI and MCP/tool-catalog contract: none.
  • Provider, bridge, target-format, or platform compatibility: Windows x64 JADX only. Hosts that relied on a working-directory java.exe with no JAVA_HOME and no matching PATH entry now get the existing runtime_missing failure with its JAVA_HOME/PATH guidance.
  • Evidence, artifact, provenance, or reconstruction contract: none.
  • Process execution, authorization, cleanup, or containment impact: the selected Java executable can only come from JAVA_HOME or a caller-listed PATH entry.
  • Generated metadata, package, or installation impact: none. The existing docs already describe the new behavior.

Evidence and regression coverage

  • Tests added: selects java.exe from the Windows PATH, not the working directory in tests/boundary/android/jadxConfiguration.test.ts. It runs on every platform, unlike the rest of that file, which skips on Windows. It changes into a temporary working directory containing java.exe, then checks that:
    • a PATH with leading and trailing empty entries selects the PATH JDK;
    • a quoted entry selects the PATH JDK;
    • a PATH of only a separator selects nothing;
    • a PATH listing . selects the working-directory file.
  • Base reproduction, executed on Windows 11 x64 (build 26200), Node 24.13.0, base ba866a26, with the published rea-agents@6.7.0 Windows native addon. I called resolveJadxConfigurationInputs from each build's compiled dist with REA_JADX_MCP_JAR set, JAVA_HOME unset, PATH=<scratch>\selected-jdk\bin;%SystemRoot%\System32;, and the working directory set to <scratch>\working:
    • main: selected = <scratch>\working\java.exe
    • this PR: selected = <scratch>\selected-jdk\bin\java.exe
  • Remaining proof gaps: the java.exe files were empty placeholders. Only configuration-input resolution was run; no JDK probe, engine JAR, APK or JADX session.

For evidence-bearing changes:

  • Observed, derived, and inferred claims remain distinguishable.
  • Artifact identity, source provenance, and failed attempts remain preserved.
  • Unsupported, incomplete, unavailable, or uncertain outcomes remain visible.

Validation performed

  • npx vitest run --project boundary tests/boundary/android/jadxConfiguration.test.ts: the new test passes on Windows (the other 16 skip on Windows by design).
  • npx vitest run tests/boundary/android <jadx process-boundary tests>: 38 passed, 133 skipped (POSIX-only), 2 failed. The 2 failures are in tests/boundary/process/jadxHashCleanup.test.ts, which does not use the changed module, and fail identically on unmodified main on this host.
  • npm run check:fast: typecheck and lint passed (also in the pre-push hook).
  • Real Windows before/after selection check described above.

Not run: npm run check, npm run check:pr, npm run verify:android, and any JADX engine or APK workflow.

Compatibility, safety, and release

  • Breaking changes or migration steps: none intended. A Windows setup that depended on an unlisted working-directory java.exe must now set JAVA_HOME or add that directory to PATH, which is what the docs already said.
  • Real Hopper/Ghidra, browser, or OS coverage: Windows 11 x64 only, configuration resolution only.
  • Package or release metadata impact: none.
  • Security, privacy, process, or containment review: removes an implicit executable search location; no new execution path.

Review checklist

  • This PR addresses a concrete problem or an agreed enhancement.
  • The PR has one focused outcome and the title follows type(scope): outcome.
  • Related issue is linked, or the reason for not linking one is stated above.
  • Tests cover changed observable behavior and meaningful failure paths.
  • Owning docs, contracts, and generated metadata are updated where needed.
  • User-visible CLI/MCP changes include representative output.
  • I checked the final diff for secrets, unrelated cleanup, and unsupported claims.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/5204 **Author:** [@ranmori](https://github.com/ranmori) **Created:** 10/19/2026 **Status:** ❌ Closed **Base:** `main` ← **Head:** `fix/jadx-windows-path-java` --- ### 📝 Commits (2) - [`0b92dc4`](https://github.com/morluto/rea/commit/0b92dc4133b4cbbb947b81a7b329d005f55c69c4) fix(android): select Windows JADX java.exe from PATH, not the working directory - [`0c599b9`](https://github.com/morluto/rea/commit/0c599b9bb5e3af0394b8817206f30af555742b86) Merge branch 'main' into fix/jadx-windows-path-java ### 📊 Changes **2 files changed** (+74 additions, -29 deletions) <details> <summary>View changed files</summary> 📝 `src/android/JadxConfiguration.ts` (+44 -28) 📝 `tests/boundary/android/jadxConfiguration.test.ts` (+30 -1) </details> ### 📄 Description ## Summary Fixes #5096. With `JAVA_HOME` absent, Windows JADX configuration searched the process working directory before the selected `PATH`. A stray `java.exe` there therefore won over the JDK the caller selected, even when that directory was not on `PATH`. This PR searches only the `PATH` entries, as [docs/android-analysis.md](https://github.com/morluto/rea/blob/main/docs/android-analysis.md) already describes ("resolves `java.exe` on the selected Windows `PATH`"). The issue was source-only; this PR adds a native Windows reproduction of the bug and of the fix. ## Problem and expected behaviora Trigger: Windows x64, `JAVA_HOME` unset, a `java.exe` in the process working directory, and a different JDK selected through `PATH`. - Before: `resolveJava` iterated `[process.cwd(), ...PATH entries]` and returned the first readable `java.exe`, so the working-directory file was probed and used for the engine session. - A second route to the same result: an empty `PATH` entry, such as the trailing `;` common in real Windows `PATH` values, resolved through `resolve("", "java.exe")` to the working directory as well. - After: only non-empty `PATH` entries are searched, in order. A caller who lists the working directory (for example `.`) still selects it, and an absolute `JAVA_HOME` still takes precedence. ## Change and scope - The Windows `PATH` search moves out of `resolveJava` into an exported `findWindowsPathJava(path, signal)` in `src/android/JadxConfiguration.ts`. It drops the `process.cwd()` candidate and skips empty entries. Quote stripping, the readable/executable/regular-file checks, canonicalization, and the `runtime_missing` failure for an uninspectable candidate are unchanged. - `resolveJava` calls it and keeps its existing "Cannot find java.exe on the selected Windows PATH" failure when nothing is found. Not included: the non-Windows path (`java` resolved by the spawn) and `JAVA_HOME` handling are untouched. There is no fallback to another `PATH` JDK when the first one later fails validation; the issue mentions that only as a consequence of the working-directory selection. ## Contract and boundary impact - Semantic owner and earliest changed stage: `src/android/JadxConfiguration.ts`, Java selection during JADX configuration. - CLI and MCP/tool-catalog contract: none. - Provider, bridge, target-format, or platform compatibility: Windows x64 JADX only. Hosts that relied on a working-directory `java.exe` with no `JAVA_HOME` and no matching `PATH` entry now get the existing `runtime_missing` failure with its `JAVA_HOME`/`PATH` guidance. - Evidence, artifact, provenance, or reconstruction contract: none. - Process execution, authorization, cleanup, or containment impact: the selected Java executable can only come from `JAVA_HOME` or a caller-listed `PATH` entry. - Generated metadata, package, or installation impact: none. The existing docs already describe the new behavior. ## Evidence and regression coverage - Tests added: `selects java.exe from the Windows PATH, not the working directory` in `tests/boundary/android/jadxConfiguration.test.ts`. It runs on every platform, unlike the rest of that file, which skips on Windows. It changes into a temporary working directory containing `java.exe`, then checks that: - a `PATH` with leading and trailing empty entries selects the `PATH` JDK; - a quoted entry selects the `PATH` JDK; - a `PATH` of only a separator selects nothing; - a `PATH` listing `.` selects the working-directory file. - Base reproduction, executed on Windows 11 x64 (build 26200), Node 24.13.0, base `ba866a26`, with the published `rea-agents@6.7.0` Windows native addon. I called `resolveJadxConfigurationInputs` from each build's compiled `dist` with `REA_JADX_MCP_JAR` set, `JAVA_HOME` unset, `PATH=<scratch>\selected-jdk\bin;%SystemRoot%\System32;`, and the working directory set to `<scratch>\working`: - main: `selected` = `<scratch>\working\java.exe` - this PR: `selected` = `<scratch>\selected-jdk\bin\java.exe` - Remaining proof gaps: the `java.exe` files were empty placeholders. Only configuration-input resolution was run; no JDK probe, engine JAR, APK or JADX session. For evidence-bearing changes: - [x] Observed, derived, and inferred claims remain distinguishable. - [x] Artifact identity, source provenance, and failed attempts remain preserved. - [x] Unsupported, incomplete, unavailable, or uncertain outcomes remain visible. ## Validation performed - `npx vitest run --project boundary tests/boundary/android/jadxConfiguration.test.ts`: the new test passes on Windows (the other 16 skip on Windows by design). - `npx vitest run tests/boundary/android <jadx process-boundary tests>`: 38 passed, 133 skipped (POSIX-only), 2 failed. The 2 failures are in `tests/boundary/process/jadxHashCleanup.test.ts`, which does not use the changed module, and fail identically on unmodified main on this host. - `npm run check:fast`: typecheck and lint passed (also in the pre-push hook). - Real Windows before/after selection check described above. Not run: `npm run check`, `npm run check:pr`, `npm run verify:android`, and any JADX engine or APK workflow. ## Compatibility, safety, and release - Breaking changes or migration steps: none intended. A Windows setup that depended on an unlisted working-directory `java.exe` must now set `JAVA_HOME` or add that directory to `PATH`, which is what the docs already said. - Real Hopper/Ghidra, browser, or OS coverage: Windows 11 x64 only, configuration resolution only. - Package or release metadata impact: none. - Security, privacy, process, or containment review: removes an implicit executable search location; no new execution path. ## Review checklist - [x] This PR addresses a concrete problem or an agreed enhancement. - [x] The PR has one focused outcome and the title follows `type(scope): outcome`. - [x] Related issue is linked, or the reason for not linking one is stated above. - [x] Tests cover changed observable behavior and meaningful failure paths. - [x] Owning docs, contracts, and generated metadata are updated where needed. - [x] User-visible CLI/MCP changes include representative output. - [x] I checked the final diff for secrets, unrelated cleanup, and unsupported claims. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
bsakaguchi 2026-11-01 21:43:12 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
morluto/rea#6810
No description provided.