Mobile JavaScript, Electron and Java: Before and After in Real Runtimes

1. Mobile source and compiled Hermes bytecode

The mobile build hook accepts JavaScript source before compilation. We ran the original and transformed source, then compiled each with the same Hermes revision and ran the resulting bytecode. The fixture exercises module initialization, cached imports, state, rejected inputs, Unicode and date operations using Day.js 1.11.13 and its UTC plugin.

Both source and compiled bytecode grew in this run. The Hermes run report contains the per-scenario observations, source and bytecode hashes, compiler commands, versions, timestamps and BoxFleet identifiers. A deliberately incorrect runtime result and a missing scenario were rejected. The comparison also checked global property names and host codec availability.

Mobile boundary: this is a standalone engine run with an owned Metro-style loader. React Native UI, native modules, JNI, Android APK/AAB installation, iOS IPA installation and signing were not tested. The build hook does not accept existing Hermes bytecode as protection input. A complete mobile application still needs qualification with its own matching engine and native host.

2. Electron main, preload and renderer

The desktop pipeline transforms explicitly selected application files and writes a new directory or ASAR archive. The fixture includes a CommonJS main process and preload, an ESM renderer with a live exported binding, IPC calls, an unchanged dependency, resources and package metadata. All four application variants were launched in Electron 44.5.0 on Linux x64.

The byte count above is the sum of application file contents, not installer or ASAR container size. The Electron run report includes application inventories, file hashes, the selected roles, each scenario and runtime settings. Unselected files matched byte-for-byte, and the protected directory and ASAR contained the same application files. Incorrect and incomplete result controls were rejected.

The first Electron attempt exposed a problem in the test harness: evaluating code through the debugger bypassed the intended CSP control. The corrected test clicks a button whose application handler attempts the evaluation, then observes the rejection and enforcement event. The failed attempt is retained in the operator validation record.

Desktop boundary: one owned Linux fixture is qualified. Native addons, unpacked ASAR sidecars, installers, updates, signatures, notarization, Windows and macOS remain unqualified. Chromium's operating-system sandbox was disabled in E2B; the preload JavaScript sandbox and context isolation were measured separately.

3. Java application and library JARs

On October 22, the Java classpath fixture ran on OpenJDK 17.0.20.1 under Linux x64. We compared the original and transformed application JARs, then repeated the same scenarios through a separate consumer compiled against the original library. The consumer's compiled class stayed byte-for-byte unchanged. The fixture covers API calls, state, rounding, rejected inputs, reflection, annotations, service discovery, resource contents and resource-directory lookup.

The Java run report records all 68 scenario executions, artifact hashes, resource preservation, runtime versions and BoxFleet provenance. Three deliberately incomplete JARs, missing a resource, service descriptor or API class, failed when executed. A separate wrong-output comparison was also rejected. The size changes describe these JAR files and do not establish a resistance score.

Java boundary: every tested JVM process used -Dfile.encoding=UTF-8 for the Unicode console contract. This evidence covers one owned Java 17 classpath application and library with explicit contracts. Kotlin metadata, Android/iOS, desktop GUI behavior, Windows/macOS, external dependencies, undeclared reflection, signed JARs, JPMS modules and multi-release JARs remain unqualified or unsupported by this build path. Admission checks reject recognized native formats and nested ZIP/JAR files; opaque resources may be preserved without execution or runtime qualification.

4. Application inventory and remaining coverage

A read-only inventory command identifies components in directories and packages, including APK/AAB, IPA, ASAR, JAR and wheel layouts. It reports source candidates and untreated components with hashes. It does not execute the package, verify signatures or turn native and bytecode components into supported protection inputs.

Review the application coverage matrix for the exact input, packaging and runtime status of each family. Native Android/iOS, Flutter, Unity, MAUI and other desktop runtimes require their own implementation and matching platform evidence. Timings in the linked reports are individual observations, not production performance estimates. No OpenShell enforcement is claimed for these runs.

See the earlier public-project and Chromium measurements ↗