J2CL: Java to Closure JavaScript with Bazel

Why J2CL Targets a Java Web Stack

J2CL addresses a specific problem: allowing Java source to participate in a modern web application without treating Java as a separate application platform. It converts Java to Closure-style JavaScript and connects that output to Closure Compiler. The intended audience is therefore not every Java developer. It is teams building web code that want Java's type system, reusable libraries, and Bazel-supported compilation while retaining a JavaScript deployment target.

The README says J2CL underlies Google web products including Gmail, Inbox, Docs, Slides, and Calendar. It also warns that the process of adapting workflows and tooling for the open-source version is not finalized and describes the project as an alpha developer preview. Those statements should be read together. The compiler has production use inside Google, but the public repository does not present the surrounding open-source adoption process as finished. That distinction matters when planning an external project because build rules, dependency declarations, and release integration still form part of the adoption cost.

J2CL is also relevant when an application contains both Java and JavaScript. Java can supply typed components or reusable domain logic, while Closure Compiler processes the resulting JavaScript and its cross-language interoperability. This is not a general-purpose converter for making every JVM library work in a browser. Library compatibility depends on what J2CL and its emulation layer support.

J2CL Compilation and Cross-Language Checks

The visible architecture is centered on transpilation from Java to Closure-style JavaScript, followed by checks that account for types crossing the language boundary. `README.md` describes runtime type checking based on Java's strong type system, together with cross-language type checks. Those checks are relevant when Java code calls JavaScript or interacts with JavaScript-facing APIs because the compiler can inspect more than the Java class signature alone.

J2CL is powered by Bazel. Repository directories such as `transpiler/`, `build_defs/`, `third_party/`, and `samples/` indicate that compilation rules, bundled dependencies, and executable examples are first-class parts of the repository. The `MODULE.bazel`, `BUILD`, and `.bazelrc` files also make Bazel configuration part of using the project. This differs from treating the transpiler as a standalone command that accepts any JAR file.

The project also publishes data type and semantics documentation under `docs/semantics.md`. That distinction matters because compiling syntactically valid Java does not mean every JVM behavior survives unchanged in a browser. J2CL closely follows Java semantics, but the repository includes a dedicated emulation-limitations guide. Code review should therefore include the intended runtime behavior, supported library dependencies, and JavaScript interoperation points, not just Java compilation errors.

Getting Started Through the Repository Guides

`README.md` does not provide a self-contained installation command or a minimal command sequence for compiling the sample applications. It directs new users to `docs/getting-started.md` and points JavaScript users to the Bazel documentation. A first real use should begin in one of those documents rather than with an invented package name or compiler flag.

The repository contains `samples/helloworld/`, which is the most direct sample for an initial build, plus `samples/guava/`, `samples/box2d/`, and `samples/wasm/`. Start with the Hello World sample because it narrows the first verification to one Java-to-JavaScript compilation path. The repository also includes Guava, Box2D, and Wasm samples.

The first result is not documented as a universal command or fixed output filename in `README.md`. It should instead be verified against the Bazel target and configuration named by `docs/getting-started.md` and the selected sample. Record the generated JavaScript or Wasm artifact, compare it with the sample's expected browser entry point, and check the browser console for type-checking or compatibility errors. This workflow is less convenient than a one-line converter, but it reflects the actual Bazel-oriented project layout.

Windows users face an explicit boundary. `README.md` says the workflow is not yet supported on Windows and points developers to WSL. That recommendation concerns the build workflow, not permission to run generated JavaScript in a Windows browser.

WebAssembly Support and Specification Boundaries

J2CL has a separate getting-started guide, `docs/getting-started-j2wasm.md`, and a `samples/wasm/` directory. This makes WebAssembly a repository-supported direction rather than an incidental feature name. `README.md`, however, explicitly labels Wasm support work in progress because related specification work was not finalized when that statement was written. It also points to issue 93 for development status and says browser availability was still tied to specification and V8 work.

That caveat has two practical effects. First, a project should not infer identical deployment support across browsers merely because J2CL can generate a Wasm target. Second, Wasm should be separated from the JavaScript evaluation. A successful JavaScript build does not prove that a Wasm build has the same dependency set, debugging experience, runtime behavior, or browser compatibility.

The repository topic `wasmgc` and the Wasm sample indicate a distinct output path from ordinary Closure JavaScript. `README.md` does not provide enough detail to claim equivalent feature coverage between the two targets. Projects considering J2CL for Wasm should first resolve their required browser matrix, then reproduce the Wasm sample under the relevant `docs/getting-started-j2wasm.md` instructions. If browser support is a release gate, the state of issue 93 is more relevant than the project's overall production-use statement.

Java Semantics Limits Reuse

J2CL's reuse case depends on how faithfully the relevant JVM behavior can be emulated in JavaScript. `README.md` names Guava, Dagger, and AutoValue as libraries brought into the JavaScript toolchain, while `docs/limitations.md` exists specifically to record emulation constraints. This is the central trade-off: Java syntax alone is not enough, because applications also depend on collections, reflection patterns, concurrency behavior, class loading assumptions, or library code that expects JVM facilities.

The presence of `jre/`, `junit/`, `maven/`, `third_party/`, and library samples shows that compatibility is handled as a build and runtime concern. It should not be interpreted as unrestricted support for arbitrary Maven Central artifacts. `README.md` does not document a general promise that every dependency can be added with `maven()` or that every JAR is browser-compatible.

The README does not name reflection or other specific runtime facilities as limitations, so this review does not assign J2CL a more precise list. The defensible test is narrower: inspect `docs/limitations.md`, locate the needed library support in `third_party/`, and compile a small usage that exercises the actual APIs. Libraries used only in a narrow configuration may pass while unrelated modules fail during emulation or optimization.

J2CL and GWT Use Different Integration Boundaries

J2CL is related to GWT, but `README.md` does not frame it as a drop-in replacement. It explains that the GWT team began J2CL as a new alternative because Java on the web needed tighter integration with the wider ecosystem, a modern architecture, and a different development workflow. The strategy also shifted GWT3 toward an SDK centered on libraries and enterprise tooling.

The practical difference is architectural and operational. J2CL centers its public workflow on Bazel, Closure-style JavaScript, Java-to-JavaScript interoperation, and a separate Wasm path. GWT historically represented a different Java web compiler and SDK orientation. For an adopter, the choice comes down to the build ecosystem and target requirements, not merely the shared goal of running Java in a browser.

A team already standardized on Bazel and Closure Compiler has a clearer reason to evaluate J2CL. A team standardized on GWT libraries or established GWT module configuration would need evidence that the required library and build behavior is preserved. `README.md` positions the projects as complementary concerns, not as interchangeable command-line compilers. Neither product is a safe substitute without checking application-specific dependencies.

Maintenance, Releases, and Apache-2.0 Obligations

The repository is not archived, and its last push was on 2026-10-15. Recent release tags include `v20260402`, `v20250630`, and `v20250623`. Those facts indicate ongoing repository activity, but they do not remove the README's open-source workflow warning or its alpha developer-preview disclaimer.

The upgrade cost is likely to sit in Bazel build definitions and dependency declarations rather than only Java source changes. A release change can affect `MODULE.bazel`, repository rules, bundled `third_party/` dependencies, generated output, or browser validation. `build_test.sh` and `build_test_samples.sh` show that the project includes executable test entry points, although `README.md` does not describe their full invocation or output.

J2CL is licensed under `Apache-2.0`. That identifier permits use and modification under the license's conditions, including preservation of applicable notices and the license text. This is not legal advice, and organizations still need to review notices, third-party dependencies, and internal policy. The project-specific upgrade check is to run the sample and repository test paths documented for the selected release, then inspect generated output before changing production build targets.

Editorial conclusion

J2CL fits teams that already build with Bazel and want typed Java code to participate directly in a Closure Compiler or WebAssembly-based web application. It is a poor fit for a simple Node.js deployment, a Maven or Gradle workflow that cannot absorb Bazel, or a Windows-native setup. Before adoption, inspect `docs/limitations.md`, test the required libraries under `third_party/`, and confirm that the selected browser and WebAssembly specifications match the project's Wasm status.

Frequently asked questions

Official sources

1. google/j2cl on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases