Support pure JVM JAR compilation and packaging for desktop JVM

[RanjithRagavan]

This PR adds support for compiling and packaging the ExecuTorch Java/Kotlin APIs as a standard JVM JAR package targeting desktop platforms (Linux, macOS, Windows). It resolves #16422 by decoupling the codebase from Android-specific APIs (using reflection to delegate android logging) and adding a new :executorch_jvm Gradle project. In addition, the JNI CMake configuration has been expanded to support building on desktop hosts.

cc @kirklandsign @cbilgin

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/20761

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

⚠️ 21 Awaiting Approval

As of commit 17b9ad5 with merge base 80a07e6 ():

AWAITING APPROVAL - The following workflows need approval before CI can run:

• Build Aarch64 Linux CUDA Wheels (gh)
• Build Aarch64 Linux Wheels (gh)
• Build documentation (gh)
• Build Linux CUDA Wheels (gh)
• Build Linux Wheels (gh)
• Build macOS Wheels (gh)
• Build Presets (gh)
• Build Windows Wheels (gh)
• Cadence Build & Test (gh)
• Lint (gh)
• periodic (gh)
• pull (gh)
• Test ARM Backend (gh)
• Test CoreML Backend (gh)
• Test Cortex-M Backend (gh)
• Test NXP Backend (gh)
• Test QNN Backend (gh)
• Test QNN Windows MSVC build (gh)
• Test Vulkan Backend (gh)
• Test WebGPU Backend (gh)
• Test XNNPACK Backend (gh)

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[RanjithRagavan]

@pytorchbot label "release notes: none"

[nil-is-all]

Hi @RanjithRagavan, thank you for the PR. Could you address the CI failures?

[psiddh]

Thanks @RanjithRagavan for the PR. The idea is strong and imo worth pursuing — a pure-JVM ExecuTorch artifact for desktop (Linux/macOS/Windows) is good in terms of direction This requires a bit of a redesign before it's mergeable, so let me lay out my thoughts rather than line-by-line comments.

1. Don't nest desktop-JVM under android: A desktop module living in extension/android/ and compiling executorch_android's source tree byrelative path (srcDirs = ['../executorch_android/...']) couples the two platforms and gives no compile boundary — which is why android.util.Log leaks into the JVM build. Extract the platform-neutral API into a shared module, and make android and jvm thin sibling modules that depend on it:

extension/
├── jni/ shared C++ JNI + CMake
├── java/ shared, platform-neutral API (no android.* — enforced by classpath)
├── android/ Android-only: AAR, AndroidLogger, jniLibs
└── jvm/ Desktop-only: jar, ConsoleLogger, per-OS native packaging

2. Replace reflection-based logging with a Logger interface (AndroidLogger / ConsoleLogger), selected per module — compile-checked and testable, avoids the partial Log shim.

3. Solve native-library delivery — this is the core gap. A pure JVM jar with no native binary will UnsatisfiedLinkError on first use. The standard pattern is an API jar + per-platform native jars (Maven classifiers: linux-x86_64, macos-aarch64, windows-x86_64…) with a loader that extracts and loads the right .so/.dylib/.dll at runtime.

4. Sequence it to keep Android safe. To keep the existing executorch-android artifact safe, I'd suggest doing the shared-module extraction as a separate, behavior-preserving refactor first (Android depends on it, package names unchanged, existing Android CI green, AAR diffed before/after), then adding the JVM module on top. That way desktop support never risks the shipping Android build.

5. CI, tests, and docs — Changes needed to go along with the PR review

Happy to help scope the shared-module split and the native-packaging approach. IMO this is a valuable addition and worth getting the foundation right. 🙏

[psiddh]

Please take a look at the feedback

[RanjithRagavan]

valuable feedbacks.. Will work on it.

[RanjithRagavan]

1. Extracted Shared Platform-Neutral Java API

Extracted the platform-neutral Java API into a shared module and converted the Android and JVM modules into thin sibling shells:

           +-------------------------------------------------------+
           |                    extension/java/                    |
           |             (Shared platform-neutral API)             |
           |             -----------------------------             |
           |             - DType, EValue, Module, Tensor           |
           |             - Log singleton & Logger SPI              |
           +-------------------------------------------------------+
                                ^             ^
                                |             |
      depends on (api project)  |             |  depends on (api project)
                                |             |
  +-----------------------------------+     +-----------------------------------+
  |        extension/android/         |     |          extension/jvm/           |
  |     (Android-specific shell)      |     |      (JVM Desktop-specific)       |
  |     ------------------------      |     |      ----------------------       |
  |     - AndroidLogger               |     |      - ConsoleLogger              |
  |     - fbjni AAR packing           |     |      - JvmNativeLoaderDelegate    |
  |     - jniLibs (.so package)       |     |      - NativeLibraryLoader        |
  +-----------------------------------+     +-----------------------------------+

• Platform-neutral Kotlin API source files are now under extension/java/. No relative srcDirs are used anymore.
• We verified that zero android.* imports exist in the shared module (extension/java).

2. Replace Reflection-Based Logging with a Logger Interface

We introduced the Logger interface and a Log facade in the shared module. Log calls dynamically resolve the provider using java.util.ServiceLoader (with a built-in fallback to console if none is found on the classpath):

ExecuTorch Classes (Shared Java Module)
             │
             ▼  (calls Log.d/i/w/e)
     Log facade (SPI)
             │
             ▼  (discovers Logger provider on classpath)
  ┌───────────────────────────┴───────────────────────────┐
  ▼                                                       ▼
AndroidLogger (extension/android)               ConsoleLogger (extension/jvm)
  │                                                       │
  ▼                                                       ▼
android.util.Log                                System.err / System.out

• Registered AndroidLogger via ServiceLoader inside the executorch_android module.
• Registered ConsoleLogger via ServiceLoader inside the executorch_jvm module.

3. Solve Native Library Delivery on JVM Desktop

• We created NativeLibraryLoader in the JVM module to handle unpacking native libraries from classpath resources (/native/<os>/<arch>/...) and loading them dynamically.
• We implemented JvmNativeLoaderDelegate to intercept library-load requests. When ExecuTorchRuntime or other classes call NativeLoader.loadLibrary("executorch"), it intercepts and maps them to "executorch_jni", which loads the self-contained JNI library (libexecutorch_jni.so/.dylib/.dll) using NativeLibraryLoader.
• Registered JvmNativeLoaderDelegate via ServiceLoader, which allows the JVM module to dynamically hook into and handle all library loads on desktop platforms cleanly without Android needing to know:

Module / ExecuTorchRuntime (extension/java)
                 │
                 ▼  (calls NativeLoader.loadLibrary("executorch"))
        NativeLoader facade
                 │
                 ▼  (discovers JvmNativeLoaderDelegate via ServiceLoader)
    JvmNativeLoaderDelegate (extension/jvm)
                 │
                 ▼  (maps request for "executorch" to "executorch_jni")
      NativeLibraryLoader (extension/jvm)
                 │
                 ▼  (detects OS/arch and extracts binary from classpath)
Classpath: /native/macos/aarch64/libexecutorch_jni.dylib  ──►  Temp Directory
                                                                      │
                                                                      ▼ (System.load())
                                                              Loaded Native C++ Layer

4. Tests and Verification

• Relocated EValueTest.kt and TensorTest.kt to the shared extension/java module where they run directly on the host JVM. This makes running tests incredibly fast and allows them to be executed in desktop JVM CI flows without requiring an emulator.
• Verified all compiles and runs green on JDK 17 (Android debug/release AARs, Shared API jar, and Desktop JVM jar).

[psiddh]

This is a good redesign.

I want to be clear about the bar this change has to clear, though. ExecuTorch Android is a foundational, widely-deployed dependency in production, so the Android path must not regress. Before we can consider next steps this will need thorough vetting and careful consideration, internal integration validation, a release-shrunk consumer build, and an AAR before/after diff proving the shipping artifact is unchanged. Please bear with a slower, more careful review than usual; it's a reflection of the surface area and potential blast radius, not the quality of the work.

Thanks for the collaboration! I'll summarize the next steps.

[RanjithRagavan]

Rearchitected ExecuTorch JVM Support — Zero Android Path Regression

Thanks for the feedback @psiddh! Based on your guidance regarding ExecuTorch Android's foundational status in production, this change has been re-architected to guarantee that the Android build path, shipping AAR artifact, and runtime performance do not regress in any way.

---

Key Architectural Decisions

1. Zero Source Relocation: All Android Java/Kotlin source files (Tensor.kt, Module.kt, ExecuTorchRuntime.kt, EValue.kt, LlmModule.kt, DType.kt, etc.) remain in their original location under extension/android/executorch_android/src/main/java/org/pytorch/executorch/. FB internal Buck targets and directory layouts remain 100% untouched.
2. Zero Logging Reflection/SPI Penalty: Log.kt on Android calls android.util.Log directly and statically. ServiceLoader runtime SPI lookups have been removed to preserve R8/ProGuard inlineability.
3. No Intermediate :executorch_java Dependency: executorch_android remains a standalone AAR library with zero external Java module dependencies.
4. Desktop JVM via Gradle sourceSets: Desktop JVM support (executorch_jvm in extension/jvm/) compiles a standalone desktop .jar for Linux, macOS, and Windows by linking to the shared Kotlin source files in extension/android/... at compile time, providing a console Log.kt override for desktop platforms.

---

Architecture Diagram

graph TD
    subgraph "Source Files"
        A["extension/android/executorch_android/src/main/java/<br/>(Tensor.kt, Module.kt, EValue.kt, LlmModule.kt, etc.)"]
        B["Android Log.kt<br/>(android.util.Log static call)"]
        C["JVM Log.kt & NativeLibraryLoader.kt<br/>(Console logging & OS native library unpacker)"]
    end

    subgraph "Gradle Build Targets"
        A --> |Direct Sources| D[":executorch_android (.aar)"]
        B --> |Direct Android Log| D
        
        A --> |Shared sourceSets.main| E[":executorch_jvm (.jar)"]
        C --> |Desktop Overrides| E
    end

    subgraph "Shipping Artifacts"
        D --> F["Android Production Artifact<br/>(executorch-android.aar)"]
        E --> G["Desktop JVM Artifact<br/>(executorch-jvm.jar)"]
    end

Loading

[RanjithRagavan]

@psiddh Redesign implemented per your feedback — pushed as 438dce3. Point-by-point:

1. Shared platform-neutral module extracted ✅

New extension/java/ module (published as org.pytorch:executorch-java) now holds all platform-neutral API classes (Module, Tensor, EValue, DType, LlmModule, AsrModule, training, …), moved with git mv so blame/history is preserved. Android and JVM are thin siblings:

extension/
├── jni/        shared C++ JNI + CMake (unchanged location; non-Android host branch added)
├── java/       shared, platform-neutral API — no android.* (enforced by classpath:
│               JDK + fbjni-java-only + soloader only; any android.* import fails compilation)
├── android/    Android-only: AAR, AndroidLogger, init provider, jniLibs
└── jvm/        Desktop-only: jar, ExecuTorchJvm.init(), per-OS native packaging

• No relative srcDirs cross-compilation anymore — both siblings declare api project(':executorch_java').
• Package names unchanged (org.pytorch.executorch.*), so existing imports in consumer code keep working; Android consumers resolve executorch-java transitively from the AAR's POM.

2. Logger interface, no reflection ✅

• Shared module defines a Logger interface and an internal Log facade with a ConsoleLogger default.
• Android installs AndroidLogger (backed by android.util.Log, so logcat behavior is unchanged) at process start via a small ExecuTorchInitProvider ContentProvider — the androidx-Startup/Firebase mechanism, no reflection, no ServiceLoader.
• Desktop uses ConsoleLogger by default.
• All compile-checked and testable: new LoggerTest runs in the shared module's unit tests.

The ServiceLoader lookup that was in ExecuTorchRuntime is removed — the Android runtime init is back to NativeLoader.init(SystemDelegate()) + loadLibrary("executorch") exactly as before. (Correction to my earlier comment, which had claimed this while the diff said otherwise.)

3. Native-library delivery ✅ (mechanism)

Standard API-jar + per-platform-native-jars pattern:

org.pytorch:executorch-jvm:<version>                  (API jar)
org.pytorch:executorch-jvm:<version>:linux-x86_64     (classified native jars)
org.pytorch:executorch-jvm:<version>:macos-aarch64
… (linux/macos/windows × x86_64/aarch64)

• jarNative* Gradle tasks package binaries staged under extension/cmake-out-jvm/<classifier>/ (built with the non-Android branch of extension/android/CMakeLists.txt) into native/<os>/<arch>/ inside the classified jars, and attach them to the Maven publication. Verified locally with a staged binary.
• NativeLibraryLoader extracts the right .so/.dylib/.dll from the classpath at runtime.
• Desktop entry point is explicit and compile-checked: ExecuTorchJvm.init() before first use (documented in extension/jvm/README.md).

4. Android safety ✅ (with two honest caveats)

• Android runtime behavior preserved: same native loader delegate, same library name, same logcat logging, same package names. The duplicated native-loading blocks in Module/TrainingModule/SGD/AsrModule now funnel through ExecuTorchRuntime.ensureNativeLibraryLoaded() with the Android defaults.
• Verified locally: :executorch_java and :executorch_jvm build cleanly, spotless/ktfmt passes, and 63 unit tests (EValue, Tensor, Logger) pass on the desktop JVM. The Android module itself needs CI (no Android SDK on my machine).

Caveats I want to be upfront about:

1. Java 17 bytecode is forced: fbjni-java-only:0.7.0 publishes Gradle metadata requiring JVM 17+, so the shared module — and therefore the Android module consuming it — must target 17. This is why the earlier revision bumped compileOptions 11→17; it's a dependency requirement, not gratuitous. D8/AGP 8.9 handles Java 17 bytecode, minSdk 23 unaffected.
2. extension/android/BUCK had to change since sources moved: the Buck targets keep their historical names and re-export new //xplat/executorch/extension/java targets, but the internal mirror needs your validation — I can't build Buck externally.
3. AAR diff: the AAR no longer embeds the API classes (they arrive transitively from executorch-java, published alongside) and gains one init-provider manifest entry. Happy to produce a before/after AAR diff once CI artifacts are available, or to split the shared-module extraction into a separate behavior-preserving PR first if you'd prefer that sequencing.
4. Per-OS native binaries still need a CI matrix job to actually build them — the packaging/publishing/loading mechanism is in place and tested; the binaries themselves are CI work.

Would appreciate another look when you have time. Thanks for the detailed direction — the codebase is much cleaner this way.

[psiddh]

@psiddh Redesign implemented per your feedback — pushed as 438dce3. Point-by-point:

1. Shared platform-neutral module extracted ✅

New extension/java/ module (published as org.pytorch:executorch-java) now holds all platform-neutral API classes (Module, Tensor, EValue, DType, LlmModule, AsrModule, training, …), moved with git mv so blame/history is preserved. Android and JVM are thin siblings:

extension/
├── jni/        shared C++ JNI + CMake (unchanged location; non-Android host branch added)
├── java/       shared, platform-neutral API — no android.* (enforced by classpath:
│               JDK + fbjni-java-only + soloader only; any android.* import fails compilation)
├── android/    Android-only: AAR, AndroidLogger, init provider, jniLibs
└── jvm/        Desktop-only: jar, ExecuTorchJvm.init(), per-OS native packaging

• No relative srcDirs cross-compilation anymore — both siblings declare api project(':executorch_java').
• Package names unchanged (org.pytorch.executorch.*), so existing imports in consumer code keep working; Android consumers resolve executorch-java transitively from the AAR's POM.

2. Logger interface, no reflection ✅

• Shared module defines a Logger interface and an internal Log facade with a ConsoleLogger default.
• Android installs AndroidLogger (backed by android.util.Log, so logcat behavior is unchanged) at process start via a small ExecuTorchInitProvider ContentProvider — the androidx-Startup/Firebase mechanism, no reflection, no ServiceLoader.
• Desktop uses ConsoleLogger by default.
• All compile-checked and testable: new LoggerTest runs in the shared module's unit tests.

The ServiceLoader lookup that was in ExecuTorchRuntime is removed — the Android runtime init is back to NativeLoader.init(SystemDelegate()) + loadLibrary("executorch") exactly as before. (Correction to my earlier comment, which had claimed this while the diff said otherwise.)

3. Native-library delivery ✅ (mechanism)

Standard API-jar + per-platform-native-jars pattern:

org.pytorch:executorch-jvm:<version>                  (API jar)
org.pytorch:executorch-jvm:<version>:linux-x86_64     (classified native jars)
org.pytorch:executorch-jvm:<version>:macos-aarch64
… (linux/macos/windows × x86_64/aarch64)

• jarNative* Gradle tasks package binaries staged under extension/cmake-out-jvm/<classifier>/ (built with the non-Android branch of extension/android/CMakeLists.txt) into native/<os>/<arch>/ inside the classified jars, and attach them to the Maven publication. Verified locally with a staged binary.
• NativeLibraryLoader extracts the right .so/.dylib/.dll from the classpath at runtime.
• Desktop entry point is explicit and compile-checked: ExecuTorchJvm.init() before first use (documented in extension/jvm/README.md).

4. Android safety ✅ (with two honest caveats)

• Android runtime behavior preserved: same native loader delegate, same library name, same logcat logging, same package names. The duplicated native-loading blocks in Module/TrainingModule/SGD/AsrModule now funnel through ExecuTorchRuntime.ensureNativeLibraryLoaded() with the Android defaults.
• Verified locally: :executorch_java and :executorch_jvm build cleanly, spotless/ktfmt passes, and 63 unit tests (EValue, Tensor, Logger) pass on the desktop JVM. The Android module itself needs CI (no Android SDK on my machine).

Caveats I want to be upfront about:

1. Java 17 bytecode is forced: fbjni-java-only:0.7.0 publishes Gradle metadata requiring JVM 17+, so the shared module — and therefore the Android module consuming it — must target 17. This is why the earlier revision bumped compileOptions 11→17; it's a dependency requirement, not gratuitous. D8/AGP 8.9 handles Java 17 bytecode, minSdk 23 unaffected.
2. extension/android/BUCK had to change since sources moved: the Buck targets keep their historical names and re-export new //xplat/executorch/extension/java targets, but the internal mirror needs your validation — I can't build Buck externally.
3. AAR diff: the AAR no longer embeds the API classes (they arrive transitively from executorch-java, published alongside) and gains one init-provider manifest entry. Happy to produce a before/after AAR diff once CI artifacts are available, or to split the shared-module extraction into a separate behavior-preserving PR first if you'd prefer that sequencing.
4. Per-OS native binaries still need a CI matrix job to actually build them — the packaging/publishing/loading mechanism is in place and tested; the binaries themselves are CI work.

Would appreciate another look when you have time. Thanks for the detailed direction — the codebase is much cleaner this way.

I will look into it this week and get back, Thanks again for all the great work and contribution

[psiddh]

@claude Please review the design of this PR and read all existing comments
and diagrams for context. The primary concern is Android regression risk
because changes to the shipping AAR or Buck targets could affect Android apps.

What do you think of this alternative design?

Share platform-neutral sources without making Android depend on a new untime JAR:

java-common sources
├── compiled directly into the existing self-contained Android AAR
│ + Android logging/native-loading implementation
└── compiled directly into the desktop JVM JAR
+ JVM logging/native-loading implementation

Android may reference the shared source location, but its existing artifact
and runtime contract should remain unchanged:

• Self-contained Android AAR
• Java 11 bytecode
• Exactly one Android FBJNI dependency
• Existing logging and native-loading behavior
• No new manifest provider
• Existing Buck target ownership and attributes
• No mutable cross-platform native-loader configuration

Desktop JNI should have its own build boundary, preferably self-contained
FBJNI linkage, platform-correct linker settings, secure native extraction,
and real Linux/macOS/Windows runtime tests.

Suggested sequencing / Ownership:

1. Shared-source extraction:

   • @RanjithRagavan : AAR parity and standalone-AAR tests for all variants.
   • @psiddh : internal Buck/FoA validation.

2. Desktop JVM implementation:

   • @RanjithRagavan owns implementation and clean-process JNI tests.

3. Native classifier publication:

   • @RanjithRagavan owns packaging and Maven-local consumer tests.
   • @psiddh assist with release infrastructure/credentials if needed.

4. Final regression gates:

   • @RanjithRagavan provides OSS R8 and dependency-graph evidence.
   • @psiddh own internal FoA validation and final Android parity sign-off.

[claude]

Claude finished @psiddh's task in 3m 24s —— View job

---

Design review: shared-source vs. shared-runtime-JAR

• Read all PR comments and diagrams for context
• Examine the current PR diff (shared module, logging, native loader, Buck, CMake)
• Compare current design vs. the proposed "shared-source, no runtime JAR" design
• Assess Android regression risk
• Provide a recommendation

---

Verdict: I agree with your alternative. Share sources, not a runtime artifact. The current PR is well-executed and much cleaner as OSS module topology, but it converts four separate properties of the shipping Android contract into changes, and each one is an independent regression vector. Source-sharing gives you the desktop artifact while keeping the AAR byte-close to what ships today. Below I map each of your constraints to the concrete thing in the current diff it would revert, then flag one actual bug I found while reading.

Where the current design touches the Android shipping contract

1. AAR is no longer self-contained. extension/android/executorch_android/build.gradle:64 declares api project(':executorch_java'), and the API classes (Module, Tensor, EValue, LlmModule, …) now live in the separate org.pytorch:executorch-java artifact. The AAR gains a transitive POM dependency and loses the classes it used to embed. That is exactly the artifact whose before/after diff you want to be empty, and it won't be. Any consumer (internal or OSS) that assumes a self-contained AAR — shading, non-standard transitive resolution, offline mirrors — is exposed. Source-sharing keeps the classes compiled into the AAR → the diff stays near-empty.

2. Java 11 → 17 is forced. executorch_android/build.gradle:38-39 bumps compileOptions to 17, and extension/java/build.gradle:33-35 documents why: fbjni-java-only:0.7.0's Gradle metadata requires JVM 17+, and the AAR inherits it by consuming that module. Sharing sources instead lets the AAR keep compiling against regular fbjni (not fbjni-java-only) and stay at Java 11 bytecode. This is the cleanest illustration of the coupling: the desktop dependency's toolchain requirement should not reach the Android artifact.

3. A new manifest <provider> runs in every consuming app. AndroidManifest.xml:4-7 registers ExecuTorchInitProvider, whose only job (ExecuTorchInitProvider.kt:24-27) is Log.install(AndroidLogger()) at process start. This merges into every downstream app's manifest and adds process-startup work. With source-sharing, Android compiles a Log that calls android.util.Log directly and statically — no provider, no install step, no manifest-merger entry, and it preserves the R8/ProGuard inlineability you called out earlier.

4. A mutable cross-platform native-loader global is introduced into the shipping path. ExecuTorchRuntime.configureNativeLoading (extension/java/.../ExecuTorchRuntime.kt:49-58) is a @Volatile var delegate + library-name pair shared by both platforms. On Android it's dead weight, but it adds a mutable global and an ordering contract to the foundational runtime. Your "no mutable cross-platform native-loader configuration" constraint removes it: each artifact compiles its own loading strategy.

On Buck (constraint: unchanged ownership/attributes): sources moved to //xplat/executorch/extension/java and the Android targets now exported_deps them (extension/android/BUCK:22-24). Historical names are preserved, but the ABI/dep graph of //xplat/executorch/extension/android:executorch changes and needs FoA validation. Source-sharing keeps the srcs list on the Android target (pointing at the shared source dir), so target ownership and attributes like required_for_source_only_abi / pure_kotlin stay put.

Bug in the current desktop path (independent of which design you pick)

ExecuTorchJvm.init() cannot satisfy its own contract. It calls ExecuTorchRuntime.configureNativeLoading(...) "before the native library is loaded" — but the companion object's initializer eagerly loads the library:

// ExecuTorchRuntime.kt
init { ensureNativeLibraryLoaded() }   // runs on FIRST touch of the companion
...
fun configureNativeLoading(...) {
    check(!NativeLoader.isInitialized()) { "...must be called before...loaded" }  // will throw
}

Calling configureNativeLoading is itself the first access to the companion, which runs init { ensureNativeLibraryLoaded() } → NativeLoader.init(SystemDelegate()) + loadLibrary("executorch") before the delegate is swapped. On desktop that either throws UnsatisfiedLinkError (no libexecutorch on java.library.path) or, if it somehow loads, makes the subsequent check(!isInitialized()) fail. Either way the desktop entry point is broken. The eager init{} + shared mutable global is the root cause — which is another argument for compiling the loader per-artifact rather than configuring one shared runtime at runtime. Fix this →

Notes for implementing the source-sharing design cleanly

• Put the shared sources in a neutral location, not under extension/android/. That was the original objection (android.util.Log leaking in). A neutral dir (e.g. extension/java/src/main/...) that both the AAR target and the JVM jar reference by srcDir satisfies "Android may reference the shared source location" while keeping the AAR self-contained and taking no module dependency.
• Logging via per-source-set class, not an interface+install facade. Keep the shared code calling a Log facade; let the Android source set compile a Log/logger backed by android.util.Log and the JVM source set compile a console one. No Logger interface, no install(), no provider, no ServiceLoader. This is simpler than the current PR and matches "existing logging behavior unchanged."
• Watch for duplicate-class collisions when a class is provided per-platform: the shared source set must not also contain Log.kt/the native-loader, or the AAR/jar will see two definitions. Keep platform-specific files out of the shared set.
• Native extraction hardening (your "secure extraction" point): NativeLibraryLoader.load (NativeLibraryLoader.kt:74-83) extracts to a fixed tmpdir/executorch-native/<fileName> shared across processes/versions — a TOCTOU / stale-or-tampered-file hazard, and deleteOnExit won't remove a loaded .dll on Windows. Prefer a per-process unique dir (Files.createTempDirectory) and, ideally, checksum verification of the extracted binary.

On sequencing

Your 4-step plan is the right shape, and it matches the safe path you asked for on Aug 16: land the shared-source extraction as a standalone, behavior-preserving refactor first (AAR-diff empty, all Android variants' standalone-AAR tests green, internal Buck/FoA validated), then add the JVM jar and native classifiers on top. That way desktop support never gates on, or risks, the shipping Android build. The per-OS native binaries (step 3) genuinely need a CI matrix regardless of design; the loader/packaging mechanism here is reusable once the extraction hardening above is in.

Net: the alternative is the lower-risk design and I'd recommend adopting it. Happy to look again once the shared-source version is up.

[psiddh]

@RanjithRagavan Thank you for the thoughtful redesigns, responsiveness to feedback, and the substantial time you’ve invested here. Desktop JVM support is valuable, and I appreciate your continued collaboration in getting the foundation and Android safety bar right. I’m happy to own the internal Buck/FoA validation and final parity checks while you drive the OSS implementation and testing.

Please let me know your thoughts

[RanjithRagavan]

@psiddh Thank you — I agree with the shared-source design, and with the sequencing. It's strictly lower-risk for Android and still delivers the full desktop artifact, so let's go with it.
Concretely, here's my understanding of what I'll implement:

1. — shared-source extraction (behavior-preserving, standalone PR):

• Move the platform-neutral sources to a neutral location (e.g. extension/java/src/main/...) referenced by srcDir from both the Android target and (later) the JVM jar — no new Gradle module dependency, no published executorch-java artifact.
• The AAR stays self-contained: same embedded classes, Java 11 bytecode, the existing single fbjni dependency, existing logcat logging and native loading, no manifest provider, no Logger interface/install step. Buck targets keep their srcs list pointing at the shared dir, so ownership and attributes (required_for_source_only_abi, pure_kotlin, …) stay put.
• Deliverables from my side: before/after AAR diff (expect near-empty) + standalone-AAR tests for all variants; Buck/FoA validation on your side as you offered.

2. desktop JVM jar on top of that: self-contained FBJNI linkage, platform-correct linker settings, and clean-process JNI tests on Linux/macOS/Windows.
3. native classifier publication with Maven-local consumer tests; will flag when release-infra/credential help is needed.
4. regression gates: OSS R8 and dependency-graph evidence from me; internal FoA validation and final parity sign-off from you.

[RanjithRagavan]

@psiddh Thank you — I agree with the shared-source design and the sequencing. Step 1 (the behavior-preserving shared-source extraction) is up for review as #22338.

A few notes on how it maps to your constraints and the @claude review:

• Android contract preserved: self-contained AAR (shared sources compiled in via java.srcDirs, no new artifact or transitive dependency), Java 11 bytecode, exactly one fbjni dependency, existing logcat logging and native loading, no manifest provider, no mutable cross-platform loader config. Verified with a before/after AAR diff — the only delta is one internal Log.class (the Android-backed facade Tensor.kt now references by simple name; R8-inlineable).
• The ExecuTorchRuntime eager-init bug the review found in the previous revision is real, and the whole class of problem disappears under this design — there is no shared mutable runtime to configure anymore. The per-source-set Log approach is implemented exactly as suggested, with the shared directory containing no Log definition, so no duplicate-class collisions.
• Local regression: 61/61 unit tests pass on both the Android module and a pure desktop JVM compile of the shared sources (no android.jar); 136 instrumentation tests on an API 34 emulator with a freshly built native lib — the only 5 failures reproduce byte-identically on unmodified main (pre-existing error-message-text skew, unrelated to this change).
• Buck: targets keep their historical names, ownership, and attributes; srcs reference the shared location. As you offered, internal Buck/FoA validation is on your side — thank you.

I opened this as a fresh PR to keep the review archaeology clean, since this branch's design differs from what's on this one. Happy to close #22338 and fold the exact same branch back into this PR if you'd rather keep everything here. Once step 1 lands, I'll follow with the desktop JVM jar (step 2) and native classifier publication (step 3) on top.

[kirklandsign]

@claude review

[claude]

Claude finished @kirklandsign's task in 2m 29s —— View job

---

Code Review — Desktop JVM support (PR #20761)

• Read PR diff & all prior comments/diagrams
• Assess Android regression risk vs. the shared-source design already agreed on
• Review desktop JVM native-loading & security
• Post review

---

First, the meta-point: the branch on this PR still contains the earlier shared-runtime-JAR design — the one where executorch_android takes api project(':executorch_java'), Java is bumped to 17, a manifest <provider> is added, and a mutable cross-platform native-loader global lives in the shipping runtime. But the thread already converged (Aug 24–31) on the shared-source design instead, and @RanjithRagavan has opened #22338 as the behavior-preserving step 1 of that plan. So most of the Android-contract concerns below are already resolved by moving to #22338 — I'm flagging them here so the record on this PR is complete and so the diff reviewed here isn't mistaken for the current direction.

If the plan holds, this branch should either be closed in favor of #22338 (+ follow-ups), or reset to the shared-source approach. The review below is against the code actually on this branch.

---

Android regression vectors still present on this branch

1. AAR is no longer self-contained. executorch_android/build.gradle:64 — api project(':executorch_java'). The API classes (Module, Tensor, EValue, LlmModule, …) leave the AAR and arrive transitively from org.pytorch:executorch-java. That makes the before/after AAR diff non-empty and exposes any consumer that assumes a self-contained AAR (shading, offline mirrors, non-standard transitive resolution). The shared-source design keeps these compiled into the AAR.

2. Java 11 → 17 forced. executorch_android/build.gradle:37-39 + extension/java/build.gradle:33-35: fbjni-java-only:0.7.0 requires JVM 17, and the AAR inherits it by consuming executorch-java. A desktop dependency's toolchain requirement should not reach the Android artifact. Source-sharing lets the AAR keep fbjni (not -java-only) at Java 11.

3. New manifest <provider> in every consuming app. AndroidManifest.xml:4-7 registers ExecuTorchInitProvider, whose sole job (ExecuTorchInitProvider.kt:24-27) is Log.install(AndroidLogger()) at process start. This merges into every downstream app and adds startup work. Per-source-set Log (Android compiles a static android.util.Log facade) removes the provider, the install step, and the manifest-merger entry — and preserves R8 inlineability.

4. Mutable cross-platform native-loader global on the shipping path. ExecuTorchRuntime.kt:26-27 — @Volatile var nativeLoaderDelegate / nativeLibraryName. Dead weight on Android and adds a mutable global + ordering contract to a foundational runtime.

Bug: ExecuTorchJvm.init() cannot satisfy its own contract (still live on this branch)

This is the same defect called out in the Aug 27 review and it is still here:

// ExecuTorchRuntime.kt
init { ensureNativeLibraryLoaded() }                 // line 30, runs on first companion touch
...
fun configureNativeLoading(delegate, libraryName) {  // line 50
  check(!NativeLoader.isInitialized()) { "...must be called before...loaded" }  // line 52
  ...
}

ExecuTorchJvm.init() (ExecuTorchJvm.kt:38) calls configureNativeLoading(...). That call is itself the first access to the companion object, so Kotlin runs the companion's init { ensureNativeLibraryLoaded() } before the method body — which does NativeLoader.init(SystemDelegate()) + loadLibrary("executorch") with the default delegate. On desktop that throws UnsatisfiedLinkError (no libexecutorch on java.library.path); even if it somehow loaded, the subsequent check(!isInitialized()) would then fail. Either way the documented desktop entry point is broken. Root cause is the eager init{} + shared mutable global — which is exactly why compiling the loader per-artifact (the shared-source design) is cleaner. Fix this →

NativeLibraryLoader — native extraction hardening (NativeLibraryLoader.kt:74-83)

Carry these into whatever JVM module lands:

• Fixed shared path is a TOCTOU / stale-binary hazard. Extraction target is tmpdir/executorch-native/<fileName>, shared across processes and versions. A different (or malicious) process can pre-create that path; a stale binary from an older version silently wins. Prefer a per-process unique dir via Files.createTempDirectory(...), and ideally verify a bundled checksum before System.load.
• deleteOnExit() won't remove a loaded .dll on Windows — the file stays mapped; cleanup is best-effort at best. Worth a comment, and the per-process dir at least avoids cross-run collisions.
• os.arch mapping is thin. arm (32-bit) and other values fall through to UnsatisfiedLinkError, which is fine, but the message should name the resolved classifier so users can tell "unsupported arch" from "missing native jar".

Smaller notes

• Module.kt:38 ExecuTorchRuntime.getRuntime() in init{} — on Android the classes-load ordering that used to guarantee the native lib was up now depends on the provider having run first. Another reason the per-artifact static approach is safer.
• log.cpp:96 non-Android fallback writes to stderr unconditionally and unbuffered-per-line; fine for a first cut, but note it ignores timestamp/line/function, so desktop logs are lower-fidelity than logcat. Acceptable, just flagging.
• extension/jvm/build.gradle:77 stages from rootProject.file("../cmake-out-jvm/...") — a path outside the Gradle root. Works, but it's an implicit contract with CI; a log/validation when the dir is missing (beyond onlyIf) would make "API-jar-only" builds less surprising.

---

Bottom line: the desktop-JVM mechanics (native classifier jars, loader, delegate) are the reusable, valuable part and are in good shape modulo the hardening above. The Android-contract coupling on this branch is what the shared-source pivot exists to remove, and the ExecuTorchJvm.init() bug is a real functional blocker for the desktop path as written. I'd recommend landing #22338 (behavior-preserving extraction, empty AAR diff) first, then rebuilding the JVM jar on top with lazy native loading and the extraction hardening — which is the sequence already agreed in-thread.

[RanjithRagavan]

@kirklandsign Thanks for the review — agreed on all points. #22338 is the current direction; this PR stays as the umbrella for steps 2–3 and won't merge as-is.

Once #22338 lands I'll rebuild the JVM module on top of it with: lazy per-artifact native loading (the ExecuTorchJvm.init() bug disappears structurally — no shared mutable loader config), extraction hardening (per-process temp dir, checksum verification, classifier-named errors), plus the smaller notes on staging-path validation and log.cpp fidelity. The classifier-jar packaging and consumer tests carry over.