IKVM for .NET: Running and Converting Java Bytecode

Why IKVM Exists for .NET Teams

IKVM addresses a specific interoperability problem: how to execute existing compiled Java code from the Microsoft .NET platform without first porting its source to C#. Its documented uses fall into two forms. Static integration converts bytecode into a .NET assembly that an ordinary .NET application can reference. Dynamic execution uses the `java` executable in the JDK runtime image to convert bytecode on the fly and run it.

The intended users are .NET developers who already have a JAR, dependency set, or Java application that must operate within a .NET environment. The project supports .NET Framework 4.7.2 and later, as well as .NET 6 and later. Its documented platform coverage includes Windows x86, x64, and ARM64; Linux x64, ARM, and ARM64 with GLIBC or MUSL; and Mac OS X x64 and arm64. The README cautions that support differs among artifacts because some platform images or tools cannot be distributed in every form.

IKVM does not decompile Java bytecode into C# source and does not execute .NET code in Java. Its direction is explicit: Java to .NET. It is therefore a fit for binary reuse and runtime compatibility, not for teams expecting readable translated C# or bidirectional managed-code interoperation.

IKVM's JVM, Class Libraries, and Bytecode Pipeline

The repository describes five related components: a Java virtual machine implemented in .NET, a .NET implementation of the Java class libraries, a translator from Java bytecode to .NET IL, interoperability tools, and a full JRE/JDK 8 runtime image. These pieces address different layers. Bytecode translation makes compiled Java types available to .NET assemblies, while the virtual machine and class libraries support code paths that need Java runtime behavior.

The static path begins with a JAR and produces a DLL or EXE as part of an .NET build. `IkvmReference` performs that build-time conversion and automatically adds a reference to the resulting assembly. Java package names become .NET namespaces, so a .NET project can call APIs from the compiled JAR without receiving translated C# source.

The dynamic path is different. A Java application is started through the `java` executable included in the JDK runtime image. According to the README, bytecode is converted on-the-fly to Common Intermediate Language, or CIL, and then executed. This distinction matters when choosing an integration style: a build-time assembly has a place in the .NET dependency graph, while on-the-fly conversion belongs to a runtime image with a normal JRE or JDK directory structure.

Installing IKVM Packages and Runtime Images

The README documents NuGet installation through the Visual Studio Package Manager console. Install `IKVM` in a project that needs the main runtime and build integration. Projects using the Maven-oriented integration install `IKVM.Maven.Sdk` instead.

In the Package Manager console, enter:

PM> Install-Package IKVM

The command adds IKVM to the current project. For Maven-based integration, the documented alternative is:

PM> Install-Package IKVM.Maven.Sdk

Some Java libraries require tools or class content associated with a full runtime image. In that case, install the appropriate image package:

PM> Install-Package IKVM.Image.JRE
PM> Install-Package IKVM.Image.JDK

A standalone JDK is also available from the repository's Releases page. The README states that its directory structure can serve as `JAVA_HOME` for standard Java applications. The release tools, including the low-level tools discussed by the documentation, are also linked from Releases. The README does not provide operating-system-specific archive names or checksum instructions.

Converting a JAR with IkvmReference

The shortest documented static-use example adds the `IKVM` package and identifies a JAR through an `IkvmReference` item. XML metadata is shown below in a console block because the README presents the settings as an SDK-style project snippet.

<ItemGroup>
  <PackageReference Include="IKVM" Version="Version" />
</ItemGroup>

<ItemGroup>
  <IkvmReference Include="..\..\ext\helloworld\helloworld-2.0.jar" />

Replace the example's `Version` placeholder with the package version selected for the project, and adjust the JAR path to the application's actual location. During the build, IKVM translates the Java library and automatically adds a reference to the generated assembly. The resulting assembly follows the rules described for automatic assembly naming and versioning unless those settings are overridden.

The documented metadata goes beyond basic conversion. `AssemblyName` and `AssemblyVersion` override generated identity values, while `DisableAutoAssemblyName` and `DisableAutoAssemblyVersion` turn off automatic detection. `KeyFile` selects a cryptographic key file, `DelaySign` requests delayed signing, and `Compile`, `Sources`, and `References` control JAR handling. A first use should start with only `Include`, since the README says additional metadata customizes the generated assembly rather than being required for the basic example.

Static Conversion Versus Dynamic JDK Execution

Static conversion and dynamic execution expose Java in different .NET build layouts. With `IkvmReference`, translation occurs during the .NET build, and the generated assembly becomes a project reference. This suits applications that consume Java libraries through normal .NET dependency resolution. A library JAR becomes an assembly reference, while an executable assembly needs the class containing `main()` identified when it is built with `ikvmc`.

The dynamic route instead uses the `java` executable from a packaged JDK image. The bytecode conversion happens on-the-fly, and the application is launched through Java tooling. This preserves a familiar JRE or JDK directory structure and can support standard tools such as `javac`, `jdeps`, `policytool`, and `keytool`.

A real alternative is to rewrite the Java source as C# and build it directly for .NET. That approach produces native .NET source and may simplify debugging and deployment, but it is a porting project rather than binary interoperability. IKVM instead preserves the existing compiled Java artifact. Conversely, a conventional Java runtime plus a separate service boundary avoids loading Java into the .NET process, at the cost of distributed application structure. The README does not document process isolation, performance, service deployment, or rollback, so those concerns cannot be resolved from the project documentation.

Java SE 8 and Artifact Boundaries

The clearest compatibility boundary is Java SE 8. IKVM describes a full JRE/JDK 8 runtime image, and its support list names Java SE 8. A JAR compiled for that compatibility target is the documented operating case. The repository does not claim support for converting current Java SE bytecode into C# source or for running every newer Java release.

The artifact boundary is equally important. `IKVM`, `IKVM.Maven.Sdk`, `IKVM.Image.JRE`, and `IKVM.Image.JDK` solve different packaging needs. The core package supports .NET integration, the Maven SDK adds another project entry point, and the image packages supply runtime directory structures. Some libraries need JDK rather than JRE content, so choosing only the JRE image can leave a required tool or library unavailable.

IKVM is the wrong tool when the requirement is to recover C# source, inspect readable decompiled logic, or run .NET assemblies on Java. It is also a poor fit when the deployment requires an artifact that the README says cannot be distributed for that platform. Since artifact availability varies, platform support should be checked against the specific package or release before application migration begins.

Release Activity, Compatibility Work, and Licensing

The repository is not archived. Its last push was on 2026-10-14, and the release list includes versions 8.16.2, 8.16.1, and 8.16.0 from August, September, and October 2026. This is evidence of recent repository and release activity, although the README does not provide a compatibility policy for each IKVM release or a long-term-support schedule.

Compatibility still requires engineering attention. A Java library can bring transitive JARs, Java SE 8 runtime expectations, native platform constraints, and assembly metadata choices into the.NET build. `IkvmReference` exposes controls for dependencies, keys, signing, aliases, debugging, and assembly identity, which indicates that successful packaging may require more than pointing at the main JAR. The README does not document diagnostic commands or a rollback procedure, so upgrade validation has to be tied to the application's own build and Java behavior.

The repository identifies its license as a custom license that GitHub cannot classify. `LICENSE.md` is the controlling project file. The available description does not state whether redistribution, packaging, commercial use, or modifications have particular conditions, so license obligations cannot be summarized further without reading that file.

Editorial conclusion

IKVM is appropriate for .NET teams with compiled Java libraries or applications that must execute without a C# rewrite, but it is unsuitable for Java-to-C# source conversion, decompilation, or running .NET code inside Java. Before adoption, verify that the required Java SE 8 library is available, confirm support for the chosen .NET and operating-system combination, and review `LICENSE.md` because the repository uses a custom license rather than a standard GitHub license classification.

Frequently asked questions

Official sources

1. ikvmnet/ikvm on GitHub
2. Issues
3. README
4. Releases