Forem: JNBridge

Run Java from C#: 5 Methods with Code Examples

JNBridge — Thu, 07 May 2026 14:38:37 +0000

If you need to call Java from a .NET app, the first answer is usually “just shell out to java.exe.” That works right up until you need objects, exceptions, throughput, or a deployment story that doesn’t become a pile of scripts.

This Dev.to version walks through five practical ways to run Java from C# — from Process.Start to IKVM, JNI, gRPC, and in-process bridging — with code and the tradeoffs that matter in production.

TL;DR — Need to run Java from C#? Use Process.Start for one-off JAR executions, IKVM for pure-Java libraries with no native dependencies, gRPC for microservice architectures, JNI if you have C++ expertise and need raw speed, or JNBridgePro for production-grade in-process bridging with low latency and zero JNI glue code. See the comparison table and decision tree below.

You have a Java library you need to use from a C#/.NET application — maybe a payment SDK, a machine-learning model, or a legacy system nobody wants to rewrite. Whatever the reason, you need to run Java from C#, and it has to work in production.

If you’ve searched before, you probably found a StackOverflow answer from 2012 telling you to use Process.Start("java.exe"). That works for trivial cases, but falls apart when you need real interop: passing objects, handling exceptions across the JVM and CLR, or making thousands of calls per second with minimal latency.

This guide covers five real methods to run Java code in C#, from simple shell-out to full in-process bridging. Each includes working code, honest trade-offs, and guidance on when to use it.

Quick Comparison
Method 1: Process.Start — Run java.exe as a Subprocess
Method 2: IKVM — Compile Java Bytecode to .NET
Method 3: JNI via C++/CLI Wrapper
Method 4: gRPC Sidecar — Run Java as a Microservice
Method 5: JNBridgePro — In-Process Java/.NET Bridge
Performance Benchmarks
Which Method Should You Use?
How Do You Handle Java Dependencies from C#?
Can You Run Java from C# Without a JDK?
Frequently Asked Questions
Wrapping Up

Quick Comparison

Before diving into code, here’s what you’re choosing between:

Method	Integration Depth	Per-Call Latency	Complexity	Best For
Process.Start	Shallow (stdin/stdout)	High (~50ms+)	Low	One-off JAR execution
IKVM	Deep (.NET assembly)	Low (~0.1ms)	Medium	Pure-Java libs, no native deps
JNI via C++/CLI	Deep (native calls)	Lowest (~0.05ms)	Very High	Max control, C++ teams
gRPC Sidecar	Medium (RPC)	Medium (~2–5ms)	Medium	Microservices, cloud-native
JNBridgePro	Deep (in-process)	Low (~0.1ms)	Low	Production apps, bidirectional

🔗 For a deeper dive on bridge vs. REST vs. gRPC trade-offs, see our Bridge vs REST vs gRPC comparison.

Method 1: Process.Start — Run java.exe as a Subprocess

The most straightforward way to run Java from C# is to launch the JVM as a separate process using Process.Start. This is what most StackOverflow answers suggest, and for simple, one-shot tasks it’s perfectly fine.

When to Use It

Running a standalone Java CLI tool or JAR file
One-off executions (batch jobs, code generation, file conversion)
You don’t need to pass complex objects back and forth

Code Example

using System.Diagnostics;
using System.Text;

public class JavaProcessRunner

{

    public static async Task<string> RunJavaJarAsync(

        string jarPath,

        string arguments,

        string? javaHome = null)

    {

        var javaExe = javaHome != null

            ? Path.Combine(javaHome, "bin", "java")

            : "java";

var startInfo = new ProcessStartInfo

        {

            FileName = javaExe,

            Arguments = $"-jar \"{jarPath}\" {arguments}",

            RedirectStandardOutput = true,

            RedirectStandardError = true,

            UseShellExecute = false,

            CreateNoWindow = true

        };

// Pass classpath and other JVM options via environment

        startInfo.Environment["CLASSPATH"] =

            "/libs/dependency1.jar:/libs/dependency2.jar";

using var process = new Process { StartInfo = startInfo };

        var output = new StringBuilder();

        var errors = new StringBuilder();

process.OutputDataReceived += (_, e) =>

            { if (e.Data != null) output.AppendLine(e.Data); };

        process.ErrorDataReceived += (_, e) =>

            { if (e.Data != null) errors.AppendLine(e.Data); };

process.Start();

        process.BeginOutputReadLine();

        process.BeginErrorReadLine();

using var cts = new CancellationTokenSource(

            TimeSpan.FromSeconds(30));

        try

        {

            await process.WaitForExitAsync(cts.Token);

        }

        catch (OperationCanceledException)

        {

            process.Kill(entireProcessTree: true);

            throw new TimeoutException(

                "Java process timed out after 30s");

        }

if (process.ExitCode != 0)

            throw new Exception(

                $"Java exited with code {process.ExitCode}: {errors}");

return output.ToString();

    }

}

// Usage

var result = await JavaProcessRunner.RunJavaJarAsync(

    "/app/libs/converter.jar",

    "--input data.csv --format json");

🔗 For a complete walkthrough of running JAR files from .NET, see How to Run a Java JAR from C#.

Edge Cases to Handle

Classpath hell: Use -cp or the CLASSPATH environment variable. On Windows, separate entries with ;; on Linux/macOS, use :.
JVM not found: Check that java is on the system PATH or pass JAVA_HOME explicitly.
Large output: For big payloads, write to a temp file instead of piping through stdout.
Process leaks: Always use using and kill on timeout — orphaned JVM processes eat server memory.

The Problem

Every call spawns a new JVM. That's 50–200ms of startup overhead per invocation, plus the memory cost of a full JVM instance. If you're making more than a handful of calls, this approach doesn't scale.

Method 2: IKVM — Compile Java Bytecode to .NET

IKVM converts Java bytecode into .NET assemblies. You run ikvmc against a JAR file and get a DLL you can reference directly in your C# project. Your Java code literally runs on the CLR — no JVM required.

When to Use It

The Java library is self-contained with few dependencies
You need tight, low-latency integration
You're okay with some compatibility limitations

Code Example

First, convert the JAR:

# Install IKVM (community fork targets .NET 6+)

dotnet add package IKVM

# Or use the command-line converter

ikvmc -target:library -out:MyJavaLib.dll mylib.jar

Then use it from C# like any other .NET library:

using com.example.mylib;

public class IkvmExample

{

    public static void RunJavaCodeInCSharp()

    {

        // Java classes are now .NET classes

        var parser = new com.example.mylib.JsonParser();

        // Call Java methods directly — compiled to IL bytecode

        var result = parser.parse("{\"key\": \"value\"}");

        Console.WriteLine($"Parsed: {result.get("key")}");

// Java collections work but need casting

        var list = new java.util.ArrayList();

        list.add("item1");

        list.add("item2");

var iterator = list.iterator();

        while (iterator.hasNext())

            Console.WriteLine(iterator.next());

    }

}

Limitations

IKVM was a remarkable project, but it has real constraints:

Incomplete JDK coverage: Not every javax. or java. class is implemented. Swing, AWT, and many java.nio features are missing or broken.
Reflection edge cases: Java code relying heavily on reflection may behave differently.
Native dependencies: If your JAR depends on native JNI libraries, IKVM can't help.
Maintenance status: The original project was abandoned. The ikvm-revived community fork targets .NET 6+ but coverage varies.

🔗 Migrating away from IKVM? See our guide on Migrating from IKVM to JNBridgePro.

For simple, pure-Java libraries, IKVM is elegant. For anything touching the filesystem, networking, or native code, expect surprises.

Method 3: JNI via C++/CLI Wrapper

The Java Native Interface (JNI) is the official way for native code to interact with the JVM. C++/CLI lets you write code that lives in both the .NET and native worlds, making it possible to load a JVM inside your .NET process and call Java methods through JNI.

This is the most powerful — and most painful — approach.

When to Use It

You need maximum performance and control over marshaling
You're comfortable with C++ and manual memory management
You have a dedicated team to maintain the interop layer

Code Example

C++/CLI Bridge (JavaBridge.cpp):

// Compile as C++/CLI: /clr
#include <jni.h>
#using <mscorlib.dll>

using namespace System;

using namespace System::Runtime::InteropServices;


public ref class JavaBridge

{

private:

    JavaVM* jvm;

    JNIEnv* env;


public:

    JavaBridge(String^ classPath)

    {

        JavaVMInitArgs vmArgs;

        JavaVMOption options[1];


IntPtr cpPtr = Marshal::StringToHGlobalAnsi(

            String::Format("-Djava.class.path={0}", classPath));

        options[0].optionString =

            static_cast(cpPtr.ToPointer());


vmArgs.version = JNI_VERSION_1_8;

        vmArgs.nOptions = 1;

        vmArgs.options = options;

        vmArgs.ignoreUnrecognized = JNI_FALSE;


jint rc = JNI_CreateJavaVM(

            &jvm, (void**)&env, &vmArgs);

        Marshal::FreeHGlobal(cpPtr);


if (rc != JNI_OK)

            throw gcnew Exception(String::Format(

                "Failed to create JVM: error {0}", rc));

    }


String^ CallStaticMethod(

        String^ className,

        String^ methodName,

        String^ arg)

    {

        // Convert .NET strings to native for JNI

        IntPtr clsName = Marshal::StringToHGlobalAnsi(className);

        jclass cls = env->FindClass(

            static_cast(clsName.ToPointer()));


if (cls == nullptr)

            throw gcnew Exception(

                "Java class not found: " + className);


// ... method lookup, call, string marshaling ...

        // (Full implementation requires ~50 lines of

        //  careful memory management)

    }


~JavaBridge() { if (jvm) jvm->DestroyJavaVM(); }

};

C# Usage:

using var bridge = new JavaBridge(

    @"C:\myapp\libs\mylib.jar");

string result = bridge.CallStaticMethod(

    "com/example/TextProcessor",

    "processText",

    "Hello from C#!");

Console.WriteLine(result);

Why Most Teams Don't Do This

You must maintain C++/CLI code — a language most .NET developers don't know
Manual JNI string/array/object marshaling is tedious and error-prone
One null-pointer mistake crashes your entire process (segfault, not a managed exception)
Only one JVM per process (JNI limitation)
Every new Java method requires more C++ glue code
Windows-only if using C++/CLI (use P/Invoke on Linux)

This is the "build your own bridge" option. It works, but you're signing up to maintain it forever.

Method 4: gRPC Sidecar — Run Java as a Microservice

Instead of running Java inside your .NET process, run it alongside as a separate service. Define your interface in Protocol Buffers, generate clients for both languages, and communicate over gRPC. This is the modern, cloud-native approach.

When to Use It

You're already in a microservices architecture
You want clean language boundaries
You need to scale the Java and .NET parts independently
Latency of 2–5ms per call is acceptable

Code Example

1. Define the service (calculator.proto):

syntax = "proto3";

package calculator;


service Calculator {

    rpc Calculate (CalcRequest) returns (CalcResponse);

    rpc BatchCalculate (stream CalcRequest)

        returns (stream CalcResponse);

}


message CalcRequest {

    string expression = 1;

    int32 precision = 2;

}


message CalcResponse {

    double result = 1;

    string formatted = 2;

}

2. C# client:

using Grpc.Net.Client;

using Calculator;

public class JavaGrpcClient : IDisposable

{

    private readonly GrpcChannel _channel;

    private readonly Calculator.CalculatorClient _client;

public JavaGrpcClient(

        string address = "http://localhost:50051")

    {

        _channel = GrpcChannel.ForAddress(address);

        _client = new Calculator.CalculatorClient(_channel);

    }

public async Task<(double Result, string Formatted)>

        CalculateAsync(string expression, int precision = 2)

    {

        var response = await _client.CalculateAsync(

            new CalcRequest

            {

                Expression = expression,

                Precision = precision

            });

        return (response.Result, response.Formatted);

    }

public void Dispose() => _channel?.Dispose();

}

// Usage

using var client = new JavaGrpcClient();

var (result, formatted) = await client.CalculateAsync(

    "(3.14159 * 2) + 1", 4);

Console.WriteLine($"Result: {formatted}"); // "7.2832"

Trade-offs

Pros	Cons
Clean separation of concerns	Network overhead (2–5ms/call)
Language-independent contracts	Must maintain .proto files
Independently scalable	Two processes to deploy and monitor
Easy to test in isolation	Serialization cost for complex objects

Method 5: JNBridgePro — In-Process Java/.NET Bridge

JNBridgePro loads the JVM inside your .NET process and lets you call Java classes as if they were native C# objects. You use a proxy generation tool to create .NET wrappers for your Java classes, then call them with normal C# syntax. No JNI glue code, no process management, no serialization.

When to Use It

You need low-latency, high-frequency calls to Java code
You want to pass complex objects between Java and .NET without serialization
You need Java callbacks into .NET (bidirectional interop)
You don't want to maintain interop infrastructure yourself

Code Example

using com.jnbridge.jnbcore;

using com.example.mylib;  // Generated proxies

public class JNBridgeExample

{

    public static void RunJavaInsideDotNet()

    {

        // Initialize — starts a JVM in-process

        DotNetSide.init(new JNBLicenseInfo("license.dat"),

            new JNBClassPathInfo

        {

            ClassPath = new[]

            {

                "/app/libs/mylib.jar",

                "/app/libs/dependency.jar"

            },

            JvmPath = "/usr/lib/jvm/java-17/lib/server/libjvm.so"

        });

try

        {

            // Use Java objects like C# objects

            var processor = new com.example.mylib.DataProcessor();

// .NET types are marshaled automatically

            var config = new java.util.HashMap();

            config.put("mode", "batch");

            config.put("threads", java.lang.Integer.valueOf(4));

            processor.configure(config);

// Process data

            var input = new java.util.ArrayList();

            for (int i = 0; i < 1000; i++)
                input.add($"record-{i}");

var results = processor.processAll(input);

            Console.WriteLine(

                $"Processed {results.size()} records");

        }

        finally

        {

            DotNetSide.shutdown();

        }

    }

}

What Makes It Different

JNBridgePro handles the hard parts you'd have to build yourself with JNI:

Type marshaling: Java strings, primitives, arrays, and collections convert automatically between the JVM and CLR
Exception bridging: Java exceptions become .NET exceptions with full stack traces
Garbage collection: Objects on both sides are properly tracked and collected
Bidirectional calls: .NET code can call Java, and Java can call back into .NET
Proxy generation: Point at a JAR, get .NET wrapper classes — no manual coding

It's a commercial product, which is the main barrier. But if you're evaluating the best way to run Java from .NET in production, the license cost is typically less than the engineering time to build and maintain a JNI wrapper or gRPC layer.

🔗 See how JNBridgePro compares to other Java–C# bridge tools.

Performance Benchmarks

These benchmarks measure calling a Java method that concatenates two strings — a minimal operation to isolate interop overhead. Environment: .NET 8, Java 17, Windows 11, 16GB RAM.

Method	JVM Startup	Per-Call Latency	Memory	Throughput (calls/sec)
Process.Start	~150ms/call	~50–200ms	~50MB/process	~5–20
IKVM	0 (no JVM)	~0.1ms	~20–50MB	~500,000+
JNI/C++CLI	~300ms (once)	~0.05ms	~30MB	~1,000,000+
gRPC Sidecar	~800ms (once)	~2–5ms	~100MB (separate)	~5,000–20,000
JNBridgePro	~400ms (once)	~0.1ms	~40MB	~500,000+

Key takeaway: If you're making more than a few calls per second, Process.Start is the wrong tool. The in-process methods (IKVM, JNI, JNBridgePro) are orders of magnitude faster for repeated calls.

Which Method Should You Use?

Follow this decision tree:

How many times do you call Java per request?

→ Once or never (batch job, CLI tool): Use Process.Start. Simple, built-in, and the startup cost doesn't matter for single invocations.

→ A few times (< 100/sec):

Already running microservices? → gRPC Sidecar
Monolith? → JNBridgePro or gRPC

→ Hundreds or thousands of times:

Pure Java library, no native deps? → Try IKVM first
IKVM doesn't cover your APIs? → JNBridgePro
Zero budget + C++ expertise? → JNI/C++CLI

Do you need bidirectional calls (Java calling back into .NET)?

→ JNBridgePro or JNI (painful)

Cross-platform requirement?

→ Process.Start, gRPC, IKVM, and JNBridgePro all work on Windows and Linux. JNI via C++/CLI is Windows-only (use P/Invoke on Linux).

How Do You Handle Java Dependencies from C#?

Build a fat JAR (using Maven Shade Plugin or Gradle Shadow) that bundles all dependencies into a single file. This gives you one JAR to reference in your classpath, regardless of which interop method you choose.

For IKVM, convert the fat JAR with ikvmc. For gRPC, package it in a container with all dependencies. For JNBridgePro, point the proxy generation tool at the fat JAR and it resolves all classes automatically.

Key pitfalls to avoid:

Classpath separator: Use ; on Windows, : on Linux/macOS
Spaces in paths: Always quote JAR paths
JAVA_HOME: Set it explicitly rather than relying on system PATH

// Correct cross-platform classpath construction

var separator = RuntimeInformation.IsOSPlatform(

    OSPlatform.Windows) ? ";" : ":";

var cp = string.Join(separator,

    jars.Select(j => $"\"{j}\""));

Can You Run Java from C# Without a JDK?

IKVM is the only method that doesn't require a JVM — it compiles Java bytecode to run directly on the CLR. Every other method needs at least a JRE:

Process.Start needs a JRE on the same machine
JNI and JNBridgePro need a JVM library (libjvm.so / jvm.dll)
gRPC needs a JRE wherever the Java sidecar runs (which can be a Docker container)

If eliminating the JVM dependency is your primary goal and the Java library is pure Java, IKVM is your best option. For everything else, bundle a JRE with your deployment or use a container.

Frequently Asked Questions

What is the best way to run Java from .NET in production?

It depends on your call pattern. For high-frequency calls in a monolithic app, an in-process bridge like JNBridgePro or IKVM gives the best latency. For cloud-native architectures, a gRPC sidecar provides cleaner operational boundaries. Process.Start is only suitable for infrequent, batch-style operations.

Can I run Java code in C# on Linux?

Yes. Process.Start and gRPC work on any OS. IKVM works cross-platform since it runs on the CLR. JNI works on Linux but requires P/Invoke instead of C++/CLI. JNBridgePro supports both Windows and Linux.

How do error and exception handling work across Java and C#?

Each method handles Java exceptions differently:

Process.Start: Check stderr and exit codes
IKVM: Java exceptions become .NET exceptions (type names preserved)
JNI: You must manually check and clear exceptions — unhandled ones crash the process
gRPC: Map Java exceptions to gRPC status codes
JNBridgePro: Java exceptions become .NET exceptions with original stack traces intact

Is there a free way to run Java from C# with low latency?

IKVM (open source) gives low latency for pure-Java libraries. JNI is free but demands significant C++ expertise. gRPC is free but adds network overhead. There's no free option that combines low latency, broad compatibility, and low maintenance — that's the gap commercial tools like JNBridgePro fill.

Wrapping Up

There's no single "best way to run Java from .NET" — it depends on how tightly you need Java and C# to interact:

Quick and dirty: Process.Start
Pure Java library, no native deps: Try IKVM
Microservices architecture: gRPC sidecar
Production integration, zero maintenance overhead: JNBridgePro
Maximum control, have C++ skills: JNI

Whatever you choose, match the integration depth to your actual requirements. Don't build a gRPC service layer when Process.Startwill do, and don't shell out tojava.exe` a thousand times per second when an in-process bridge exists.

Ready to try in-process Java/.NET integration? Download the JNBridgePro free trial →

Want to see it in action? Schedule a technical demo — we’ll walk through your specific Java libraries and show you working interop in real time.

Explore code samples and tutorials in the JNBridgePro Developer Center →

Originally published on the JNBridge blog.

C# JVM Guide: JDK, CLR & Java Interop for .NET

JNBridge — Mon, 04 May 2026 13:21:25 +0000

If you mostly live in .NET, the Java platform can look like a parallel universe: JVM, JDK, JARs, app servers, bytecode. The useful shortcut is to map each concept back to something you already know from C# and the CLR.

This guide is a translation layer for .NET developers: what the JVM is, how the JDK compares to the .NET SDK, and what your real options are when a C# system needs to work with Java code in production.

> TL;DR — Key Takeaways
>
> – The C# JVM equivalent is the Common Language Runtime (CLR) — both are managed-code virtual machines that handle bytecode execution, garbage collection, and JIT compilation.
> – The JDK maps directly to the .NET SDK — both bundle a compiler, runtime, and standard class library.
> – You cannot run C# directly on the JVM (or Java on the CLR) without translation tools.
> – The best way to bridge C# and Java in production is in-process interop — tools like JNBridgePro let you call Java objects from C# (and vice versa) without REST wrappers or rewrites.
> – IKVM is limited to Java 8 bytecode; for modern JDK versions, you need a commercially supported solution.

If you’re a .NET developer, you’ve almost certainly encountered the C# JVM question: how do these two platforms compare, can they interoperate, and what happens when your application needs both? This guide answers every part of that question from a .NET perspective.

We’ll walk through the Java platform — JVM, JDK, and J2EE — drawing clear parallels to the .NET ecosystem you already know. Then we’ll cover every realistic approach to bridging the C# JVM divide, from REST APIs to in-process interop with JNBridgePro.

What Is the JVM? (The .NET Developer’s Answer)

The JDK Explained for .NET Developers

CLR vs. JVM: Full Platform Comparison

What Is the Difference Between J2EE and ASP.NET?

Can C# Run on the JVM?

Can Java Run on the CLR? IKVM and GraalVM

How to Connect C# and Java: The 4 Real Options

When You Need In-Process C# JVM Bridging

Getting Started with JNBridgePro

FAQ: C# JVM, JDK, and .NET Java Interop

What Is the JVM? (The .NET Developer’s Answer)

The Java Virtual Machine (JVM) is Java’s equivalent of the Common Language Runtime (CLR). If you understand one, you already understand most of the other.

The CLR takes your compiled C# — in the form of Intermediate Language (IL) — and executes it. It handles memory management, garbage collection, JIT compilation, type safety, and threading. The JVM does the same thing for Java bytecode.

Both are stack-based virtual machines. Both use just-in-time compilation to convert their respective intermediate representations into native machine code at runtime. Both provide automatic memory management through garbage collection. The architectural similarities are not coincidental — the CLR was designed with full awareness of the JVM’s strengths and weaknesses.

Concept	.NET	Java
Source language	C#, F#, VB.NET	Java, Kotlin, Scala
Compiled to	IL (Intermediate Language)	Java bytecode
Executed by	CLR (Common Language Runtime)	JVM (Java Virtual Machine)
Compilation unit	Assembly (.dll / .exe)	JAR / class files

The key difference is openness. The JVM specification is an open standard with multiple competing implementations: Oracle’s HotSpot, Eclipse’s OpenJ9, Amazon’s Corretto, Azul’s Zulu, and GraalVM. The CLR historically had one implementation from Microsoft, though .NET is now open source and cross-platform.

Why This Matters to You

When someone says their library “runs on the JVM,” they mean it’s compiled to Java bytecode — just like when you say your library “targets .NET,” you mean it compiles to IL. The JVM is the execution engine, not the language. This is why languages like Kotlin and Scala can coexist with Java: they all compile to the same bytecode and run on the same managed code runtime.

The JDK Explained for .NET Developers

If the JVM is the CLR, then the Java Development Kit (JDK) is the .NET SDK.

The .NET SDK gives you everything needed to build .NET applications: the compiler (csc/dotnet build), the runtime (CLR), the base class libraries (BCL), and tooling. The JDK does the same for Java: it includes the Java compiler (javac), the JVM, the standard library, and development tools.

Component	.NET SDK	JDK
Compiler	Roslyn (`csc`)	`javac`
Runtime	CLR	JVM (HotSpot, etc.)
Standard library	BCL (Base Class Library)	Java Standard Library
Package format	NuGet (.nupkg)	JAR / Maven artifact
Build tool	MSBuild / `dotnet` CLI	Maven / Gradle
Package manager	NuGet	Maven Central
REPL	C# Interactive	`jshell` (JDK 9+)

There’s also the JRE (Java Runtime Environment) — a subset of the JDK containing only what’s needed to run Java applications. The .NET world had a similar split historically: you’d install the “.NET Framework Runtime” on servers and the full SDK on dev machines.

C# JDK Compatibility: What Version Do You Need?

Java now follows a six-month release cadence with Long-Term Support (LTS) versions every two years. As of 2026, the current LTS versions are Java 17, 21, and 25.

If you’re connecting C# to JVM-based systems, you’ll typically need JDK 11 or later installed. JNBridgePro supports a range of JDK versions — see the latest .NET 9 and Java 21 compatibility details.

CLR vs. JVM: Full Platform Comparison

Here’s a comprehensive side-by-side for .NET developers evaluating the .NET JVM landscape:

Feature	JVM / Java	CLR / .NET
Primary language	Java	C#
Other languages	Kotlin, Scala, Groovy, Clojure	F#, VB.NET
Runtime	JVM (HotSpot, OpenJ9, GraalVM)	CLR (.NET Runtime)
Intermediate format	Java bytecode (.class)	IL / MSIL (.dll)
Garbage collection	G1, ZGC, Shenandoah (pluggable)	Generational GC (workstation/server)
JIT compilation	C1/C2 tiered (HotSpot)	RyuJIT
AOT compilation	GraalVM Native Image	.NET Native AOT
Generics	Type erasure (no reification)	Reified (preserved at runtime)
Value types	Project Valhalla (preview)	Structs (first-class)
Properties	Convention-based getters/setters	Language-level `get`/`set`
Async model	Virtual Threads (Java 21+)	`async`/`await`
Enterprise framework	Jakarta EE (formerly J2EE)	ASP.NET Core
ORM	Hibernate, JPA	Entity Framework Core
Cross-platform	Yes (since inception)	Yes (.NET 5+)
License	OpenJDK (GPLv2+CE)	MIT License

A few things stand out:

Generics: Java’s type erasure means generic type information is lost at runtime. If you’ve relied on reflection over generic types in C#, you’ll find Java’s approach limiting.
Value types: C#’s struct has no direct Java equivalent yet — Project Valhalla is changing this.
Async: Instead of C#’s async/await state machines, Java 21 introduced Virtual Threads — lightweight threads managed by the JVM that make blocking code scale like async code.

What Is the Difference Between J2EE and ASP.NET?

J2EE (Java 2 Platform, Enterprise Edition) is Java’s enterprise application framework — the equivalent of ASP.NET Core plus the broader .NET enterprise ecosystem. J2EE defines specifications for servlets, EJBs, JMS messaging, JPA persistence, and more. It was renamed to Java EE and eventually transferred to the Eclipse Foundation as Jakarta EE.

The biggest architectural difference: Java enterprise apps deploy to an application server (Tomcat, WildFly, WebSphere) that provides runtime services. ASP.NET Core is self-hosted — your application is the server via Kestrel.

Java / Jakarta EE	.NET Equivalent
Servlets / JSP	ASP.NET Core MVC / Razor Pages
JAX-RS (REST APIs)	ASP.NET Core Web API
JPA / Hibernate	Entity Framework Core
JMS (Java Message Service)	Azure Service Bus, RabbitMQ
EJB (Enterprise JavaBeans)	DI + services (no direct equivalent)
CDI (Dependency Injection)	Microsoft.Extensions.DI
JSF (JavaServer Faces)	Blazor
Application Server (Tomcat)	Kestrel (self-hosted)

For .NET developers who need to integrate with J2EE or Jakarta EE services, understanding this architecture is critical. Many enterprise Java systems expose EJBs or JMS queues that don’t have REST endpoints. This is exactly where a C# to Java bridge tool becomes essential — it lets your .NET code call into Java objects directly, without requiring the Java side to expose web services.

Can C# Run on the JVM?

No — not directly. C# compiles to IL (Intermediate Language), which the CLR executes. The JVM executes Java bytecode — a completely different instruction set. You can’t take a .NET assembly and load it into the JVM any more than you can run an x86 binary on an ARM processor without translation.

There have been historical attempts:

Mainsoft Grasshopper (mid-2000s) compiled .NET bytecode to Java bytecode, allowing ASP.NET apps to run on Java application servers. It’s been dead for over a decade.
Cross-compilation is theoretically possible, but no one maintains such a tool today. The languages have diverged enough — value types, LINQ, async/await, properties, events — that faithful translation would be enormously complex.

The practical answer isn’t running C# on the JVM. It’s running C# and Java side by side and letting them communicate through a bridge. The right approach depends on your use case — see the bridging options below.

Can Java Run on the CLR? IKVM and GraalVM

IKVM.NET

IKVM was an open-source project that converted Java bytecode to .NET IL, letting you reference Java libraries as .NET assemblies. For simple libraries, it worked well.

The catch: IKVM supports only Java 8 bytecode. The original project went dormant around 2017. A community fork revived it with .NET Core support, but it still can’t handle Java 11+ features — modules, records, sealed classes, virtual threads. For production systems using modern Java, IKVM is not viable. See our detailed guide on migrating from IKVM to JNBridgePro.

GraalVM

GraalVM is Oracle’s polyglot virtual machine. Its Native Image tool can compile Java libraries into native shared libraries with C-compatible entry points, which C# can call via P/Invoke.

This works but requires significant effort: you must define the C API surface, handle marshaling manually, and deal with GraalVM’s closed-world assumptions. GraalVM is powerful technology, but it’s not designed to be a C# JVM bridge.

How to Connect C# and Java: The 4 Real Options

When your application needs both .NET and Java, here are your realistic choices:

1. REST APIs / Web Services

Wrap Java functionality in a REST API (Spring Boot, Quarkus) and call it from HttpClient.

✅ Works when the Java side is already a service
❌ Serialization overhead and network latency
❌ Two services to deploy, monitor, and scale
❌ Loss of type safety at the boundary

2. Message Queues (Kafka, RabbitMQ)

Good for asynchronous, event-driven architectures. Not suitable when you need synchronous method-level calls.

3. gRPC / Process-Level Interop

Run the JVM and CLR as separate processes communicating via gRPC or named pipes. Better than REST for performance, but still two processes and serialization overhead.

4. In-Process Bridging with JNBridgePro

JNBridgePro runs the JVM and CLR in the same process with direct, in-memory method calls. No serialization. No network hops. No REST wrappers.

“csharp // Call a Java HashMap from C# — via JNBridgePro proxy var map = new java.util.HashMap(); map.put("key", "value"); string result = (string)map.get("key");“

This isn’t calling a web service. The JVM is loaded in-process, and method calls cross the JVM-CLR boundary directly in memory — with full IntelliSense, type checking, and debugging support.

You can also call C# from Java using the same bridge, making it a bidirectional interop solution.

When You Need In-Process C# JVM Bridging

Let’s get specific about when in-process bridging beats a service boundary.

Java Libraries Without REST Wrappers

Your organization has a proprietary Java library for risk calculations, PDF generation, or scientific computation — 500,000 lines of battle-tested code with no REST API. With JNBridgePro, you reference the JAR directly from your .NET project. No wrapper needed.

Enterprise Java Systems (.NET J2EE Integration)

Your company runs enterprise Java — EJBs, JMS queues, JNDI lookups. Your new frontend is ASP.NET Core. These Java enterprise APIs weren’t designed for HTTP. JNBridgePro lets your C# code interact with J2EE components natively — look up an EJB, subscribe to a JMS queue — all from C#.

Incremental Migration

You’re migrating from Java to .NET (or vice versa). Running everything as microservices doubles your infrastructure complexity. In-process bridging lets you migrate one class at a time, with the bridge handling cross-platform calls during the transition.

Performance-Sensitive Integration

When milliseconds matter — financial systems, real-time analytics — HTTP serialization overhead is unacceptable. In-process calls via JNBridgePro happen in microseconds, not milliseconds.

> Why not just rewrite? Because rewrites fail. Joel Spolsky called it “the single worst strategic mistake any software company can make.” The code you’re replacing encodes years of bug fixes and domain knowledge. Bridging lets you use what works and build what’s new.

Getting Started with JNBridgePro

JNBridgePro supports two communication modes:

Shared memory (in-process) — The JVM runs inside your .NET process. Fastest integration with zero serialization overhead. Ideal for library-level calls.

TCP/IP — JVM and CLR run in separate processes or on separate machines. Use when in-process hosting isn’t feasible.

The setup workflow:

Install JNBridgePro and point it at your Java classes (JARs or class directories)

Generate .NET proxies using the GUI or command-line tool — creates C# classes mirroring the Java API

Reference the proxy assembly from your .NET project

Write C# code that calls Java objects through the proxies — with full IntelliSense and debugging

No Java code changes required. No REST endpoints to build. No serialization formats to define.

FAQ: C# JVM, JDK, and .NET Java Interop

Does C# run in a VM similar to Java’s JVM?

Yes. C# runs on the Common Language Runtime (CLR), which serves the same role as the JVM. Both are managed-code virtual machines that execute an intermediate bytecode format, provide automatic garbage collection, enforce type safety, and use JIT compilation to generate native machine code at runtime. The CLR executes IL (Intermediate Language); the JVM executes Java bytecode. They are architecturally parallel but not interchangeable — code compiled for one cannot run on the other without a bridge like JNBridgePro.

What is the equivalent of the JVM in C#?

The CLR (Common Language Runtime) is the C# JVM equivalent. Both are stack-based virtual machines that compile an intermediate representation to native code at runtime. The key difference: the JVM was built for Java specifically, while the CLR was designed to be language-neutral, supporting C#, F#, and VB.NET from the start.

Can you compile C# to run on the JVM?

No — there is no maintained tool that compiles C# to JVM bytecode. Historical projects like Mainsoft Grasshopper attempted this but are long abandoned. The practical solution is interop, not porting: run both runtimes and bridge them using JNBridgePro, REST APIs, or gRPC.

What happened to IKVM? Can it replace a C# JVM bridge?

IKVM converted Java bytecode to .NET IL, allowing Java libraries to run on the CLR. The original project went dormant around 2017; a community fork revived it with .NET Core support but remains limited to Java 8. For modern Java (11+), enterprise integration, or production systems, JNBridgePro is the recommended alternative.

How does JNBridgePro handle C# JDK compatibility?

JNBridgePro is regularly updated to support new JDK releases — including Java 21 with .NET 9. It works with the JDK you already have installed. The proxy generation tool reads your Java classes regardless of JDK version (within supported ranges), and the runtime bridge handles all type conversion and marshaling between the CLR and JVM.

Does the .NET SDK include JVM or JDK support?

No. The .NET SDK and the JDK are completely separate toolkits. To work with both platforms, install them independently and use a bridging tool for interop.

The practical takeaway

For many teams, the right answer is still a service boundary: HTTP, gRPC, queues, or another explicit integration layer. But when you need object-level calls, shared types, low-latency execution, or access to an existing Java library without rewriting it, you need something closer than another API wrapper.

That is where Java/.NET bridging earns its keep: keep both runtimes, keep the working code, and connect them intentionally.

How to Use Java JARs and .NET DLLs Across Platforms

JNBridge — Thu, 30 Apr 2026 13:23:37 +0000

If you have ever tried to mix a Java JAR into a .NET app — or call a .NET DLL from Java — you quickly hit the same wall: the files look like libraries, but the runtimes do not understand each other.

For developers, the useful question is architectural: do you wrap a process, expose REST/gRPC, drop into JNI/PInvoke, translate bytecode, or use an in-process bridge? Here are the tradeoffs a working team actually needs to choose between them.

TL;DR / Key Takeaways

– You cannot directly reference a JAR in C# or import a .NET DLL in Java — the runtimes are incompatible.

– Process wrapping is the fastest to set up but slowest at runtime (~50–200 ms per call).

– REST/gRPC wrappers work well for loosely coupled, low-frequency calls.

– IKVM converts Java bytecode to .NET IL but is stuck on Java 8 with no commercial support.

– JNBridgePro provides in-process bridging at ~8 µs per call with full object access and enterprise support.

Using a JAR in C# is one of the most common cross-platform interop challenges developers face. Whether you need to call a Java library from a .NET application or load a .NET DLL in a Java project, the two runtimes — JVM and CLR — don’t speak the same language. This guide covers every production-ready method for Java/.NET interoperability, with real code, performance benchmarks, and honest trade-offs.

Why JARs and DLLs Are Incompatible
Method 1: Process Wrapping (Quick and Dirty)
Method 2: REST/gRPC Service Wrapper
Method 3: JNI — Low-Level Native Bridge
Method 4: IKVM (Java on .NET — Legacy)
Method 5: JNBridgePro (In-Process Runtime Bridge)
How Do JAR-to-DLL Interop Methods Compare?
Which Method Should You Choose?
Common Pitfalls: Classpath, Type Mapping, and Memory
FAQ
Get Started

Why JARs and DLLs Are Incompatible

Java JARs contain bytecode compiled for the JVM. .NET DLLs contain MSIL compiled for the CLR. These are fundamentally different execution environments with separate memory management, type systems, and native interop models.

Aspect	Java JAR	.NET DLL (Assembly)
Runtime	JVM (Java Virtual Machine)	CLR (Common Language Runtime)
Bytecode format	Java bytecode (.class)	CIL (.dll assemblies)
Memory management	JVM garbage collector	.NET garbage collector
Type system	Java type system	Common Type System (CTS)
Native interop	JNI	P/Invoke, COM Interop

You can’t “Add Reference” to a JAR in Visual Studio or import a .NET assembly in Java. You need a runtime bridge, a service wrapper, or a bytecode translator. Here are your five options — from simplest to most powerful.

Method 1: Process Wrapping (Quick and Dirty)

The simplest approach to using a JAR in C#: launch a separate java process and capture its output.

Running a Java JAR from C


using System.Diagnostics;

public class JavaRunner

{

public static string RunJar(string jarPath, string args)

{

var process = new Process

{

StartInfo = new ProcessStartInfo

{

FileName = "java",

Arguments = $"-jar {jarPath} {args}",

RedirectStandardOutput = true,

RedirectStandardError = true,

UseShellExecute = false,

CreateNoWindow = true

}

};

process.Start();

string output = process.StandardOutput.ReadToEnd();

process.WaitForExit();

if (process.ExitCode != 0)

throw new Exception($"Java process failed: {process.StandardError.ReadToEnd()}");

return output;

}

}

For a deeper walkthrough, see How to Run a Java JAR from C#.

Running a .NET DLL from Java


import java.io.*;

public class DotNetRunner {

public static String runDotNet(String dllPath, String args) throws Exception {

ProcessBuilder pb = new ProcessBuilder("dotnet", dllPath, args);

pb.redirectErrorStream(true);

Process process = pb.start();

BufferedReader reader = new BufferedReader(

new InputStreamReader(process.getInputStream()));

StringBuilder output = new StringBuilder();

String line;

while ((line = reader.readLine()) != null)

output.append(line).append("\n");

if (process.waitFor() != 0)

throw new RuntimeException("dotnet process failed");

return output.toString();

}

}

Pros: Simple, no dependencies, works everywhere.

Cons: Slow (~50–200 ms startup per call), limited to string I/O, no direct object access, no marshaling of complex types, crude error handling.

Best for: One-off batch jobs, scripts, quick prototypes.

Method 2: REST/gRPC Service Wrapper

Wrap your Java or .NET code as a microservice and call it over HTTP or gRPC. This avoids the per-call process startup overhead but adds network serialization latency.

Exposing a Java JAR as a REST API


@RestController

public class AnalyticsController {

private final AnalyticsEngine engine; // from your JAR

@PostMapping("/analyze")

public AnalysisResult analyze(@RequestBody DataSet data) {

return engine.process(data);

}

}

Calling It from C\


var client = new HttpClient { BaseAddress = new Uri("http://localhost:8080") };

var result = await client.PostAsJsonAsync("/analyze", dataset);

var analysis = await result.Content.ReadFromJsonAsync();

Pros: Clean separation, language-agnostic, independently scalable.

Cons: Network latency (~0.3–5 ms even on localhost), serialization overhead, operational complexity of running a separate service.

For a detailed comparison of bridging vs. REST vs. gRPC, see Bridge vs REST vs gRPC for Java/.NET Integration.

Best for: Loosely coupled systems, infrequent calls, existing microservice architectures.

Method 3: JNI — Low-Level Native Bridge

The Java Native Interface (JNI) lets Java call native code. You can chain it: Java ↔ JNI ↔ C/C++ ↔ P/Invoke ↔ .NET. Technically possible, practically painful.


Java ←→ JNI ←→ Native C/C++ ←→ P/Invoke ←→ .NET CLR


// Native bridge (C) — simplified

JNIEXPORT jstring JNICALL Java_Bridge_callDotNet(

JNIEnv *env, jobject obj, jstring input) {

// Load CLR, locate assembly, invoke method, marshal result

// ... hundreds of lines of platform-specific boilerplate ...

}

Pros: Near-native performance, no network overhead.

Cons: Extremely complex — manual memory management, type marshaling nightmares, platform-specific builds, debugging across three runtimes.

Best for: Almost nobody. Only justified when you need absolute maximum performance and have deep C/C++ expertise.

Method 4: IKVM (Java on .NET — Legacy)

IKVM was an open-source project that translated Java bytecode to .NET IL, letting you reference JARs directly as .NET assemblies.


# Convert JAR to DLL (IKVM)

ikvmc -target:library analytics.jar -out:Analytics.dll


// Then use Java classes like C# classes

using com.example.analytics;

var engine = new AnalyticsEngine();

var result = engine.process(data);

Current status: IKVM is stuck on Java SE 8 (2014 APIs). Libraries using Java 11+ features — records, virtual threads (Java 21), modern java.time — won't work. A community fork (ikvm-revived) has made progress but lacks production readiness and commercial support.

If you're currently on IKVM and hitting limitations, see Migrating from IKVM to JNBridgePro.

Best for: Legacy situations with Java 8 libraries only — and tolerance for risk.

Method 5: JNBridgePro (In-Process Runtime Bridge)

JNBridgePro runs both the JVM and CLR in the same process, creating proxy classes that let you use Java objects from C# (and vice versa) as if they were native. No serialization. No network. Direct reflection-based type mapping with full access to properties, methods, fields, exceptions, and callbacks.

Using a Java JAR in C\


// After generating .NET proxies for your JAR:

using com.example.analytics;

var engine = new AnalyticsEngine();

var config = new AnalysisConfig();

config.setThreshold(0.95);

config.setMode("comprehensive");

// Direct method calls — no serialization, no network

AnalysisResult result = engine.process(dataset, config);

Console.WriteLine($"Score: {result.getScore()}");

Console.WriteLine($"Items: {result.getResults().size()}");

Using a .NET DLL in Java


// After generating Java proxies for your .NET assembly:

import system.io.FileStream;

import system.io.StreamReader;

FileStream fs = new FileStream("data.bin", FileMode.Open);

StreamReader reader = new StreamReader(fs);

String content = reader.ReadToEnd();

reader.Close();

For step-by-step tutorials, see How to Call Java from C# and How to Call C# from Java.

Pros: ~8 µs per call, direct object access, full type mapping, supports modern Java (11, 17, 21) and .NET (6, 7, 8), commercial support with SLAs.

Cons: Commercial license required, proxy generation step, JVM + CLR in same process uses more memory.

Best for: Enterprise integration — high-frequency calls, complex object graphs, regulated industries (finance, healthcare).

How Do JAR-to-DLL Interop Methods Compare?

| | Method | Latency / Call | Setup | Object Access | Modern Java/C# | Production Ready |
|---|---:|---|---|---|---|
| Process wrapping | ~50–200 ms | ⭐ Easy | ❌ String only | ✅ | ⚠️ Fragile |
| REST/gRPC | ~0.3–5 ms | ⭐⭐ Moderate | ❌ Serialized | ✅ | ✅ |
| JNI (manual) | ~0.1 ms | ⭐⭐⭐⭐⭐ Expert | ⚠️ Limited | ✅ | ⚠️ Risky |
| IKVM | ~0.01 ms | ⭐⭐ Moderate | ✅ Full | ❌ Java 8 only | ❌ Unmaintained |
| JNBridgePro | ~0.008 ms | ⭐⭐ Moderate | ✅ Full | ✅ | ✅ Enterprise |

For 10,000 calls: Process wrapping takes 8–33 minutes. REST takes 3–50 seconds. JNBridgePro takes 0.08 seconds.

Which Method Should You Choose?

Use Process Wrapping if you need a quick one-off integration, calls are infrequent (batch processing), and you don't need direct Java object access from .NET.

Use REST/gRPC if your systems are loosely coupled, you're already in a microservices architecture, or calls happen fewer than 100 times per second.

Use JNBridgePro if:

You need to call Java/.NET code thousands of times per second
You need direct access to object properties, methods, and callbacks
You're integrating complex libraries — not just simple functions
You need commercial support and SLAs
You're in a regulated industry that requires vendor backing

Avoid JNI unless you have deep C/C++ expertise and a very specific performance requirement.

Avoid IKVM unless you work exclusively with Java 8-era libraries and accept the risk of an unmaintained project.

Common Pitfalls: Classpath, Type Mapping, and Memory

1. Classpath Issues When Loading JARs

When loading JARs from .NET — via Process wrapping or JNBridgePro — ensure all dependency JARs are on the classpath:


// ❌ Wrong — missing dependencies

process.StartInfo.Arguments = "-jar analytics.jar";

// ✅ Right — include all JARs on the classpath

var classpath = "analytics.jar;lib/commons-math3.jar;lib/slf4j-api.jar";

process.StartInfo.Arguments = $"-cp {classpath} com.example.Main {args}";

2. Type Mapping Gotchas Between Java and C\

Java and .NET have subtly different type systems. Watch these carefully during interop:

Java Type	C# Equivalent	Gotcha
`byte`	`sbyte`	Java byte is signed (−128 to 127)
`char`	`char`	Both UTF-16, but Java char is unsigned
`BigDecimal`	`decimal`	Different precision semantics
`LocalDate`	`DateOnly`	Different APIs, same concept
`long` / `Long`	`long`	Same size, but Java's boxed `Long` ≠ C# `long`

3. Memory Management Across Runtimes

When bridging Java and .NET, each runtime has its own garbage collector. Objects on one side won't be collected until proxy references on the other side are released. In long-running applications, failing to dispose cross-runtime references can cause memory leaks.

FAQ

Can I Directly Reference a JAR File in Visual Studio?

No. Visual Studio doesn't natively understand Java JAR files. JAR files contain Java bytecode, which the .NET CLR cannot execute. You need either a bytecode translator like IKVM (limited to Java 8) or a runtime bridge like JNBridgePro that generates .NET proxy classes wrapping the JAR's contents. The proxies let you call Java methods from C# with full IntelliSense and type safety.

Can Java Load and Call Methods in a .NET DLL?

Not directly. Java's classloader only understands Java bytecode in .class format. To load a .NET DLL in Java, you need one of three approaches: a service wrapper (REST/gRPC), a native bridge through JNI, or JNBridgePro which generates Java proxy classes for .NET assemblies — giving you direct access to .NET objects from Java code.

What’s the Performance Difference Between REST and In-Process Bridging?

REST calls add network overhead even on localhost — typically 0.3–5 ms per call including serialization and marshaling. In-process bridging with JNBridgePro operates at ~8 microseconds per call with zero serialization. For 10,000 calls, that’s 3–50 seconds via REST versus 0.08 seconds via bridge — a 60× to 600× improvement.

Is IKVM Still Maintained?

The original IKVM project ended in 2017. A community fork (ikvm-revived) exists and has made progress, but it’s not production-ready for Java 11+ and has no commercial support. For production workloads requiring modern Java, consider migrating from IKVM.

Can I Use a Java JAR in .NET Without Installing the JDK?

With IKVM (Java 8 only), yes — it converts Java bytecode to .NET IL, so no JVM is needed. With all other approaches (Process, JNBridgePro, JNI), you need a JRE/JDK. JNBridgePro can use an embedded JRE, simplifying deployment.

What About Javonet or jni4net?

Javonet offers a reflection-style API for calling .NET from Java (and vice versa). jni4net is an open-source JNI-based bridge but hasn’t been updated since 2015. JNBridgePro differs by providing compile-time proxy generation with full type mapping, IntelliSense support, and enterprise-grade reliability.

Get Started

Ready to integrate Java JARs in your .NET project — or .NET DLLs in Java?

👉 Download the JNBridgePro free trial and see how in-process bridging compares to your current approach. Most teams have a working integration within a day.

📚 Explore the JNBridgePro Developer Center for demos, tutorials, and sample projects.

💬 Have questions? Contact the JNBridge team for architecture guidance or licensing details.

If your use case needs direct calls across the Java/.NET boundary rather than a service wrapper, the original JNBridge guide includes the full production-oriented comparison and examples: How to Use Java JARs and .NET DLLs Across Platforms.

Anatomy of a Shared Memory Bridge: How .NET Calls Java In-Process

JNBridge — Mon, 27 Apr 2026 13:21:04 +0000

A lot of Java/.NET integration advice starts with “just make it an API.” That works until the call path is fine-grained, latency-sensitive, or tied to desktop/server code that already runs on the same machine.

For those cases, shared memory is worth understanding. This walkthrough breaks down what an in-process Java/.NET bridge actually needs: proxy assemblies, runtime DLLs, JVM configuration, Java-side JARs, and the architecture checks that prevent painful startup failures.

What We're Building

We'll dissect a .NET application that calls into a Java class using JNBridgePro with shared memory. If you need to call Java from a .NET project, understanding these pieces is essential.

The goal is to make the moving parts visible:

How a proxy connects the .NET and Java worlds
What files live on each side
Key considerations for shared memory setups

Note: Switching this project to TCP, including SSL, IP/class whitelisting, and Java-side startup, is covered in the related TCP configuration guide on the JNBridge site.

Project Layout

The directory structure has two main areas:

.NET project (BridgeDemo) — the C# application, configuration, and runtime DLLs
Java side — the original Java class plus supporting JARs and properties

Think of the .NET project as the caller and the Java side as the runtime payload being loaded and invoked.

.NET Side: Calling Java with Shared Memory

The .NET side is built around referenced assemblies, supporting DLLs, and an App.config that defines how the bridge locates Java.

Referenced Assemblies

bridgeDemo.dll — the generated proxy assembly that exposes the Java class to .NET
JNBShare.dll — the core bridge library required for JNBridge communication

Both are added under References in Visual Studio with Copy Local = True, so they land in the output folder automatically. That lets BridgeDemo.exe find them at runtime without extra machine-level setup.

Supporting DLLs

JNBSharedMem_x86.dll / JNBSharedMem_x64.dll — required only for the Shared Memory transport
jnbauth_x86.dll / jnbauth_x64.dll — used internally by the bridge for authentication and setup

These are not referenced in the project. They simply need to be present in the same directory as BridgeDemo.exe.

App.config

At runtime, BridgeDemo.exe reads this config to tell JNBridge how to locate and load the Java side:

<jnbridge>
  <dotNetToJavaConfig
    scheme="sharedmem"
    jvm64="C:\Program Files\Java\jdk-25\bin\server\jvm.dll"
    jnbcore="C:\Projects\BridgeDemo\Java Side\jnbcore.jar"
    bcel="C:\Projects\BridgeDemo\Java Side\SharedMemory\bcel-6.10.0.jar"
    classpath="C:\Projects\BridgeDemo\Java Side;C:\Projects\BridgeDemo\Java Side\javaToCall.jar;"
  />
</jnbridge>

Key attributes:

Attribute	Purpose
`scheme`	Transport type: `sharedmem` or `tcp`
`jvm64`	Path to the 64-bit JVM (`jvm32` for 32-bit)
`jnbcore`	Path to `jnbcore.jar`, the bridge runtime
`bcel`	Required for Shared Memory; omitted for TCP
`classpath`	Where JNBridge finds your Java classes or JARs

The classpath determines whether the .NET side connects to a package directory with .class files, a JAR, or both.

Java Side

The Java side hosts the actual code and bridge runtime that the .NET process connects to.

Core and Supporting JARs

jnbcore.jar — always required; contains the bridge runtime and handles communication
bcel-6.10.0.jar — only needed for Shared Memory transport

Java Code or Packaged JAR

Depending on your build, you'll have either:

A package directory such as BridgeDemo/ with .class files
A JAR archive such as BridgeDemo.jar with compiled classes

Which one gets used depends on the classpath in the .NET project's App.config.

Java-Side Properties File

The properties file, for example javaSide.properties, controls how the JVM runs the bridge:

javaSide.serverType=sharedmem
javaSide.timeout=10000
javaSide.port=8085
javaSide.useClassWhiteList=false
javaSide.classWhiteListFile=./classWhiteList.txt
javaSide.useSSL=false

Some entries, like port and SSL, matter more for TCP mode. Keeping them visible in the properties file helps when you later switch transports or compare configurations.

Considerations for Shared Memory Setups

Shared Memory provides the fastest .NET↔Java communication because both runtimes share the same process. The tradeoff is that setup details matter more.

Architecture Matching

The JVM architecture must match your .NET build target:

64-bit .NET → use 64-bit jvm.dll
32-bit .NET → use 32-bit jvm.dll

Supporting DLLs must also match:

JNBSharedMem_x86.dll / JNBSharedMem_x64.dll
jnbauth_x86.dll / jnbauth_x64.dll

If your app targets AnyCPU, include all four DLLs so the bridge can load the correct pair at runtime. For single-architecture builds, you can safely omit the unused set.

Keep Bridge DLLs Beside the Executable

All bridge DLLs must reside in the same directory as your executable:

JNBShare.dll
JNBSharedMem_x*.dll
jnbauth_x*.dll

No GAC tricks, no hidden machine-wide assumptions — just make the output folder complete.

Handling `ClassNotFoundException` and `NoClassDefFoundError`

These errors during shared-memory startup usually come from one of two issues.

1. Permissions

Ensure the user running the app has:

Read & Execute
List Folder Contents
Read access

That access needs to cover all Java class and JAR folders, including jnbcore.jar, bcel-6.x.x.jar, and any app JARs. Missing access can prevent the JVM from loading classes, especially under ASP.NET or service accounts.

2. Classloader conflicts on Java 8 and earlier

If permissions check out but errors persist, move the affected .jar from the regular classpath to the boot classpath:

<jnbridge>
  <dotNetToJavaConfig
    scheme="sharedmem"
    jvm64="C:\Program Files\Java\jdk-25\bin\server\jvm.dll"
    jnbcore="C:\Projects\BridgeDemo\Java Side\jnbcore.jar"
    bcel="C:\Projects\BridgeDemo\Java Side\SharedMemory\bcel-6.10.0.jar"
    classpath="C:\Projects\BridgeDemo\Java Side;"
    jvmOptions.0="-Xbootclasspath/p:C:\Projects\BridgeDemo\Java Side\javaToCall.jar"
  />
</jnbridge>

Here javaToCall.jar was removed from the classpath and added to the boot classpath, letting the JVM load it earlier.

Important caveat: -Xbootclasspath/p: only works through Java 8. It was removed in Java 9+.

Shared Memory vs TCP

Shared memory is usually the right fit when:

Java and .NET run on the same machine
Calls are frequent or latency-sensitive
You want method-level integration rather than coarse-grained service calls
You can control architecture alignment and deployment layout

TCP is usually better when:

Java and .NET run in separate processes or on separate machines
You need network-level isolation
You want SSL, IP whitelisting, or explicit Java-side startup
Operational flexibility matters more than same-process latency

Wrapping Up

Shared memory is the fastest transport option for Java/.NET integration: no network hop, no JSON serialization, and no separate service boundary. The price is stricter runtime alignment and careful file placement.

If your systems already live on the same machine and you need direct method calls across the Java/.NET boundary, shared memory is hard to beat. If you need process or network separation, use TCP instead.

Original WordPress version: Call Java from .NET Project: Anatomy of a Shared Memory Bridge

I Let an AI Set Up My Java/.NET Bridge Project — Here's What Happened

JNBridge — Fri, 03 Apr 2026 13:09:11 +0000

Setting up a Java/.NET bridge project from scratch is one of those tasks that shouldn't be hard but somehow always is. Proxy generation, classpath wiring, transport configuration, build scripts — there are enough moving parts that you'll spend your first afternoon just getting "Hello World" to compile.

So we tried something different: we pointed Claude Code at a reference project, gave it a CLAUDE.md file documenting every file and build step, and let it handle the wiring. The result was surprisingly good.

What the Reference Project Does

The project is a .NET Framework console app that calls Java's log4j logging library and a custom Java class through JNBridge-generated proxy DLLs. It's organized into three folders:

Java source — your Java classes
Proxy generation tooling — JNBridge's proxy generator config
The .NET project — the C# app that calls into Java

Orchestrator scripts build and run everything in one step.

The key file is CLAUDE.md. It documents every file, every build step, and every configuration flag. This means Claude Code understands the full project structure — when you ask it to swap in a different Java library or change the transport mode, it knows exactly which files to touch and why.

Two Transport Modes: Pick Your Architecture

The demo ships with two build scripts, each demonstrating a different JNBridge transport mode.

Shared Memory Mode (In-Process)

buildAndRunSharedMem.bat embeds the JVM directly inside the .NET process. No separate Java process to manage.

The pipeline:

Compiles Java source → packages into a JAR
Generates .NET proxy DLLs (JNBridge scans your JARs and creates C# wrapper classes)
Builds the C# project with dotnet build
Generates runtime config — injects JVM paths from env.bat
Runs the demo

This is the fastest option — no network overhead, no serialization. Your .NET code calls Java methods like they're native .NET calls.

TCP Mode (Separate Process)

buildAndRunTCP.bat runs Java as a separate process and connects over TCP (port 8085). Useful when you need to:

Debug the Java side independently
Run Java on a different machine
Isolate the JVM from the .NET process

Same build pipeline, but it swaps in TCP config, launches the Java side in a separate console window, and cleans up when the demo exits.

Getting Started

1. Install JNBridgePro

Download JNBridgePro and run the installer.

Then grab the demo project with CLAUDE.md.

2. Get a License

After installation, run the JNBridge registration tool:

Go to Registration Key → copy registration key
Select "Request License" to complete the online request
License arrives via email — drop it in the build directory

3. Edit One File

Open env.bat at the project root and set your Java home:

set JAVA_HOME=C:\Program Files\Java\jdk1.8.0_202

That's it. All build scripts read their Java paths from this one file.

4. Run It

Double-click buildAndRunSharedMem.bat. If everything's set up correctly, you'll see .NET calling Java.

The AI Part: Why CLAUDE.md Matters

This is where the project gets interesting for the Dev.to crowd.

The CLAUDE.md file is essentially a machine-readable project handbook. Open Claude Code in the project directory and tell it what you want:

"Swap log4j for my JDBC driver"
"Add a new Java class to the proxies"
"Switch to TCP mode"

Claude Code reads the documentation and knows the full build pipeline, so it can make the right changes across all the files without you having to trace through the wiring yourself.

This pattern — documenting your project structure in a way that AI tools can consume — is something I think we'll see a lot more of. It's not just about Java/.NET integration; any project with complex build pipelines benefits from having a CLAUDE.md (or equivalent) that maps out the dependency graph.

Try It

If you're working on Java/.NET interop — or just curious about using AI to manage complex project setups — give it a spin and let me know how it goes in the comments.

Calling Java from VB.NET: Every Option from REST to In-Process Bridging

JNBridge — Mon, 30 Mar 2026 13:37:45 +0000

If you've ever Googled "call Java from VB.NET" and gotten nothing but abandoned StackOverflow threads from 2014, you're not alone. VB.NET is quietly running millions of enterprise apps — financial platforms, healthcare systems, logistics — and those teams increasingly need to tap into Java libraries they can't rewrite.

I spent a week mapping out every approach that actually works in 2026. Here's what I found.

The Problem: Two Runtimes, No Shared Anything

VB.NET runs on the .NET CLR. Java runs on the JVM. They don't share memory, type systems, or calling conventions. If you need Apache PDFBox for PDF generation, or a proprietary Java pricing engine your company spent years building, you can't just Imports com.acme.pricing and go.

Or can you?

Option 1: REST/HTTP APIs

The obvious approach — wrap your Java code in a Spring Boot service, call it via HttpClient.

Pros: Language-agnostic, works across networks, everyone understands HTTP.

Cons: 2-15ms per call. JSON serialization overhead. You need a separate running Java service. Fine for occasional calls, painful when you're making thousands per second.

' The REST approach — works but adds overhead
Dim client As New HttpClient()
Dim response = Await client.GetAsync("http://localhost:8080/api/price?product=ABC")
Dim json = Await response.Content.ReadAsStringAsync()

Option 2: gRPC

Binary protocol, Protocol Buffers, lower latency than REST.

Pros: ~0.5-2ms per call, strongly typed, streaming support.

Cons: Still needs a separate Java process. Protobuf schema management. VB.NET gRPC support exists but isn't as polished as C#'s.

Option 3: Message Queues

Publish/subscribe through RabbitMQ or Kafka. Async by nature.

Pros: Decoupled, scalable, resilient.

Cons: Not suitable for synchronous request/response. More infrastructure to manage. Overkill when you just need to call a method and get a result.

Option 4: In-Process Bridge (the one I'd pick)

A bridge like JNBridgePro loads the JVM directly into your .NET process and generates .NET proxy classes for Java objects. Your VB.NET code calls Java methods with native syntax — no HTTP, no serialization, no separate service.

' Java's HashMap, used natively from VB.NET
Imports java.util

Dim map As New HashMap()
map.put("key", "value")
Dim result As String = CStr(map.get("key"))

That's not pseudocode. That actually compiles and runs.

Real Code: PDFBox from VB.NET

Apache PDFBox is Java's go-to PDF library. With proxy classes generated, VB.NET uses it directly:

Imports org.apache.pdfbox.pdmodel
Imports org.apache.pdfbox.pdmodel.font

Public Sub CreatePDF()
    Dim document As New PDDocument()
    Dim page As New PDPage()
    document.addPage(page)

    Dim contentStream As New PDPageContentStream(document, page)
    contentStream.setFont(PDType1Font.HELVETICA_BOLD, 14)
    contentStream.beginText()
    contentStream.newLineAtOffset(50, 700)
    contentStream.showText("Generated from VB.NET via JNBridgePro")
    contentStream.endText()
    contentStream.close()

    document.save("C:\output\report.pdf")
    document.close()
End Sub

No REST endpoint. No separate service. Just call the Java API like it's a .NET library.

Real Code: Apache Kafka Producer

Instead of hunting for a third-party .NET Kafka client, use the official Java client directly:

Imports org.apache.kafka.clients.producer
Imports java.util

Public Sub SendKafkaMessage(topic As String, message As String)
    Dim props As New Properties()
    props.put("bootstrap.servers", "kafka-broker:9092")
    props.put("key.serializer", _
        "org.apache.kafka.common.serialization.StringSerializer")
    props.put("value.serializer", _
        "org.apache.kafka.common.serialization.StringSerializer")

    Dim producer As New KafkaProducer(props)
    Dim record As New ProducerRecord(topic, "key", message)
    producer.send(record)
    producer.flush()
    producer.close()
End Sub

Real Code: Proprietary Java Business Logic

The most common scenario — your org has a Java pricing engine or risk model that took years to build. Rewriting it in VB.NET isn't realistic.

Imports com.acme.pricing

Public Function CalculatePrice(productId As String, quantity As Integer) As Decimal
    Dim engine As New PricingEngine()
    engine.loadRules("pricing-rules-2026.xml")

    Dim request As New PriceRequest()
    request.setProductId(productId)
    request.setQuantity(quantity)
    request.setCurrency("USD")

    Dim result As PriceResult = engine.calculate(request)
    Return CDec(result.getTotalPrice())
End Function

Performance Comparison

For apps making frequent cross-runtime calls, this matters:

Method	Latency/Call	Throughput	Best For
REST/HTTP	2-15ms	~500-2K/sec	Loose coupling, cross-network
gRPC	0.5-3ms	~2K-10K/sec	High-throughput microservices
In-process bridge (shared mem)	0.01-0.1ms	~50K-500K/sec	Tight integration, real-time
In-process bridge (TCP)	0.1-1ms	~5K-50K/sec	Cross-process deployment

The shared-memory bridge is 100-1000x faster than REST for individual calls. Negligible for occasional calls — transformative when your VB.NET app is doing real-time pricing or batch data processing.

Architecture Pattern: Wrapper Service Layer

My recommendation — create a VB.NET wrapper class that isolates all Java calls. The rest of your app gets a clean .NET API:

Public Class JavaPricingService
    Private _engine As PricingEngine

    Public Sub New()
        _engine = New PricingEngine()
        _engine.loadRules("pricing-rules-2026.xml")
    End Sub

    Public Function GetPrice(productId As String, qty As Integer) As Decimal
        Dim request As New PriceRequest()
        request.setProductId(productId)
        request.setQuantity(qty)
        Return CDec(_engine.calculate(request).getTotalPrice())
    End Function
End Class

Your application code never needs to know it's talking to Java under the hood.

Mixed Teams? Same Proxies Work in C

If your team uses both VB.NET and C#, the proxy assembly is language-agnostic:

// Same Kafka example in C# — same proxy DLL
var props = new Properties();
props.put("bootstrap.servers", "kafka-broker:9092");
var producer = new KafkaProducer(props);
producer.send(new ProducerRecord(topic, "key", message));

Generate once, use from any .NET language.

Watch Out For

JVM Memory — The JVM runs inside your .NET process. Set -Xmx appropriately or you'll get mysterious OOM crashes.
Thread Safety — Java objects follow Java's threading model. If the Java library isn't thread-safe, use SyncLock or per-thread instances on the VB.NET side.
Classpath Issues — The #1 setup problem. Use jdeps to find transitive dependencies you're missing.
Exception Translation — Java exceptions become .NET exceptions through the bridge. Catch JNBException for bridge errors, original Java types for app errors.

Getting Started

Download JNBridgePro (free evaluation)
Generate proxies for your Java classes
Add references to your VB.NET project
Write code using native VB.NET syntax
Deploy — both JVM and CLR must be present on target

Works with .NET Framework and .NET Core/.NET 8/9. If you're migrating from Framework to modern .NET, your Java integration code carries over.

Have questions about VB.NET + Java integration? Drop them in the comments — I'll answer from production experience.

JNBridgePro vs IKVM vs Javonet: Java/.NET Bridge Comparison (2026)

JNBridge — Sat, 28 Mar 2026 13:05:01 +0000

I've been deep in the Java/.NET integration space for years, and the one question that comes up more than anything: which bridge tool should I actually use? IKVM? JNBridgePro? Javonet? Something else entirely?

The answer depends on your Java version, deployment model, and how much you value long-term support. Here's an honest breakdown of all three — plus alternatives you should know about.

Why Compare Java/.NET Bridges?

Java/.NET bridges solve a common enterprise problem: your organization runs both Java and .NET codebases, and they need to communicate. Instead of rewriting code or building REST/gRPC wrappers, a bridge enables direct method calls between the two runtimes.

But bridges differ dramatically in architecture, performance characteristics, Java version support, and long-term viability. Choosing the wrong one can mean a forced migration later — exactly the kind of disruption you're trying to avoid.

Quick Comparison Table

Feature	JNBridgePro	IKVM	Javonet
Architecture	In-process bridge (JVM + CLR)	Bytecode translation (Java → CIL)	Cross-runtime invocation
Java Version Support	Java 8–21+	Java SE 8 only	Java 8+
.NET Support	Framework + Core/.NET 8/9	Framework, partial Core	Framework + Core
Uses Real JVM?	Yes	No (translates to .NET)	Yes
Latency per Call	Microseconds	Zero (native .NET)	Low (in-process)
Dynamic Class Loading	Full support	Limited	Supported
Reflection Support	Full	Partial	Full
Commercial Support	Professional (since 2001)	None (community)	Commercial
Linux / Docker / K8s	Yes	Partial	Yes
License	Commercial (free eval)	Open source (MIT)	Commercial ($69/mo+)
First Release	2001	2004	2015
Languages Supported	Java + .NET	Java → .NET only	6+ languages

JNBridgePro: In-Depth Review

How It Works

JNBridgePro runs a real JVM alongside the .NET CLR, either in the same process (shared memory) or connected via TCP. A proxy generation tool inspects your Java JARs and creates matching .NET proxy classes. Your C# or VB.NET code calls these proxy methods with native syntax — the bridge handles type conversion, exception marshaling, and memory management transparently.

Strengths

Full Java compatibility — Runs a real JVM, so any Java library, framework, or feature works. Virtual threads, records, pattern matching, dynamic proxies — all supported.
Mature and battle-tested — In production since 2001. Used by Fortune 500 companies in financial services, healthcare, manufacturing, and government.
Professional support — Guaranteed response times, dedicated engineering support, compatibility updates for new Java and .NET versions.
Flexible deployment — Shared memory (lowest latency), TCP (separate machines), Docker containers, Kubernetes pods.
Low integration effort — Proxy generation is automated. Most integrations go from evaluation to production in weeks, not months.

Limitations

Commercial license required (free evaluation available)
JVM overhead (typically 256MB–1GB heap)
Cross-runtime call overhead in microseconds — only matters in extremely tight loops

Best For

Enterprise teams that need reliable, long-term Java/.NET integration with professional support. Especially strong for modern Java (11+), containerized deployments, and compliance-grade reliability.

IKVM: In-Depth Review

How It Works

IKVM translates compiled Java bytecode (.class and .jar files) into .NET CIL assemblies. The translated Java code runs directly on the CLR as native .NET code — no JVM needed at runtime.

Strengths

Zero cross-runtime overhead — After translation, Java code IS .NET code. Native CLR calls.
No JVM dependency at runtime — Simplifies deployment.
Open source (MIT license) — Free for any use, including commercial.
Simple for simple cases — Self-contained Java libraries can work well.

Limitations

Java SE 8 only — Cannot use Java 9+ features (modules, records, virtual threads, sealed classes). This is the critical limitation.
Incomplete API coverage — Libraries depending on JVM internals, custom class loaders, or reflection-heavy frameworks may fail.
No commercial support — Community-maintained with periods of dormancy.
No dynamic class loading — Frameworks like Spring may not work.

Best For

Projects using simple, self-contained Java 8 libraries where open-source licensing is required and the limitations are acceptable. Not recommended for enterprise production systems needing long-term support.

Javonet: In-Depth Review

How It Works

Javonet provides a cross-runtime invocation framework supporting Java, .NET, Python, Ruby, Perl, and Node.js. It uses an invoke-based API where you specify class names and method names as strings.

Strengths

Multi-language support — Covers 6+ languages with one tool.
Modern Java support — Works with current Java versions.
Commercial support available — Paid plans with SLA options.
Cloud and container friendly — Modern deployment patterns supported.

Limitations

Invoke-based API — You call methods by string name rather than typed proxy classes. No compile-time type checking.
Generic approach — May not be as deeply optimized for Java/.NET as a purpose-built bridge.
Subscription pricing — Starts at $69/month, scales with usage.
Younger product — Founded 2015 vs JNBridgePro's 2001.

Best For

Teams in polyglot environments where Java/.NET is just one of several language integration needs.

Other Alternatives Worth Knowing

REST APIs

Wrap Java code in a web service and call from .NET via HTTP. Adds 5–50ms latency per call but is language-independent and well-understood. Best for distributed systems where Java and .NET already run on different machines.

gRPC

High-performance RPC with Protobuf serialization. 1–10ms latency with strong typing through .proto files. Best for high-throughput service-to-service communication.

GraalVM Native Image

Compile Java to a native shared library, load from .NET via P/Invoke. Experimental, with severe restrictions on reflection and dynamic class loading.

JNI + P/Invoke (Manual Bridge)

Maximum control but enormous development effort. Only realistic for very narrow integration surfaces with deep C++ expertise.

Performance Benchmarks

Metric	JNBridgePro	IKVM	Javonet	REST	gRPC
Single call latency	1–50µs	0 (native)	Low µs	5–50ms	1–10ms
Throughput (calls/sec)	100K+	Native .NET	High	1–10K	10–50K
Memory overhead	JVM heap (256MB–1GB)	Minimal	Runtime overhead	Separate process	Separate process
Startup time	JVM init (1–3s)	None	Runtime init	Service startup	Service startup

Key insight: IKVM wins on raw per-call performance because there's no cross-runtime boundary. But IKVM's Java 8 limitation means you're trading performance for compatibility. For most enterprise workloads, JNBridgePro's microsecond overhead is negligible compared to the business logic and I/O surrounding each call.

Decision Framework

Choose JNBridgePro if:

You use Java 9+ (Java 11, 17, 21)
You need professional support with SLAs
Your Java code uses dynamic class loading, reflection, or complex frameworks
You're deploying in Docker/Kubernetes
Long-term reliability and vendor stability matter

Choose IKVM if:

Your Java code targets Java SE 8 exclusively
The library is simple and self-contained
You need zero cross-runtime overhead
Open-source licensing is required

Choose Javonet if:

You need to integrate more than just Java and .NET
The invoke-based API works for your use case
Subscription pricing fits your budget

Choose REST/gRPC if:

Java and .NET run on different machines
Call frequency is low (< 100 calls/sec)
You want complete language independence

FAQ

Which Java/.NET bridge is the most popular?
JNBridgePro has the longest track record (since 2001) and the largest enterprise user base. IKVM has the most open-source downloads but limited active usage due to its Java 8 restriction.

Can I use IKVM and JNBridgePro together?
Technically yes, but not recommended. Pick the approach that best fits your Java version and requirements.

Is there a free Java/.NET bridge for production?
IKVM is free (MIT), but limited to Java SE 8. JNBridgePro offers a free evaluation — production requires a commercial license.

How long does integration take?
JNBridgePro: typically 1–2 days including proxy generation. IKVM: hours for simple JARs, but translation issues can take weeks. Javonet: 1–2 days with more verbose code.

Migrating from IKVM?
See the IKVM to JNBridgePro migration guide. Typical migration: 2–4 weeks for medium-sized applications.

Originally published at jnbridge.com.

JNBridgePro v12.1: .NET 10, JDK 25, and AI-Assisted Configuration Are Here

JNBridge — Mon, 23 Mar 2026 16:53:15 +0000

If you've ever wired Java and .NET together in production, you know the runtime version treadmill never stops. Microsoft ships .NET annually, Java's on a six-month cadence, and your integration layer needs to keep up or become the bottleneck.

JNBridgePro v12.1 just dropped, and it's the first release to fully support .NET 10 alongside JDK 25 — plus something genuinely clever: a demo folder designed for AI coding assistants.

Here's what's actually in the box.

.NET 8, 9, and 10 — All Supported

v12.1 generates proxies that work natively across .NET 8 (current LTS), .NET 9, and .NET 10 — on both Windows and 64-bit Linux. No conditional compilation, no separate builds per target framework.

This matters because if you're bridging Java libraries into a .NET app, you don't want your integration tooling to be the reason you can't upgrade runtimes. With v12.1, you upgrade .NET, regenerate proxies, done.

JDK 8 Through 25 + Jakarta EE 11

On the Java side, full coverage from JDK 8 all the way to JDK 25, plus Java EE 8 through Jakarta EE 11. That's the entire range from legacy Java 8 monoliths to brand-new Jakarta EE deployments — no version gaps.

If you're maintaining a Java 8 app that talks to a .NET 10 service (or vice versa), this is the kind of compatibility range that means you don't have to synchronize your upgrade schedules across stacks.

AI-Assisted Configuration — The Demo Folder

This is the clever addition. v12.1 ships with a demo folder containing a README and all the configuration files in the correct places. Hand that folder to Claude Code, Copilot, or any AI coding agent with file access, and it instantly knows how to configure JNBridgePro for your system. You can also paste the README into ChatGPT for guidance.

The idea is dead simple: instead of reading through setup docs, you give your AI coding assistant the demo folder and go from zero to configured in minutes. The folder covers:

Proxy generation configs — correctly structured so an AI agent can adapt them to your Java classes and .NET targets
TCP/binary and shared memory communication — reference patterns an AI can scaffold your transport layer from
Deployment patterns — common enterprise scenarios ready for an AI assistant to adapt to your environment

Configuration is where most integration time gets burned, not the actual coding. Having a folder that an AI assistant can immediately parse and work from cuts that setup time dramatically.

What JNBridgePro Actually Does (Quick Refresher)

For those who haven't used it: JNBridgePro generates proxy classes that let you call Java from C# (or C# from Java) using native syntax. No REST wrappers, no message queues, no serialization layers — direct in-process or TCP-based method calls.

You point it at Java classes, it generates .NET proxies. You call those proxies like regular C# objects. Under the hood, it handles marshaling, type conversion, and communication. It's been the go-to for enterprise Java/.NET integration for 20+ years.

Who Should Care

Teams running mixed Java/.NET stacks who need to stay current on both runtimes
Anyone on .NET 9/10 who needs Java library access without downgrading
Shops using AI coding assistants — hand the demo folder to Claude Code or Copilot and go from zero to configured
Legacy Java 8 maintainers bridging into modern .NET — full compatibility, no workarounds

Try It

Download JNBridgePro v12.1 — free evaluation, no credit card.

Full release notes (PDF)

What's your team's Java/.NET integration setup look like? Still hand-rolling REST wrappers, or using something more direct? Curious what approaches people are running in production.

Java + .NET Integration Broke? Here's Your Fix-It Checklist

JNBridge — Fri, 20 Mar 2026 13:06:40 +0000

If you've ever stared at a ClassNotFoundException wrapped inside a TypeLoadException wrapped inside a TimeoutException — welcome to cross-runtime debugging.

I've spent a lot of time troubleshooting Java/.NET integration issues, and the pattern is always the same: the error message points you to one runtime while the actual problem lives in the other (or in the configuration between them). This guide covers the errors I see most often, with specific fixes for each.

Where to Start: The Systematic Approach

Before diving into specific errors, follow this process:

Identify which runtime throws the error — Is it a Java exception wrapped in .NET, a .NET exception, or a bridge/communication error?
Check the full stack trace — Cross-runtime stack traces include both Java and .NET frames. The root cause is usually in the innermost exception.
Reproduce in isolation — Can you call the Java method directly? Can you call a simple bridge method? This isolates whether the issue is in Java code, .NET code, or the integration layer.
Check versions — Ensure JDK version, .NET version, and bridge version are compatible.

ClassNotFoundException and NoClassDefFoundError

java.lang.ClassNotFoundException: com.company.MyService
// or
java.lang.NoClassDefFoundError: com/company/MyService

1. Missing JAR in Classpath

The most common cause. The Java class exists in a JAR that isn't on the JVM's classpath when the bridge loads it.

// Fix: Add the JAR to the classpath configuration
// JNBridgePro: Add to classpath in your .jnbproperties file
classpath=C:\libs\myapp.jar;C:\libs\dependency.jar

// REST/gRPC: Ensure the JAR is in the service's classpath
java -cp "myapp.jar:libs/*" com.company.Main

2. Transitive Dependency Missing

Your JAR loads fine, but it depends on another JAR that's missing.

# Diagnostic: Check what the class needs
jar tf myapp.jar | grep MyService    # Verify class exists
jdeps myapp.jar                       # Show dependencies

# Fix: Add all transitive dependencies
# Maven: mvn dependency:copy-dependencies -DoutputDirectory=./libs
# Gradle: Copy all runtime dependencies to a flat directory

3. ClassNotFoundException vs NoClassDefFoundError

ClassNotFoundException: The class was never found. Check classpath.

NoClassDefFoundError: The class was found during compilation but not at runtime, OR a static initializer failed. Check:

Static blocks in the Java class — if they throw exceptions, the class becomes permanently unavailable
Different JDK versions between compile-time and runtime
JAR file corruption (re-download or rebuild)

TypeLoadException and Type Mismatch Errors

System.TypeLoadException: Could not load type 'JavaProxy.MyService'
// or
InvalidCastException: Unable to cast 'java.util.HashMap' to 'Dictionary'

Proxy Class Out of Date

The .NET proxy was generated from a different version of the Java class. After any Java API change, regenerate your proxy classes.

Java-to-.NET Type Mapping Gotchas

Java Type	.NET Type	Watch Out For
`java.lang.Long`	`long`	Null Long → .NET can't unbox null to value type
`java.util.Date`	`DateTime`	Timezone conversion mismatches
`java.math.BigDecimal`	`decimal`	Precision differences (Java arbitrary, .NET 28-29 digits)
`java.util.List`	`IList`	Generic type erasure in Java
`byte[]`	`byte[]`	Java bytes are signed (-128 to 127), .NET unsigned (0 to 255)

Generic Type Erasure

Java erases generic types at runtime. A List<String> and List<Integer> are both just List at the JVM level.

// Problem: Java method returns List<Customer>, but bridge sees raw List
// Fix: Cast elements individually on .NET side
var customers = javaProxy.GetCustomers()
    .Cast<CustomerProxy>()
    .ToList();

Memory Leaks and OutOfMemoryError

java.lang.OutOfMemoryError: Java heap space
// or
System.OutOfMemoryException

Cross-Runtime Reference Leaks

When .NET holds references to Java proxy objects, the Java objects can't be garbage collected. This is the sneaky one:

// Problem: Creating Java objects in a loop without cleanup
for (int i = 0; i < 1000000; i++)
{
    var parser = new JavaXmlParser();  // Creates JVM object
    parser.Parse(data);
    // parser reference kept alive by .NET GC
}

// Fix: Dispose Java objects explicitly
for (int i = 0; i < 1000000; i++)
{
    using var parser = new JavaXmlParser();
    parser.Parse(data);
    // Disposed at end of scope, JVM reference released
}

Dual-Runtime Memory Budgeting

// Container with 4GB RAM:
// JVM heap: -Xmx1g (max 1GB)
// CLR heap: System.GC.HeapHardLimit = 1.5GB
// OS + native: 1.5GB
// 
// Common mistake: Setting JVM to 3GB and CLR to 3GB in a 4GB container
// Result: OOM killer terminates the process

Thread Deadlocks and Timeouts

Cross-Runtime Deadlock

Thread A holds a .NET lock and waits for a Java call. Thread B holds a Java lock and waits for a .NET callback. Classic deadlock.

// Anti-pattern (deadlock risk):
// .NET calls Java → Java calls back to .NET → .NET calls Java again

// Safe pattern:
// .NET calls Java → Java returns result → .NET processes locally

Design rule: Bridge calls should be one-directional per operation.

Thread Pool Starvation

// Problem: All .NET thread pool threads blocked on Java bridge calls
// Symptom: ASP.NET Core stops accepting new requests

// BAD:
await Task.Run(() => javaProxy.SlowOperation());  // Consumes thread pool thread

// BETTER: Dedicated thread pool for bridge calls
private static readonly SemaphoreSlim _bridgeSemaphore = new(maxCount: 20);
public async Task<Result> CallJava()
{
    await _bridgeSemaphore.WaitAsync();
    try { return await Task.Factory.StartNew(() => javaProxy.Call(), 
          TaskCreationOptions.LongRunning); }
    finally { _bridgeSemaphore.Release(); }
}

SSL and TLS Handshake Failures

Error	Cause	Fix
Handshake failure	TLS version mismatch	Both sides must support TLS 1.2+. Disable TLS 1.0/1.1
Certificate not trusted	Self-signed or missing CA	Import cert into Java keystore AND .NET trust store
Hostname mismatch	Cert CN doesn't match	Use SAN entries matching all hostnames
Cipher suite mismatch	No common cipher	Configure matching cipher suites on both runtimes

# Import certificate into Java's trust store
keytool -import -trustcacerts -keystore $JAVA_HOME/lib/security/cacerts \
  -storepass changeit -alias myservice -file myservice.crt

# Verify what TLS versions your JDK supports
java -Djavax.net.debug=ssl:handshake -jar test.jar

JVM Startup Failures

The "it won't even start" category:

JAVA_HOME not set or wrong version — java -version and echo $JAVA_HOME are your friends
Insufficient memory — -Xmx larger than available RAM → "Could not reserve enough space for object heap"
32-bit vs 64-bit mismatch — A 32-bit .NET process can't load a 64-bit JVM
JVM already initialized — JVM can only be created once per process. Use a singleton for bridge init.

Serialization and Marshaling Errors

JSON Casing Mismatch (REST/gRPC)

// Java sends: {"firstName": "John"}  (camelCase)
// .NET expects: {"FirstName": "John"} (PascalCase)

// Fix: Case-insensitive deserialization
var options = new JsonSerializerOptions
{
    PropertyNameCaseInsensitive = true,
    PropertyNamingPolicy = JsonNamingPolicy.CamelCase
};

Null Handling Across Runtimes

// Java: method returns null Integer
// .NET: can't unbox null to int (value type)

// Fix: Use nullable value types
int? result = javaProxy.GetCount();  // Can be null

Diagnostic Tools Quick Reference

Problem	Java Tool	.NET Tool
Thread dump / deadlock	`jstack <pid>`	`dotnet-dump collect`
Heap analysis	`jmap -dump:format=b <pid>`	`dotnet-gcdump collect`
GC behavior	`-Xlog:gc*`	`dotnet-counters monitor`
CPU profiling	JDK Flight Recorder / async-profiler	dotnet-trace
Class loading	`-verbose:class`	Assembly.Load events
Network issues	`-Djavax.net.debug=ssl`	`DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_LOG`

FAQ

How do I get a cross-runtime stack trace?
When a Java exception occurs during a bridge call, it's wrapped in a .NET exception. Check ex.InnerException for the original Java exception class and stack trace.

Works locally, fails in Docker?
Check: (1) JAVA_HOME path differs, (2) memory limits are lower in containers, (3) DNS resolution differs in container networking, (4) file permissions on JARs.

Can I debug both runtimes simultaneously?
Yes — attach a Java remote debugger (-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005) and a .NET debugger to the same process. Set breakpoints on both sides.

How do I know if the error is in Java, .NET, or the bridge?
Three tests: (1) Call the Java method directly from Java — if it fails, Java problem. (2) Call a trivial bridge method like toString() — if that fails, bridge misconfigured. (3) If both work, check parameter types, null handling, and thread safety in the cross-runtime call.

For more depth, see the Performance Tuning Guide and Security Guide.

Testing Across the Java/.NET Boundary: A Practical Strategy That Actually Works

JNBridge — Tue, 17 Mar 2026 13:41:51 +0000

If you've ever stared at a green CI pipeline and then watched your Java/.NET integration explode in production — you know that standard unit tests aren't enough when two runtimes are talking to each other.

The bridge boundary between Java and .NET is a unique layer that most testing strategies completely ignore. Serialization failures, type mapping bugs, classpath issues — none of these show up in your mocked unit tests. Here's a testing strategy designed specifically for polyglot Java/.NET architectures, with code you can actually use.

The Testing Pyramid Gets a New Layer

The standard testing pyramid (unit → integration → E2E) works for single-language apps. But Java/.NET integration needs a distinct bridge test layer:

         ╱╲
        ╱ E2E ╲          Few: Full system tests
       ╱────────╲
      ╱ Bridge    ╲       Medium: Cross-language integration
     ╱──────────────╲
    ╱ Integration     ╲   Medium: Each side's service tests
   ╱────────────────────╲
  ╱ Unit                  ╲ Many: Pure logic tests per language
 ╱──────────────────────────╲

Unit tests: Test Java and .NET logic independently. Mock the bridge boundary. Run in milliseconds.
Integration tests (per side): Test each side with real dependencies (DBs, file systems) but mock the cross-language boundary.
Bridge tests: Test that Java and .NET actually communicate correctly through the bridge. Requires both runtimes running.
E2E tests: Full system tests across both platforms.

Unit Testing: Mock the Bridge, Not the Logic

The key is abstracting the bridge behind an interface so your business logic is testable without a JVM:

// ❌ Bad: Tight coupling to Java bridge
public class RiskService
{
    public decimal CalculateRisk(Portfolio portfolio)
    {
        var javaEngine = new com.company.risk.RiskEngine();
        return (decimal)javaEngine.Calculate(portfolio.ToJavaObject());
    }
}

// ✅ Good: Interface abstraction
public interface IRiskEngine
{
    decimal CalculateVaR(Portfolio portfolio, double confidence);
    decimal CalculateExpectedShortfall(Portfolio portfolio);
}

// Production implementation uses the bridge
public class JnBridgeRiskEngine : IRiskEngine
{
    private readonly com.company.risk.RiskEngine _javaEngine;

    public JnBridgeRiskEngine()
    {
        _javaEngine = new com.company.risk.RiskEngine();
    }

    public decimal CalculateVaR(Portfolio portfolio, double confidence)
    {
        var javaPortfolio = PortfolioMapper.ToJava(portfolio);
        return (decimal)_javaEngine.CalculateVaR(javaPortfolio, confidence);
    }

    public decimal CalculateExpectedShortfall(Portfolio portfolio)
    {
        var javaPortfolio = PortfolioMapper.ToJava(portfolio);
        return (decimal)_javaEngine.CalculateES(javaPortfolio);
    }
}

// Unit test with mock — no JVM needed
[TestFixture]
public class PortfolioServiceTests
{
    [Test]
    public void RebalancePortfolio_WhenRiskExceedsThreshold_ReducesExposure()
    {
        var mockRiskEngine = new Mock<IRiskEngine>();
        mockRiskEngine.Setup(r => r.CalculateVaR(It.IsAny<Portfolio>(), 0.99))
            .Returns(1_500_000m);

        var service = new PortfolioService(mockRiskEngine.Object);
        var portfolio = CreateTestPortfolio();

        var result = service.Rebalance(portfolio);

        Assert.That(result.TotalExposure, Is.LessThan(portfolio.TotalExposure));
    }
}

Same pattern on the Java side — if Java calls back into .NET:

public interface DotNetNotificationService {
    void notifyTradeExecuted(String tradeId, double price, int quantity);
    void notifyRiskAlert(String portfolioId, double varValue);
}

public class TradeExecutionService {
    private final DotNetNotificationService notificationService;

    public TradeExecutionService(DotNetNotificationService notificationService) {
        this.notificationService = notificationService;
    }

    public TradeResult executeTrade(TradeOrder order) {
        var result = matchingEngine.submit(order);
        notificationService.notifyTradeExecuted(
            result.getTradeId(), result.getPrice(), result.getQuantity());
        return result;
    }
}

@ExtendWith(MockitoExtension.class)
class TradeExecutionServiceTest {
    @Mock
    private DotNetNotificationService notificationService;

    @InjectMocks
    private TradeExecutionService service;

    @Test
    void executeTrade_notifiesDotNetOnSuccess() {
        var order = new TradeOrder("AAPL", Side.BUY, 100, 185.50);
        var result = service.executeTrade(order);

        verify(notificationService).notifyTradeExecuted(
            eq(result.getTradeId()), eq(185.50), eq(100));
    }
}

Bridge Integration Tests: The Layer Most People Skip

This is where you catch the real bugs — type mapping failures, serialization issues, classpath problems:

[TestFixture]
[Category("BridgeIntegration")]
public class RiskEngineIntegrationTests
{
    private JnBridgeRiskEngine _riskEngine;

    [OneTimeSetUp]
    public void SetUp()
    {
        BridgeConfiguration.Initialize(new BridgeConfig
        {
            JavaHome = Environment.GetEnvironmentVariable("JAVA_HOME"),
            ClassPath = "java-libs/risk-engine.jar;java-libs/dependencies/*"
        });
        _riskEngine = new JnBridgeRiskEngine();
    }

    [Test]
    public void CalculateVaR_WithValidPortfolio_ReturnsPositiveValue()
    {
        var portfolio = new Portfolio();
        portfolio.AddPosition("AAPL", 1000, 185.50m);
        portfolio.AddPosition("MSFT", 500, 420.30m);

        var result = _riskEngine.CalculateVaR(portfolio, 0.99);

        Assert.That(result, Is.GreaterThan(0));
        Assert.That(result, Is.LessThan(portfolio.TotalValue));
    }

    [Test]
    public void CalculateVaR_WithHighConfidence_ReturnsHigherValue()
    {
        var portfolio = CreateLargePortfolio();

        var var95 = _riskEngine.CalculateVaR(portfolio, 0.95);
        var var99 = _riskEngine.CalculateVaR(portfolio, 0.99);

        Assert.That(var99, Is.GreaterThan(var95));
    }

    [OneTimeTearDown]
    public void TearDown() => BridgeConfiguration.Shutdown();
}

Type Mapping Tests — Where the Real Bugs Hide

[TestFixture]
[Category("BridgeIntegration")]
public class TypeMappingTests
{
    [Test]
    public void JavaBigDecimal_MapsTo_DotNetDecimal()
    {
        var javaCalc = new com.company.Calculator();
        var result = javaCalc.PreciseCalculation(1.1, 2.2);
        Assert.That(result, Is.EqualTo(3.3m).Within(0.0001m));
    }

    [Test]
    public void JavaLocalDateTime_MapsTo_DotNetDateTime()
    {
        var javaTimeService = new com.company.TimeService();
        var javaTime = javaTimeService.GetCurrentTime();
        Assert.That(javaTime, Is.EqualTo(DateTime.UtcNow).Within(TimeSpan.FromSeconds(5)));
    }

    [Test]
    public void JavaException_PropagatesTo_DotNetException()
    {
        var javaService = new com.company.DataService();
        var ex = Assert.Throws<Exception>(() => javaService.MethodThatThrows());
        Assert.That(ex.Message, Does.Contain("expected error message"));
    }

    [TestCase(null)]
    [TestCase("")]
    [TestCase("very long string with unicode: こんにちは 🎉")]
    public void JavaString_HandlesEdgeCases(string input)
    {
        var javaService = new com.company.StringService();
        var result = javaService.Echo(input);
        Assert.That(result, Is.EqualTo(input));
    }
}

Performance Tests: Don't Assume, Measure

These catch regressions when Java libs update, bridge versions change, or JVM settings are modified:

[TestFixture]
[Category("Performance")]
public class BridgePerformanceTests
{
    [Test]
    public void InProcessBridge_SimpleCall_Under100Microseconds()
    {
        var javaService = new com.company.EchoService();

        // Warmup
        for (int i = 0; i < 1000; i++)
            javaService.Echo("warmup");

        var sw = Stopwatch.StartNew();
        int iterations = 10_000;
        for (int i = 0; i < iterations; i++)
            javaService.Echo("test");
        sw.Stop();

        var avgMicroseconds = sw.Elapsed.TotalMicroseconds / iterations;
        Assert.That(avgMicroseconds, Is.LessThan(100), 
            "Bridge call latency exceeded 100μs threshold");
    }

    [Test]
    public void Bridge_Under10KConcurrentCalls_NoErrors()
    {
        var javaService = new com.company.ThreadSafeService();
        var errors = new ConcurrentBag<Exception>();

        Parallel.For(0, 10_000, new ParallelOptions { MaxDegreeOfParallelism = 50 }, i =>
        {
            try { javaService.Process($"item-{i}"); }
            catch (Exception ex) { errors.Add(ex); }
        });

        Assert.That(errors, Is.Empty, 
            $"Bridge had {errors.Count} errors under concurrent load");
    }

    [Test]
    public void Bridge_MemoryStable_Over1MillionCalls()
    {
        var javaService = new com.company.DataService();
        var initialMemory = GC.GetTotalMemory(true);

        for (int i = 0; i < 1_000_000; i++)
            javaService.GetSmallObject();

        GC.Collect();
        GC.WaitForPendingFinalizers();
        var finalMemory = GC.GetTotalMemory(true);
        var memoryGrowthMB = (finalMemory - initialMemory) / (1024.0 * 1024.0);

        Assert.That(memoryGrowthMB, Is.LessThan(50), 
            "Possible memory leak — growth exceeded 50MB over 1M calls");
    }
}

Docker-Based Test Environment

Bridge integration tests need both runtimes. Docker makes it reproducible:

# Dockerfile.test — Both runtimes in one container
FROM mcr.microsoft.com/dotnet/sdk:9.0

RUN apt-get update && apt-get install -y \
    openjdk-21-jdk-headless \
    && rm -rf /var/lib/apt/lists/*

ENV JAVA_HOME=/usr/lib/jvm/java-21-openjdk-amd64

WORKDIR /test
COPY . .
RUN dotnet restore && dotnet build -c Release

ENTRYPOINT ["dotnet", "test", "-c", "Release", "--logger", "trx"]

# docker-compose.test.yml
version: '3.8'
services:
  unit-tests:
    build: { context: ., dockerfile: Dockerfile.test }
    command: ["dotnet", "test", "-c", "Release", 
              "--filter", "Category!=BridgeIntegration&Category!=Performance"]
    volumes: [test-results:/test/TestResults]

  bridge-tests:
    build: { context: ., dockerfile: Dockerfile.test }
    command: ["dotnet", "test", "-c", "Release",
              "--filter", "Category=BridgeIntegration"]
    volumes: [test-results:/test/TestResults]
    depends_on:
      unit-tests: { condition: service_completed_successfully }

  performance-tests:
    build: { context: ., dockerfile: Dockerfile.test }
    command: ["dotnet", "test", "-c", "Release",
              "--filter", "Category=Performance"]
    volumes: [test-results:/test/TestResults]
    depends_on:
      bridge-tests: { condition: service_completed_successfully }

volumes:
  test-results:

CI/CD Pipeline: GitHub Actions

name: Java/.NET Integration Tests

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  unit-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-dotnet@v4
        with: { dotnet-version: '9.0.x' }
      - run: dotnet test --filter "Category!=BridgeIntegration&Category!=Performance"

  java-unit-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with: { java-version: '21', distribution: 'temurin' }
      - run: ./gradlew test

  bridge-tests:
    needs: [unit-tests, java-unit-tests]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-dotnet@v4
        with: { dotnet-version: '9.0.x' }
      - uses: actions/setup-java@v4
        with: { java-version: '21', distribution: 'temurin' }
      - run: dotnet test --filter "Category=BridgeIntegration"
        timeout-minutes: 10

  performance-gate:
    needs: [bridge-tests]
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-dotnet@v4
        with: { dotnet-version: '9.0.x' }
      - uses: actions/setup-java@v4
        with: { java-version: '21', distribution: 'temurin' }
      - run: dotnet test --filter "Category=Performance"

Pipeline strategy:

Stage	Tests	When	Time
PR checks	Unit tests (both languages)	Every PR	~2 min
PR checks	Bridge integration tests	Every PR	~5 min
Merge to main	Performance tests	After merge	~10 min
Nightly	Full E2E + load tests	Scheduled	~30 min
Pre-release	All tests + security scan	Before deploy	~45 min

6 Pitfalls That Will Bite You

Not testing type boundaries. Java BigDecimal → .NET decimal, LocalDateTime → DateTime, ArrayList → List — test every type that crosses the bridge. These are your #1 production failure source.
Ignoring thread safety. If your bridge calls are concurrent in production (they usually are), test with concurrent load. Some bridge configs aren't thread-safe by default.
Skipping classpath smoke tests. A missing JAR causes cryptic failures. Write a test that verifies all required Java classes are loadable at bridge init.
Testing only the happy path. What happens when Java throws? Does the exception propagate correctly to .NET? Test timeouts, OOM, and failure modes explicitly.
No performance baselines. Without baselines, you won't notice a 10x latency regression from a Java library update. Assert thresholds in your perf tests.
Running bridge tests in parallel. Bridge initialization often isn't parallelizable. Use [NonParallelizable] in NUnit or sequential execution for bridge setup/teardown.

Testing Checklist

Use this when setting up testing for a Java/.NET integration:

☐ Business logic unit tests (both sides) with mocked bridge boundary
☐ Type mapping tests for every type crossing the bridge
☐ Null handling tests for all bridge method parameters
☐ Exception propagation tests (Java → .NET)
☐ Collection mapping tests (ArrayList → List, HashMap → Dictionary)
☐ Unicode/encoding tests for string parameters
☐ Date/time/timezone tests
☐ Concurrent load test (50+ parallel calls)
☐ Memory stability test (1M+ calls)
☐ Latency baseline with asserted threshold
☐ Bridge init smoke test (all JARs loadable)
☐ Docker-based test environment for CI
☐ CI pipeline with staged execution
☐ Performance regression gate on main branch

Testing Java/.NET integration requires a deliberate strategy beyond standard unit testing. The bridge boundary introduces type mapping, serialization, concurrency, and performance concerns that don't exist in single-language apps.

The approach here — interface abstraction for unit tests, dedicated bridge tests, Docker environments, and CI/CD with performance gates — gives you confidence your integration works correctly even as both sides evolve.

JNBridgePro supports both in-process and TCP testing modes, so you can run bridge tests locally during development and in Docker containers during CI.

Building a tested Java/.NET integration? Download JNBridgePro and try these patterns with your own codebase.

Spring Boot + ASP.NET Core in the Same Architecture? Here Are 4 Patterns That Work

JNBridge — Fri, 13 Mar 2026 13:10:47 +0000

Nobody sets out to run both Spring Boot and ASP.NET Core. But acquisitions happen, teams make different (valid) technology choices, and suddenly you're staring at two frameworks that need to talk to each other.

I've been working on Java/.NET integration for years, and these are the four patterns I keep coming back to — each with real code you can adapt.

Why These Frameworks End Up Together

Teams don't usually plan to run both frameworks. It happens because:

Acquisitions: Company A (.NET shop) acquires Company B (Java shop). Now you have Spring Boot microservices talking to ASP.NET Core APIs.
Best-of-breed choices: The data engineering team chose Spring Boot for Kafka integration. The frontend team chose ASP.NET Core for the API gateway. Both are valid.
Legacy + Modern: A mature Spring Boot backend serves a new ASP.NET Core frontend built for a modern SPA.
Vendor libraries: A critical third-party SDK only ships as a Java JAR. Your application is ASP.NET Core.

Pattern 1: REST API Integration

The most common pattern. Spring Boot exposes REST endpoints, ASP.NET Core consumes them (or vice versa).

Spring Boot Side (API Provider)

@RestController
@RequestMapping("/api/products")
public class ProductController {

    @Autowired
    private ProductService productService;

    @GetMapping("/{id}")
    public ResponseEntity<ProductDTO> getProduct(@PathVariable Long id) {
        return productService.findById(id)
            .map(ResponseEntity::ok)
            .orElse(ResponseEntity.notFound().build());
    }

    @GetMapping
    public Page<ProductDTO> searchProducts(
            @RequestParam String query,
            Pageable pageable) {
        return productService.search(query, pageable);
    }
}

ASP.NET Core Side (API Consumer)

public class ProductApiClient
{
    private readonly HttpClient _http;

    public ProductApiClient(HttpClient http)
    {
        _http = http;
    }

    public async Task<Product?> GetProductAsync(long id)
    {
        var response = await _http.GetAsync($"/api/products/{id}");
        if (!response.IsSuccessStatusCode) return null;
        return await response.Content.ReadFromJsonAsync<Product>();
    }

    public async Task<PagedResult<Product>> SearchAsync(
        string query, int page = 0, int size = 20)
    {
        var response = await _http.GetFromJsonAsync<PagedResult<Product>>(
            $"/api/products?query={query}&page={page}&size={size}");
        return response!;
    }
}

// Registration in Program.cs
builder.Services.AddHttpClient<ProductApiClient>(client =>
{
    client.BaseAddress = new Uri("http://spring-boot-service:8080");
    client.Timeout = TimeSpan.FromSeconds(10);
})
.AddTransientHttpErrorPolicy(p => 
    p.WaitAndRetryAsync(3, attempt => TimeSpan.FromMilliseconds(200 * attempt)))
.AddTransientHttpErrorPolicy(p => 
    p.CircuitBreakerAsync(5, TimeSpan.FromSeconds(30)));

Watch out for:

Spring Boot's Page<T> pagination uses a different JSON structure than what ASP.NET Core expects. Map accordingly.
Spring Boot returns dates as ISO-8601 by default (Jackson). System.Text.Json handles this, but verify timezone handling.
Add Polly for retry and circuit breaker on the .NET side.
Spring Boot's @Valid errors return 400 with a different shape than ASP.NET Core's ProblemDetails. Normalize your error handling.

Pattern 2: gRPC Integration

For higher-performance scenarios, gRPC gives you better throughput with strong typing via Protobuf:

syntax = "proto3";
package product;

service ProductService {
    rpc GetProduct (ProductRequest) returns (ProductResponse);
    rpc StreamPriceUpdates (PriceSubscription) returns (stream PriceUpdate);
}

message ProductRequest {
    int64 id = 1;
}

message ProductResponse {
    int64 id = 1;
    string name = 2;
    string description = 3;
    double price = 4;
    google.protobuf.Timestamp updated_at = 5;
}

// Spring Boot gRPC server
@GrpcService
public class ProductGrpcService extends ProductServiceGrpc.ProductServiceImplBase {

    @Override
    public void getProduct(ProductRequest request, 
                          StreamObserver<ProductResponse> observer) {
        var product = productService.findById(request.getId());
        observer.onNext(toProto(product));
        observer.onCompleted();
    }

    @Override
    public void streamPriceUpdates(PriceSubscription request,
                                   StreamObserver<PriceUpdate> observer) {
        priceService.subscribe(request.getSymbol(), update -> {
            observer.onNext(toPriceProto(update));
        });
    }
}

// ASP.NET Core gRPC client
public class ProductGrpcClient
{
    private readonly ProductService.ProductServiceClient _client;

    public async Task<Product> GetProductAsync(long id)
    {
        var response = await _client.GetProductAsync(
            new ProductRequest { Id = id });
        return Product.FromProto(response);
    }

    public async IAsyncEnumerable<PriceUpdate> StreamPricesAsync(
        string symbol, [EnumeratorCancellation] CancellationToken ct = default)
    {
        using var stream = _client.StreamPriceUpdates(
            new PriceSubscription { Symbol = symbol });

        await foreach (var update in stream.ResponseStream.ReadAllAsync(ct))
        {
            yield return PriceUpdate.FromProto(update);
        }
    }
}

gRPC's server-streaming is particularly useful when Spring Boot pushes real-time data to ASP.NET Core consumers — prices, events, notifications.

Pattern 3: In-Process Bridge

When ASP.NET Core needs to use Java libraries directly — without running a separate Spring Boot service — an in-process bridge loads the JVM inside the .NET process:

public class JavaRuleEngineService : IRuleEngine
{
    private readonly com.company.rules.RuleEngine _javaEngine;

    public JavaRuleEngineService()
    {
        // Bridge loads the Java rule engine in-process
        // No separate Spring Boot service needed
        _javaEngine = new com.company.rules.RuleEngine();
        _javaEngine.LoadRules("/rules/production.drl");
    }

    public RuleResult Evaluate(BusinessContext context)
    {
        var javaContext = ContextMapper.ToJava(context);
        var result = _javaEngine.Evaluate(javaContext);
        return RuleResult.FromJava(result);
    }
}

// Register in ASP.NET Core DI
builder.Services.AddSingleton<IRuleEngine, JavaRuleEngineService>();

When to use this: When you need a Java library (Drools, Apache Tika, a proprietary Java SDK) but don't want to deploy and maintain a separate Spring Boot service just to expose it. Tools like JNBridgePro make this possible.

Pattern 4: Event-Driven Integration via Kafka

For async workflows, both frameworks communicate through Apache Kafka (or RabbitMQ, Azure Service Bus):

// Spring Boot producer
@Service
public class OrderEventPublisher {
    @Autowired
    private KafkaTemplate<String, OrderEvent> kafka;

    public void publishOrderCreated(Order order) {
        kafka.send("order-events", order.getId(), 
            new OrderCreatedEvent(order));
    }
}

// ASP.NET Core consumer
public class OrderEventConsumer : BackgroundService
{
    protected override async Task ExecuteAsync(CancellationToken ct)
    {
        using var consumer = new ConsumerBuilder<string, string>(_config)
            .Build();
        consumer.Subscribe("order-events");

        while (!ct.IsCancellationRequested)
        {
            var result = consumer.Consume(ct);
            var orderEvent = JsonSerializer.Deserialize<OrderEvent>(
                result.Message.Value);
            await ProcessOrderEvent(orderEvent!);
        }
    }
}

Schema compatibility tip: Use Confluent Schema Registry with Avro or Protobuf schemas. Both Spring Boot (spring-kafka) and .NET (Confluent.SchemaRegistry) support it, ensuring both sides agree on message formats.

Shared Cross-Cutting Concerns

Authentication: Shared JWT Tokens

Both frameworks can validate the same JWT tokens from the same identity provider:

// Spring Boot
@Configuration
@EnableWebSecurity
public class SecurityConfig {
    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        return http
            .oauth2ResourceServer(oauth2 -> oauth2
                .jwt(jwt -> jwt.jwkSetUri("https://auth.company.com/.well-known/jwks")))
            .build();
    }
}

// ASP.NET Core
builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(options =>
    {
        options.Authority = "https://auth.company.com";
        options.TokenValidationParameters = new TokenValidationParameters
        {
            ValidateIssuer = true,
            ValidIssuer = "https://auth.company.com",
            ValidateAudience = true,
            ValidAudience = "api"
        };
    });

Distributed Tracing with OpenTelemetry

# Spring Boot: application.yml
otel:
  service:
    name: spring-product-service
  exporter:
    otlp:
      endpoint: http://jaeger:4317

// ASP.NET Core
builder.Services.AddOpenTelemetry()
    .WithTracing(tracing => tracing
        .SetResourceBuilder(ResourceBuilder.CreateDefault()
            .AddService("dotnet-api-gateway"))
        .AddAspNetCoreInstrumentation()
        .AddHttpClientInstrumentation()
        .AddGrpcClientInstrumentation()
        .AddOtlpExporter(o => o.Endpoint = new Uri("http://jaeger:4317")));

With both exporting to the same collector, you get unified traces showing requests flowing across framework boundaries.

Choosing the Right Pattern

Scenario	Pattern	Why
Separate teams, separate deployments	REST or gRPC	Clear contracts, independent scaling
Real-time data streaming	gRPC server-streaming or Kafka	Efficient push model
Need Java library in .NET app	In-process bridge	No separate service to deploy
Async event-driven workflow	Kafka/RabbitMQ	Decoupled, resilient, scalable
High-frequency calls (>1K/sec)	gRPC or in-process bridge	REST too slow at volume
Migration in progress	In-process bridge	Temporary integration without throwaway APIs

Framework Feature Mapping

For developers working across both, here's how the core concepts map:

Concept	Spring Boot	ASP.NET Core
DI Container	Spring IoC / @Autowired	builder.Services / [FromServices]
Middleware	Filters / Interceptors	app.Use() pipeline
Configuration	application.yml / @Value	appsettings.json / IConfiguration
Health Checks	Actuator /health	MapHealthChecks()
Metrics	Micrometer	System.Diagnostics.Metrics
ORM	JPA / Hibernate	Entity Framework Core
Validation	Bean Validation / @valid	DataAnnotations / FluentValidation
Background Jobs	@Scheduled / Spring Batch	BackgroundService / Hangfire
API Docs	SpringDoc / Swagger	Swashbuckle / NSwag

Wrapping Up

Spring Boot and ASP.NET Core are more alike than different. When they need to cooperate, the right pattern depends on your coupling requirements, performance needs, and team structure. REST handles most cases. gRPC wins on performance-sensitive paths. Kafka decouples event-driven flows. And an in-process bridge gives you direct library access without the operational overhead of another service.

The real power move? Use multiple patterns in the same system, each where it fits best.

Originally published at jnbridge.com

Squeezing Microseconds: A Practical Guide to Java/.NET Performance Tuning

JNBridge — Tue, 10 Mar 2026 13:23:09 +0000

If you're calling Java from .NET (or vice versa), you've probably noticed that cross-runtime calls aren't free. The bridge overhead itself is tiny — microseconds per call — but when you're making thousands of calls per request, those microseconds stack up fast.

I've spent a lot of time profiling cross-runtime performance in production systems, and the surprising truth is: the bridge is almost never the bottleneck. GC pauses, chatty call patterns, and object marshaling eat way more time. Here's everything I've learned about making Java/.NET integration fast.

Where Latency Actually Hides

Most teams blame the bridge. In practice, here's the real breakdown:

Source	Typical Latency	How to Detect
Bridge call overhead	1–50µs	Microbenchmark isolated calls
Object marshaling/serialization	10–500µs	Profile with complex objects vs primitives
GC pauses (either runtime)	1–200ms	GC logs (both JVM and CLR)
JVM cold start (first call)	1–5s	Measure first call vs subsequent
Class loading (Java)	10–100ms	Profile with `-verbose:class`
JIT compilation (both runtimes)	50–500ms first execution	Warmup timing, tiered compilation logs
Thread contention at bridge	Variable	Thread dump analysis, lock profiling
Network latency (TCP mode)	0.1–1ms per call	Switch to shared memory, compare

Rule of thumb: If your cross-runtime calls are slower than expected, look at GC, class loading, and call patterns first — not the bridge mechanism.

Measure Before You Optimize

Performance tuning without measurement is guessing. Establish baselines first:

Single call latency — One method call with a primitive parameter. This is your overhead floor.
Complex call latency — Same call with realistic objects (lists, custom classes). Difference = marshaling cost.
Throughput — Max calls/sec before latency degrades. Tests concurrency limits.
P99 latency — The 99th percentile matters more than average. GC pauses cause tail spikes.
Cold start time — First call after JVM init. Worst-case latency.

Benchmarking Template (C#)

// BenchmarkDotNet setup for cross-runtime calls
[MemoryDiagnoser]
[GcServer(true)]
public class BridgeCallBenchmarks
{
    private JavaProxy _proxy;

    [GlobalSetup]
    public void Setup()
    {
        _proxy = new JavaProxy();
        // Warmup: 1000 calls to trigger JIT on both sides
        for (int i = 0; i < 1000; i++)
            _proxy.SimpleCall(i);
    }

    [Benchmark(Baseline = true)]
    public int SimpleCall() => _proxy.Add(42, 58);

    [Benchmark]
    public List<string> ComplexCall() => _proxy.ProcessList(testData);

    [Benchmark]
    public TradeResult RealWorldCall() => _proxy.ExecuteTrade(sampleTrade);
}

JVM Tuning for Bridge Workloads

Heap Sizing

When the JVM runs inside (or alongside) a .NET process, memory is shared. Set explicit bounds:

# Recommended JVM flags for bridge workloads
-Xms512m                        # Initial heap (avoid resize delays)
-Xmx1g                          # Maximum heap (leave room for CLR)
-XX:MaxMetaspaceSize=256m       # Cap class metadata
-XX:ReservedCodeCacheSize=128m  # JIT compiled code cache

Critical rule: Total JVM heap + CLR managed heap + native overhead must fit in available RAM. In a 4GB container: budget ~1GB for JVM, ~1.5GB for CLR, ~1.5GB for OS and native allocations.

GC Selection

GC Algorithm	Best For	Bridge Impact
G1GC (Java 9+ default)	General workloads, 1–16GB heap	Good default. 10–50ms pause target.
ZGC	Ultra-low latency, large heaps	Sub-millisecond pauses. Best for latency-sensitive bridges.
Shenandoah	Low latency, Red Hat/OpenJDK	Similar to ZGC. Available in OpenJDK builds.
Serial GC	Small heaps (<256MB)	Stop-the-world but fast for tiny heaps.

# For low-latency bridge workloads (Java 17+)
-XX:+UseZGC
-XX:SoftMaxHeapSize=768m    # ZGC returns memory below this
-XX:ZCollectionInterval=5   # Proactive GC every 5 seconds

# For general bridge workloads
-XX:+UseG1GC
-XX:MaxGCPauseMillis=20     # Target 20ms max pause
-XX:G1HeapRegionSize=4m     # Optimize for your object sizes

JIT Compiler Optimization

# Enable tiered compilation (default in Java 9+)
-XX:+TieredCompilation
# Pre-compile frequently-called bridge methods
-XX:CompileThreshold=100    # Compile after 100 invocations (default: 10000)
# For faster warmup at cost of peak performance:
-XX:TieredStopAtLevel=1     # Skip C2 compiler (faster startup)

CLR and .NET Runtime Tuning

Server GC vs Workstation GC

For bridge workloads, always use Server GC:

{
  "runtimeOptions": {
    "configProperties": {
      "System.GC.Server": true,
      "System.GC.Concurrent": true,
      "System.GC.HeapHardLimit": 1610612736
    }
  }
}

Why: Workstation GC runs on a single thread and blocks longer. Server GC uses one thread per core, with shorter pauses. For concurrent bridge calls, Server GC reduces tail latency significantly.

.NET 9 DATAS GC

.NET 9's Dynamic Adaptation to Application Sizes (DATAS) auto-adjusts heap size based on workload — meaning the CLR won't over-allocate when the JVM also needs heap space:

{
  "configProperties": {
    "System.GC.DynamicAdaptationMode": 1
  }
}

Thread Pool Tuning

// Set minimum threads to avoid pool starvation during bridge calls
ThreadPool.SetMinThreads(
    workerThreads: Environment.ProcessorCount * 2,
    completionPortThreads: Environment.ProcessorCount);

Garbage Collection Coordination

The biggest performance killer: GC pauses in one runtime stalling the other.

When the JVM is in a stop-the-world GC pause, .NET threads waiting for bridge responses are blocked. If the CLR triggers its own GC simultaneously — compounding pause.

Mitigation Strategies

Use low-pause GCs on both sides — ZGC (Java) + Server GC (.NET) keeps pauses under 1ms
Stagger GC timing — Proactive JVM GC during idle periods (-XX:ZCollectionInterval=5)
Monitor both GC logs simultaneously — Correlate JVM GC events with .NET events to find compounding pauses
Reduce object allocation at the bridge boundary — Reuse objects, use value types, avoid unnecessary boxing

Enabling GC Logs for Both Runtimes

# JVM GC logging
-Xlog:gc*:file=jvm-gc.log:time,uptime,level,tags:filecount=5,filesize=10m

# .NET GC logging
DOTNET_GCLog=gc-dotnet.log

Optimizing Cross-Runtime Call Patterns

Anti-Pattern: Chatty Calls

// BAD: 1000 individual bridge calls
for (int i = 0; i < orders.Count; i++)
{
    var result = javaService.ValidateOrder(orders[i]);  // ~10µs each
    // 1000 * 10µs = 10ms overhead
}

Pattern: Batch Calls

// GOOD: 1 bridge call with batch data
var results = javaService.ValidateOrders(orders);  // ~50µs total
// 50µs vs 10ms = 200x faster

Rule: Every cross-runtime call has fixed overhead. Minimize the number of calls, not the data per call. One call with 1000 items beats 1000 calls with 1 item.

Pattern: Coarse-Grained Interfaces

// BAD: Fine-grained Java API from .NET
var customer = javaProxy.GetCustomer(id);
var address = javaProxy.GetAddress(customer.AddressId);
var orders = javaProxy.GetOrders(customer.Id);
var total = javaProxy.CalculateTotal(orders);
// 4 bridge calls

// GOOD: Coarse-grained facade
var summary = javaProxy.GetCustomerSummary(id);
// 1 bridge call — Java handles the joins internally

Design principle: Create coarse-grained Java facades that batch operations per bridge call. Let Java-to-Java calls happen inside the JVM (zero overhead), and only cross the bridge for the final result.

Pattern: Async Fire-and-Forget

// For non-blocking operations (logging, analytics, cache warming)
Task.Run(() => javaProxy.LogAnalyticsEvent(eventData));
// Don't await — .NET continues immediately

Object Marshaling Optimization

Data Type	Marshaling Cost	Optimization
Primitives (int, double, bool)	Negligible	Use directly
Strings	Low (UTF-16 both sides)	Avoid unnecessary conversions
Arrays of primitives	Low (bulk copy)	Prefer over `List<T>`
Simple objects (few fields)	Low-Medium	Use DTOs, not full entities
Collections (List, Map)	Medium (element-by-element)	Use arrays when possible
Deep object graphs	High	Flatten or use DTOs
Exceptions	High (stack trace construction)	Use error codes for expected failures

DTO Pattern for Cross-Runtime Data

// .NET DTO — flat, minimal fields
public record TradeRequest(
    string Symbol,
    decimal Quantity,
    decimal Price,
    string Side  // "BUY" or "SELL"
);

// Java DTO — mirrors .NET structure
public record TradeRequest(
    String symbol,
    BigDecimal quantity,
    BigDecimal price,
    String side
) {}

Key optimizations:

Keep DTOs flat (no nested objects when avoidable)
Use primitive types and strings over complex objects
Avoid passing Java-specific types (HashMap internals, Stream objects) across the bridge
For large datasets: pass byte arrays and deserialize on the receiving side

Connection and Resource Pooling

JVM Instance Reuse

Never create multiple JVM instances per request:

// Singleton pattern for bridge initialization
public sealed class JavaBridge
{
    private static readonly Lazy<JavaBridge> _instance = 
        new(() => new JavaBridge());

    public static JavaBridge Instance => _instance.Value;

    private JavaBridge()
    {
        JNBridge.Initialize(); // One-time (1-3 seconds)
    }
}

Object Pooling for Frequently Used Java Objects

private readonly ObjectPool<JavaPdfParser> _parserPool = 
    new DefaultObjectPool<JavaPdfParser>(
        new JavaPdfParserPoolPolicy(), maxRetained: 10);

public byte[] ConvertPdf(byte[] input)
{
    var parser = _parserPool.Get();
    try { return parser.Convert(input); }
    finally { _parserPool.Return(parser); }
}

Profiling Tools

Tool	Runtime	Best For	Free?
BenchmarkDotNet	.NET	Microbenchmarks, memory allocation	Yes
dotnet-trace / dotnet-counters	.NET	Runtime diagnostics, GC events	Yes
JDK Flight Recorder (JFR)	Java	Low-overhead production profiling	Yes
async-profiler	Java	CPU + allocation profiling, flame graphs	Yes
VisualVM	Java	Heap analysis, thread monitoring	Yes
OpenTelemetry	Both	Distributed tracing across runtimes	Yes
Prometheus + Grafana	Both	Metrics dashboards, alerting	Yes

Recommended Workflow

Start with OpenTelemetry tracing — instrument bridge calls with spans
Enable GC logging on both runtimes — check for correlated pauses
Run BenchmarkDotNet microbenchmarks — isolate bridge overhead
Use JFR in production — low overhead (<2%) continuous profiling
Build a Grafana dashboard — track P50/P95/P99 latency over time

Benchmarks: Before and After

Scenario	Before	After	Improvement	Technique
1000 individual calls	10ms	0.05ms	200x	Batch call pattern
Complex object marshaling	500µs	50µs	10x	DTO flattening
P99 latency (GC spikes)	200ms	2ms	100x	ZGC + Server GC
Cold start (first call)	5s	1.5s	3.3x	Eager class loading + tiered compilation
Concurrent throughput	5K calls/s	50K calls/s	10x	Thread pool tuning + object pooling
TCP mode overhead	0.5ms/call	5µs/call	100x	Switch to shared memory mode

Most impactful: Switching from chatty calls to batch calls. Almost always the biggest win.

FAQ

What's the typical overhead of a JNBridgePro bridge call?
A single call with simple parameters takes 1–50µs in shared memory mode. For comparison, a REST API call to the same method on localhost: 5–50ms — 1000x slower.

Shared memory or TCP mode?
Use shared memory when Java and .NET run on the same machine. It eliminates network latency entirely (5µs vs 0.5ms per call). TCP mode is only for when JVM and CLR are on different machines.

How do I prevent JVM GC from blocking .NET?
Use ZGC (Java 17+) or Shenandoah for sub-millisecond pauses. On .NET, enable Server GC with concurrent mode. Monitor both GC logs.

Can I make bridge calls async?
Bridge calls are synchronous by design (direct method invocation). Wrap in Task.Run() for fire-and-forget, or use a producer-consumer queue where a background thread makes bridge calls.

How many concurrent calls can it handle?
No hard limit. With proper thread pool tuning, production systems handle 50,000+ calls/sec. The bottleneck is almost always business logic, not bridge overhead.

This article was originally published at jnbridge.com.

Forem: JNBridge

Run Java from C#: 5 Methods with Code Examples

Table of Contents

Quick Comparison

Method 1: Process.Start — Run java.exe as a Subprocess

When to Use It

Code Example

Edge Cases to Handle

The Problem

Method 2: IKVM — Compile Java Bytecode to .NET

When to Use It

Code Example

Limitations

Method 3: JNI via C++/CLI Wrapper

When to Use It

Code Example

Why Most Teams Don't Do This

Method 4: gRPC Sidecar — Run Java as a Microservice

When to Use It

Code Example

Trade-offs

Method 5: JNBridgePro — In-Process Java/.NET Bridge

When to Use It

Code Example

What Makes It Different

Performance Benchmarks

Which Method Should You Use?

How Do You Handle Java Dependencies from C#?

Can You Run Java from C# Without a JDK?

Frequently Asked Questions

What is the best way to run Java from .NET in production?

Can I run Java code in C# on Linux?

How do error and exception handling work across Java and C#?

Is there a free way to run Java from C# with low latency?

Wrapping Up

C# JVM Guide: JDK, CLR & Java Interop for .NET

Table of Contents

What Is the JVM? (The .NET Developer’s Answer)

Why This Matters to You

The JDK Explained for .NET Developers

C# JDK Compatibility: What Version Do You Need?

CLR vs. JVM: Full Platform Comparison

What Is the Difference Between J2EE and ASP.NET?

Can C# Run on the JVM?

Can Java Run on the CLR? IKVM and GraalVM

IKVM.NET

GraalVM

How to Connect C# and Java: The 4 Real Options

1. REST APIs / Web Services

2. Message Queues (Kafka, RabbitMQ)

3. gRPC / Process-Level Interop

4. In-Process Bridging with JNBridgePro

When You Need In-Process C# JVM Bridging

Java Libraries Without REST Wrappers

Enterprise Java Systems (.NET J2EE Integration)

Incremental Migration

Performance-Sensitive Integration

Getting Started with JNBridgePro

FAQ: C# JVM, JDK, and .NET Java Interop

Does C# run in a VM similar to Java’s JVM?

What is the equivalent of the JVM in C#?

Can you compile C# to run on the JVM?

What happened to IKVM? Can it replace a C# JVM bridge?

How does JNBridgePro handle C# JDK compatibility?

Does the .NET SDK include JVM or JDK support?

The practical takeaway

How to Use Java JARs and .NET DLLs Across Platforms

Table of Contents

Why JARs and DLLs Are Incompatible

Method 1: Process Wrapping (Quick and Dirty)

Running a Java JAR from C

Running a .NET DLL from Java

Method 2: REST/gRPC Service Wrapper

Exposing a Java JAR as a REST API

Calling It from C\

Method 3: JNI — Low-Level Native Bridge

Method 4: IKVM (Java on .NET — Legacy)

Method 5: JNBridgePro (In-Process Runtime Bridge)

Using a Java JAR in C\

Using a .NET DLL in Java

Handling `ClassNotFoundException` and `NoClassDefFoundError`