J2C Modern Edition

J2C translates Java source code to C++. This repository packages the standalone command-line translator and the J2C Java to C++ VS Code extension. It is a modernized continuation of arnetheduck/j2c, whose original Eclipse plugin remains in that repository.

Preview: J2C is a source translator, not a complete Java compiler or runtime. Java feature support is incremental. Generated C++ may need manual changes and a compatible implementation of Java runtime behavior. Do not assume that arbitrary Java programs compile or preserve all JVM semantics.

Requirements

• Java 11 or newer to run the CLI and VS Code extension.
• Maven to build the CLI from source.
• A C++20 compiler for generated Makefiles and C++ output.
• Node.js 22 or newer and npm to package the VS Code extension.

CLI

Build the executable JAR from the repository root:

mvn package

Create an output directory and translate a Java file or source directory:

mkdir generated
java -jar target/j2c-cli.jar \
  --output generated \
  --sourcepath test/src \
  test/src/se/arnetheduck/j2c/test/Hello.java

Use the platform path separator between multiple source roots or classpath entries (; on Windows, : on macOS/Linux). Source paths help resolve Java source dependencies; classpath entries should identify dependency JARs or class directories. If --sourcepath is omitted, J2C infers roots from the selected inputs.

The --sealed-types policy defaults to advisory. Sealed declarations are translated using ordinary C++ inheritance and generated comments list permitted direct subtypes; C++ does not enforce Java's permits restriction. Choose --sealed-types reject to stop translation when sealed or non-sealed declarations are encountered.

Additional optional arguments are --classpath <paths>, --name <name>, --sealed-types advisory|reject, and --encoding <charset>. Java sources are read as UTF-8 unless --encoding says otherwise; generated C++ is always written as UTF-8.

Translate against the J2C runtime so the program runs without writing any C++:

java -jar target/j2c-cli.jar --runtime bundled --output generated test/runtime/hello
make -C generated all mains && generated/bin/Hello

--runtime bundled uses the runtime packaged in the CLI JAR (and in the VS Code extension), so no repository checkout is needed: on first use it is extracted to ~/.j2c/cache/runtime-<version>-<hash> (or J2C_CACHE_DIR), reused while its files are intact, and replaced when they are not. --runtime <directory> uses another runtime directory, such as a checkout's runtime/ (name a directory called bundled as ./bundled). Without --runtime, the default, java.* comes from the running JDK and every JDK class is a stub that fails at run time; with it, java.* comes from the runtime, so JDK classes it does not provide are compile errors that --check lists. See runtime/README.md for what it covers.

j2c run translates, builds and runs a program in one step, runs the same main class on the JVM, and compares the two:

java -jar target/j2c-cli.jar run --output generated test/runtime/hello -- one "two words"
java -jar target/j2c-cli.jar run --output generated --format json   --main Stdin --stdin test/runtime/stdin/input.txt test/runtime/stdin test/runtime/hello

It translates against the runtime (--runtime, default bundled) with --line-directives, builds the main class's binary (make bin/<Class>, run as j2c build runs make, so a failed build reports the compiler's errors at their Java lines), runs it in a fresh working directory with the arguments after -- and the bytes of --stdin <file> as standard input, compiles the same sources with the javac of the JDK running J2C, and runs the class with java (in WSL when the build ran there: --java <program>, else J2C_WSL_JAVA, else java on WSL's PATH, else the Wind

... View full README on GitHub