[PR #742] [MERGED] fix(android): validate explicit Java runtime #2208

Closed
opened 2026-10-16 21:15:41 +00:00 by bsakaguchi · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/742
Author: @kaoru0822-kitauji
Created: 10/6/2026
Status: ✅ Merged
Merged: 10/6/2026
Merged by: @morluto

Base: main ← Head: fix/jadx-java-home-validation


📝 Commits (1)

  • bd2d8cc fix(android): validate explicit Java runtime

📊 Changes

2 files changed (+61 additions, -7 deletions)

View changed files

📝 src/android/JadxConfiguration.ts (+17 -7)
➕ tests/boundary/android/jadxConfiguration.test.ts (+44 -0)

📄 Description

Summary

  • reject an explicit JAVA_HOME whose bin/java is missing, non-executable, or not a regular file
  • report the exact unusable Java path as a capability/configuration failure before launching JADX
  • preserve the existing java-on-PATH behavior when JAVA_HOME is omitted

No separate issue: this is a reproduced configuration-admission gap in the newly added Android provider.

Problem and evidence

The Android setup guide says that optional JAVA_HOME selects an existing JDK, and the resolver's own error text promises the same. On current main, however, any absolute JAVA_HOME is accepted without inspecting bin/java.

The regression creates a readable fixture JAR and supplies an absolute nonexistent JDK directory. Before the fix, resolveJadxConfiguration resolves successfully with the nonexistent command path. That defers the failure to process acquisition, after workspace/JAR snapshot work, and reports it as an adapter failure instead of a missing capability.

Change and scope

When JAVA_HOME is explicit, verify that JAVA_HOME/bin/java is readable, executable, and a regular file before returning the launch configuration. The configured path is retained unchanged. JAR validation and canonicalization are unchanged, and an omitted JAVA_HOME still returns the bare java command for normal PATH resolution.

No tool schema, result, catalog, installation, target, process-ownership, or cleanup contract changes.

Validation

Passed:

  • direct focused Vitest run for tests/boundary/android/jadxConfiguration.test.ts (2 tests)
  • npm exec --package=typescript@5.9.3 -- tsc --noEmit
  • npm run lint
  • npm run knip
  • npm run metadata:check
  • targeted oxfmt --check
  • git diff --check

Baseline evidence:

  • the same focused regression on unchanged main failed because the missing Java path resolved successfully

Materially unverified locally:

  • npm run test:focused and npm run check cannot build because the repository TypeScript 7 binary panics while resolving /proc/self/exe in this sandbox
  • the broader Android integration suite cannot verify owned-process cleanup because this sandbox has no mounted /proc
  • no real Java/JADX provider workflow was run; hosted CI covers the deterministic boundary and package lanes

🔄 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/742 **Author:** [@kaoru0822-kitauji](https://github.com/kaoru0822-kitauji) **Created:** 10/6/2026 **Status:** ✅ Merged **Merged:** 10/6/2026 **Merged by:** [@morluto](https://github.com/morluto) **Base:** `main` ← **Head:** `fix/jadx-java-home-validation` --- ### 📝 Commits (1) - [`bd2d8cc`](https://github.com/morluto/rea/commit/bd2d8cc926662f4b5bc8846ff5333eea6fdbe6bd) fix(android): validate explicit Java runtime ### 📊 Changes **2 files changed** (+61 additions, -7 deletions) <details> <summary>View changed files</summary> 📝 `src/android/JadxConfiguration.ts` (+17 -7) ➕ `tests/boundary/android/jadxConfiguration.test.ts` (+44 -0) </details> ### 📄 Description ## Summary - reject an explicit `JAVA_HOME` whose `bin/java` is missing, non-executable, or not a regular file - report the exact unusable Java path as a capability/configuration failure before launching JADX - preserve the existing `java`-on-`PATH` behavior when `JAVA_HOME` is omitted No separate issue: this is a reproduced configuration-admission gap in the newly added Android provider. ## Problem and evidence The Android setup guide says that optional `JAVA_HOME` selects an existing JDK, and the resolver's own error text promises the same. On current `main`, however, any absolute `JAVA_HOME` is accepted without inspecting `bin/java`. The regression creates a readable fixture JAR and supplies an absolute nonexistent JDK directory. Before the fix, `resolveJadxConfiguration` resolves successfully with the nonexistent command path. That defers the failure to process acquisition, after workspace/JAR snapshot work, and reports it as an adapter failure instead of a missing capability. ## Change and scope When `JAVA_HOME` is explicit, verify that `JAVA_HOME/bin/java` is readable, executable, and a regular file before returning the launch configuration. The configured path is retained unchanged. JAR validation and canonicalization are unchanged, and an omitted `JAVA_HOME` still returns the bare `java` command for normal PATH resolution. No tool schema, result, catalog, installation, target, process-ownership, or cleanup contract changes. ## Validation Passed: - direct focused Vitest run for `tests/boundary/android/jadxConfiguration.test.ts` (2 tests) - `npm exec --package=typescript@5.9.3 -- tsc --noEmit` - `npm run lint` - `npm run knip` - `npm run metadata:check` - targeted `oxfmt --check` - `git diff --check` Baseline evidence: - the same focused regression on unchanged `main` failed because the missing Java path resolved successfully Materially unverified locally: - `npm run test:focused` and `npm run check` cannot build because the repository TypeScript 7 binary panics while resolving `/proc/self/exe` in this sandbox - the broader Android integration suite cannot verify owned-process cleanup because this sandbox has no mounted `/proc` - no real Java/JADX provider workflow was run; hosted CI covers the deterministic boundary and package lanes --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
bsakaguchi 2026-10-16 21:15:41 +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#2208
No description provided.