DEV Community: JNBridge

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.

Java C# Bridge: Every Integration Tool Ranked for 2026

JNBridge — Sat, 07 Mar 2026 14:58:48 +0000

Last month I got asked by a colleague: "We have a Java payment library and a C# frontend — what's the fastest way to make them talk?" I've been answering variations of that question for years, so I figured it's time to write the definitive comparison.

Here's every serious tool for bridging Java and C# in 2026, rated honestly on performance, API fidelity, maintenance burden, maturity, and cost. No vendor fluff — just what actually works.

The Java-C# Integration Landscape in 2026

Enterprise development teams rarely have the luxury of a single technology stack. Java dominates backend services, data pipelines, and Android. C# owns the Windows desktop, game development (Unity), and increasingly cloud-native .NET workloads. When these worlds collide — and they always do — you need a bridge.

But “Java C# bridge” isn’t a single product category. It spans open-source transpilers, commercial runtime bridges, communication frameworks, and architectural patterns. Choosing the wrong tool wastes months. This guide evaluates every serious option, with honest assessments of what works and what doesn’t.

Evaluation Criteria

We evaluate each tool against five dimensions that matter in real projects:

Performance — Latency per call and maximum throughput
API Fidelity — How naturally does Java code translate to C# usage?
Maintenance Burden — Ongoing effort to keep the integration working
Maturity — Production readiness, documentation, support
Cost — Licensing, infrastructure, and developer time

Category 1: In-Process Bridges

In-process bridges load the JVM and CLR in the same process (or connected via shared memory), enabling direct method calls without network overhead.

JNBridgePro

JNBridgePro is the established commercial solution for Java-.NET bridging, in production since 2001. It generates .NET proxy assemblies from Java classes, letting C# code call Java methods with native syntax.

How it works: A proxy generation tool inspects your Java JARs and creates matching .NET classes. At runtime, the JNBridgePro runtime manages communication between the CLR and JVM — either through shared memory (same process) or TCP (cross-process/cross-machine).

// C# calling Java via JNBridgePro — looks like native .NET code
using org.apache.kafka.clients.producer;

var props = new java.util.Properties();
props.put("bootstrap.servers", "localhost:9092");
var producer = new KafkaProducer(props);
producer.send(new ProducerRecord("my-topic", "key", "value"));
producer.close();

Dimension	Rating	Notes
Performance	⭐⭐⭐⭐⭐	Shared memory: 0.01-0.1ms/call. TCP: 0.1-1ms/call.
API Fidelity	⭐⭐⭐⭐⭐	Full Java API exposed as native .NET types. Generics, collections, exceptions all translated.
Maintenance	⭐⭐⭐⭐	Regenerate proxies when Java API changes. Runtime is stable.
Maturity	⭐⭐⭐⭐⭐	25+ years in production. Used by Fortune 500 companies. Professional support.
Cost	⭐⭐⭐	Commercial license required. Free evaluation available.

Best for: Enterprise teams that need high-performance, bidirectional Java-C# integration with minimal code changes. The gold standard for in-process bridging.

IKVM.NET

IKVM converts Java bytecode to .NET CIL, allowing Java libraries to run directly on the .NET runtime. Originally created by Jeroen Frijters, the project was revived as IKVM.NET with .NET Core/.NET 6+ support.

How it works: IKVM compiles Java .class files into .NET assemblies at build time. The resulting DLLs can be referenced like any .NET library — no JVM required at runtime.

// C# calling Java via IKVM — Java classes compiled to .NET IL
// Add IKVM NuGet packages and Java JARs as build items
var map = new java.util.HashMap();
map.put("key", "value");
var result = (string)map.get("key");

Dimension	Rating	Notes
Performance	⭐⭐⭐⭐	Native .NET speed for converted code. No bridge overhead. Some JVM-specific optimizations lost.
API Fidelity	⭐⭐⭐	Good for standard Java. Struggles with JNI, native libraries, reflection-heavy frameworks.
Maintenance	⭐⭐	Conversion issues can be opaque. Build integration requires NuGet configuration.
Maturity	⭐⭐⭐	Revived open-source project. Active development but smaller community.
Cost	⭐⭐⭐⭐⭐	Free and open source (MIT license).

Best for: Projects that use pure-Java libraries (no JNI or native code) and want to eliminate the JVM dependency entirely. Works well for libraries like Bouncy Castle, Guava, or Apache Commons. Not suitable for complex frameworks (Spring, Hibernate) or libraries with native components.

JNI (Java Native Interface) — DIY Bridge

Technically possible: write a C/C++ layer that uses JNI to call Java and P/Invoke to call into .NET. This is the “build it yourself” option.

Dimension	Rating	Notes
Performance	⭐⭐⭐⭐⭐	Direct native calls. Potentially the fastest possible.
API Fidelity	⭐⭐	Manual type marshaling for every method. Extremely tedious.
Maintenance	⭐	Any Java API change requires updating C++ glue code.
Maturity	⭐⭐	Well-documented standards (JNI, P/Invoke) but no pre-built solution.
Cost	⭐⭐	Free tools, but massive developer time investment.

Best for: Almost nobody. Only consider this if you need to bridge a single, stable, performance-critical function and have C++ expertise on your team.

Category 2: Network-Based Integration

When the Java and .NET components can (or must) run as separate services.

REST APIs (Spring Boot + ASP.NET)

Dimension	Rating	Notes
Performance	⭐⭐	2-15ms per call. JSON serialization overhead.
API Fidelity	⭐⭐	Requires designing DTOs. Complex object graphs are painful.
Maintenance	⭐⭐⭐	Standard web development practices. Well-understood.
Maturity	⭐⭐⭐⭐⭐	The most common integration pattern in the industry.
Cost	⭐⭐⭐⭐	Free frameworks. Infrastructure costs for running the service.

Best for: Loosely-coupled microservice architectures where Java and .NET services communicate occasionally. Not ideal when you need tight integration or low latency.
For a deeper look at JNBridgePro’s architecture and how it handles real-world integration scenarios, see Anatomy of a Shared Memory Bridge.

gRPC

Dimension	Rating	Notes
Performance	⭐⭐⭐	0.5-3ms per call. Binary Protocol Buffers are faster than JSON.
API Fidelity	⭐⭐⭐	Strongly typed protobuf contracts. Better than REST for complex types.
Maintenance	⭐⭐⭐	Proto file management. Code generation on both sides.
Maturity	⭐⭐⭐⭐	Google-backed. Excellent .NET and Java support.
Cost	⭐⭐⭐⭐	Free. Same infrastructure costs as REST.

Best for: High-throughput microservices that need better performance than REST. Good when you also need streaming or bidirectional communication.

Message Queues (RabbitMQ, Kafka, ActiveMQ)

Dimension	Rating	Notes
Performance	⭐⭐	Asynchronous. Not suited for request/response patterns.
API Fidelity	⭐⭐	Message-based. No method-level integration.
Maintenance	⭐⭐⭐	Broker infrastructure adds operational complexity.
Maturity	⭐⭐⭐⭐⭐	Battle-tested in production everywhere.
Cost	⭐⭐⭐	Free software, but broker hosting has ongoing costs.

Best for: Event-driven architectures, async workflows, and scenarios where decoupling is more important than latency. Not a Java-C# bridge in the traditional sense.

Category 3: Code Generation and Transpilation

Javonet

Javonet is a multi-language runtime bridge that supports calling between Java, .NET, Python, Ruby, and other platforms. It uses a lightweight runtime agent to marshal calls between technology stacks.

Dimension	Rating	Notes
Performance	⭐⭐⭐	Cross-process communication with optimized serialization.
API Fidelity	⭐⭐⭐	Dynamic invocation model. Less type-safe than proxy generation.
Maintenance	⭐⭐⭐	No proxy generation step, but dynamic API can be fragile.
Maturity	⭐⭐⭐	Actively developed. Smaller user base than JNBridgePro.
Cost	⭐⭐⭐	Commercial license. Free tier available for limited use.

Best for: Multi-language environments (not just Java+C#). Good if you also need Python or Ruby integration in the same project.

Hessian / Thrift / Avro

Cross-language serialization frameworks with RPC support. Define your interface in a schema, generate client/server code for both languages.

These are more infrastructure-level tools than Java-C# bridges. They’re worth considering if you’re building a new service architecture from scratch, but they don’t help with “I have a Java JAR and need to call it from C#” scenarios.

Head-to-Head Comparison

Tool	Type	Latency	Needs JVM?	Bidirectional?	License
JNBridgePro	In-process bridge	0.01-1ms	Yes	Yes	Commercial
IKVM.NET	Bytecode compiler	Native	No	No	MIT
Javonet	Runtime bridge	1-5ms	Yes	Yes	Commercial
REST API	Network	2-15ms	Yes (separate)	Yes	Free
gRPC	Network	0.5-3ms	Yes (separate)	Yes	Free
Message Queue	Async	Variable	Yes (separate)	Yes	Free
JNI/P/Invoke	Native bridge	~0.01ms	Yes	Yes	Free

Decision Framework

Use this flowchart to narrow your options:

Do Java and .NET need to run in the same process?

**Yes → **JNBridgePro (if you need the full API) or IKVM (if the library is pure Java)
**No → **Continue below

Is latency critical (sub-millisecond)?

**Yes → **JNBridgePro in shared memory or TCP mode
**No → **Continue below

Do you need synchronous request/response?

**Yes → **gRPC (high throughput) or REST (simplicity)
**No → **Message queue (Kafka, RabbitMQ)

Our Recommendation

For most enterprise teams integrating Java and C#, JNBridgePro is the right starting point. It offers the best combination of performance, API fidelity, and maturity. The commercial license pays for itself quickly when you factor in developer time saved versus building and maintaining REST/gRPC wrappers.

If budget is the primary constraint and your Java libraries are pure Java (no JNI), give IKVM.NET a serious evaluation. For new microservice architectures where Java and .NET are separate services, gRPC provides the best performance-to-complexity ratio.

Ready to evaluate? Download JNBridgePro’s free evaluation and test it against your actual Java libraries.

What tool does your team use for Java-C# integration? I'd love to hear about real-world experiences in the comments — especially if you've tried multiple approaches.

Originally published at jnbridge.com

Java + .NET in Docker & Kubernetes: 3 Architecture Patterns That Actually Work

JNBridge — Fri, 06 Mar 2026 14:16:11 +0000

If you've ever tried to deploy a system where Java and .NET need to talk to each other inside containers, you know the pain. Do you cram both runtimes into one image? Split them into sidecars? Go full microservices with gRPC?

I've been working through each of these approaches for a polyglot trading platform, and there are real trade-offs that most "just use Kubernetes" advice glosses over. Here's what I've learned — with actual Dockerfiles and K8s manifests you can steal.

Why Containerize Java/.NET Integration at All?

Before the how — the why:

Environment parity: Java and .NET versions, runtime configs, and native dependencies are locked into the image. No more "works on my machine" across the JVM and CLR.
Independent scaling: Java and .NET components scale independently — critical when one side is compute-heavy and the other is I/O-bound.
Resource isolation: Kubernetes resource limits prevent a misbehaving JVM from starving the .NET runtime (or vice versa).
Cloud portability: Same images run on EKS, AKS, GKE, or on-prem.

The 3 Architecture Patterns

Pattern 1: Single Container with In-Process Bridge

Both the JVM and .NET runtime run inside a single container, with a bridging technology like JNBridgePro enabling direct in-process method calls.

# Multi-runtime single container
FROM mcr.microsoft.com/dotnet/aspnet:9.0 AS base

# Install JDK alongside .NET runtime
RUN apt-get update && apt-get install -y \
    openjdk-21-jre-headless \
    && rm -rf /var/lib/apt/lists/*

ENV JAVA_HOME=/usr/lib/jvm/java-21-openjdk-amd64
ENV PATH="$JAVA_HOME/bin:$PATH"

WORKDIR /app
COPY --from=publish /app/publish .
COPY java-libs/ ./java-libs/

ENTRYPOINT ["dotnet", "MyIntegrationApp.dll"]

Best for: Tight coupling, sub-millisecond method calls, shared state scenarios.

Trade-offs: Larger image (~400-600MB), both runtimes compete for same resource limits, no independent scaling.

Pattern 2: Sidecar Container

Java and .NET in separate containers within the same Kubernetes pod. They share the pod's network namespace (localhost) and can share volumes.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: integration-service
spec:
  replicas: 3
  selector:
    matchLabels:
      app: integration-service
  template:
    metadata:
      labels:
        app: integration-service
    spec:
      containers:
      - name: dotnet-app
        image: myregistry/dotnet-app:latest
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "512Mi"
            cpu: "500m"
          limits:
            memory: "1Gi"
            cpu: "1000m"
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 10
      - name: java-service
        image: myregistry/java-service:latest
        ports:
        - containerPort: 9090
        resources:
          requests:
            memory: "768Mi"
            cpu: "500m"
          limits:
            memory: "1.5Gi"
            cpu: "1000m"
        env:
        - name: JAVA_OPTS
          value: "-XX:MaxRAMPercentage=75.0 -XX:+UseG1GC"

Best for: Independent container images/build pipelines with low-latency localhost communication (0.1-0.5ms per call).

Trade-offs: Pod scheduling treats both containers as a unit. Startup ordering requires init containers or retry logic.

Pattern 3: Separate Services

Completely separate K8s deployments, communicating via REST, gRPC, or message queues.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: dotnet-frontend
spec:
  replicas: 5
  template:
    spec:
      containers:
      - name: dotnet-app
        image: myregistry/dotnet-frontend:latest
        env:
        - name: JAVA_SERVICE_URL
          value: "http://java-backend:9090"
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: java-backend
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: java-app
        image: myregistry/java-backend:latest

Best for: Loosely coupled, independently scaling systems where call frequency is low.

Trade-offs: Higher latency (1-10ms with serialization), explicit API contracts needed.

How to Choose

Factor	Single Container	Sidecar	Separate Services
Call latency	<0.01ms (in-process)	0.1-0.5ms (localhost)	1-10ms (network)
Image size	Large (both runtimes)	Smaller (separate)	Smallest
Independent scaling	No	No (same pod)	Yes
Object sharing	Direct references	Via bridge protocol	Serialization only
Call volume sweet spot	10,000+ calls/sec	1,000-10,000/sec	<1,000/sec

Rule of thumb: If your Java and .NET components make more than 1,000 cross-language calls per second, Pattern 1 or 2 is the way to go.

Docker Best Practices for Dual Runtimes

Multi-Stage Builds

# Stage 1: Build .NET
FROM mcr.microsoft.com/dotnet/sdk:9.0 AS dotnet-build
WORKDIR /src
COPY src/DotNetApp/ .
RUN dotnet publish -c Release -o /app/publish

# Stage 2: Build Java
FROM eclipse-temurin:21-jdk AS java-build
WORKDIR /src
COPY src/JavaLib/ .
RUN ./gradlew shadowJar

# Stage 3: Production
FROM mcr.microsoft.com/dotnet/aspnet:9.0-noble
RUN apt-get update && apt-get install -y \
    openjdk-21-jre-headless \
    && rm -rf /var/lib/apt/lists/*
ENV JAVA_HOME=/usr/lib/jvm/java-21-openjdk-amd64
WORKDIR /app
COPY --from=dotnet-build /app/publish .
COPY --from=java-build /src/build/libs/*.jar ./java-libs/
ENTRYPOINT ["dotnet", "MyIntegrationApp.dll"]

Production image: ~350-450MB (vs 1GB+ with full SDKs).

JVM Container Tuning

ENV JAVA_OPTS="\
  -XX:MaxRAMPercentage=75.0 \
  -XX:+UseG1GC \
  -XX:MaxGCPauseMillis=200 \
  -XX:+UseStringDeduplication \
  -XX:+ExitOnOutOfMemoryError"

The key: MaxRAMPercentage=75.0 — leaves 25% for .NET + OS overhead. And ExitOnOutOfMemoryError ensures K8s detects OOM via exit code instead of a zombie process.

Health Checks for Dual-Runtime Pods

When both runtimes are in the same pod, your health check must verify both:

public class BridgeHealthCheck : IHealthCheck
{
    private readonly IJavaBridge _bridge;

    public async Task<HealthCheckResult> CheckHealthAsync(
        HealthCheckContext context,
        CancellationToken ct = default)
    {
        try
        {
            var result = _bridge.InvokeJavaMethod(
                "com.company.HealthService", "ping");
            return result == "pong" 
                ? HealthCheckResult.Healthy("Bridge active")
                : HealthCheckResult.Unhealthy("Bridge unresponsive");
        }
        catch (Exception ex)
        {
            return HealthCheckResult.Unhealthy("Bridge failed", ex);
        }
    }
}

# Use startupProbe — JVM can take 10-30s to init
startupProbe:
  httpGet:
    path: /health/ready
    port: 8080
  initialDelaySeconds: 15
  periodSeconds: 5
  failureThreshold: 12  # Allow 60s for JVM + bridge startup
livenessProbe:
  httpGet:
    path: /health/live
    port: 8080
  periodSeconds: 15
  failureThreshold: 3

Pro tip: Use startupProbe instead of a large initialDelaySeconds on liveness. It prevents premature restarts during JVM init while still catching failures fast once running.

Resource Limits — The Common Mistake

resources:
  requests:
    memory: "1.5Gi"   # JVM 768MB + .NET 512MB + OS 256MB
    cpu: "1000m"
  limits:
    memory: "2.5Gi"   # Room for GC spikes
    cpu: "2000m"

Both the JVM and .NET CLR allocate beyond their heap — native memory, thread stacks, code caches, GC overhead. Rule: limit = 1.5× (JVM heap + .NET heap). I've seen too many teams set tight limits and get mysterious OOMKills.

Performance: Cutting Startup Time

JVM startup is the biggest bottleneck. How to fix it:

AppCDS (Class-Data Sharing): Pre-generate a shared archive → JVM startup drops from 10-30s to 3-8s
GraalVM native images: If you don't need full JVM features → startup under 1 second
.NET ReadyToRun: Publish with -p:PublishReadyToRun=true to eliminate JIT at startup
Warm-up endpoints: Pre-load frequently accessed Java classes during the startup probe phase

5 Pitfalls That'll Bite You

No MaxRAMPercentage → JVM tries to use more memory than the container allows → OOMKill
Hardcoded hostnames → Container IPs change on every restart. Use env vars or K8s service names.
No startup probe → K8s kills pod before JVM initializes → infinite restart loop
Single replica → Integration services are critical path. Always 2+ replicas with a PodDisruptionBudget.
Debug config in prod → JMX ports and debug logging should never reach production. Use ConfigMaps.

Real-World Example

A financial services company running a .NET trading platform with a Java risk calculation engine:

Phase 1: Containerize as-is in a single container. In-process bridging with JNBridgePro maintains sub-millisecond latency for thousands of risk calcs/second.
Phase 2: Split to sidecar. Java gets its own container with dedicated memory, preventing GC pauses from impacting the .NET frontend.
Phase 3: Separate deployments. K8s HPA scales Java pods based on CPU during market hours.

The key: JNBridgePro supports all three patterns with config changes, not code rewrites.

TL;DR

>10K calls/sec? Single container with in-process bridge
1K-10K calls/sec? Sidecar pattern with localhost communication
<1K calls/sec? Separate services with gRPC/REST
Always set MaxRAMPercentage for the JVM
Always use startupProbe (not just liveness)
Always run 2+ replicas with PodDisruptionBudget

What pattern are you using for polyglot containers? I'd love to hear about your setup in the comments.

How to Run a Java JAR from C#: 5 Methods Benchmarked

JNBridge — Fri, 27 Feb 2026 23:08:14 +0000

I've tested all 5 approaches to running Java JARs from C# in production — from simple Process.Start() to in-process bridges. Each has real trade-offs that benchmarks alone won't tell you.

Originally published on the JNBridge blog.

Why Run Java JAR Files from .NET?

You’ve got a Java JAR file. Maybe it’s a proprietary library your organization built over years. Maybe it’s an open-source tool like Apache Tika (document parsing), Bouncy Castle (cryptography), or Stanford NLP (natural language processing). Whatever it is, you need its functionality in your C# or .NET application — without rewriting it.

Want the fastest, most reliable approach? JNBridgePro lets you call Java JARs from C# with native method syntax — no process spawning, no HTTP overhead. Download a free evaluation to compare.

This is more common than you’d think. According to Stack Overflow’s developer survey, organizations running both Java and .NET account for over 40% of enterprise environments. The question isn’t whether you’ll need cross-platform interop — it’s how you’ll implement it.

This guide covers every practical method for running Java JAR files from .NET applications, from quick-and-dirty process execution to high-performance in-process bridging. Each approach includes working C# code you can adapt for your project.

Method 1: Process.Start — The Quick and Dirty Approach

The simplest way to run a JAR file from C# is to launch it as a separate process using System.Diagnostics.Process:

using System.Diagnostics;

public class JavaProcessRunner
{
    public string RunJar(string jarPath, string arguments)
    {
        var process = new Process
        {
            StartInfo = new ProcessStartInfo
            {
                FileName = "java",
                Arguments = $"-jar \"{jarPath}\" {arguments}",
                RedirectStandardOutput = true,
                RedirectStandardError = true,
                UseShellExecute = false,
                CreateNoWindow = true
            }
        };

        process.Start();
        string output = process.StandardOutput.ReadToEnd();
        string errors = process.StandardError.ReadToEnd();
        process.WaitForExit();

        if (process.ExitCode != 0)
            throw new Exception($"Java process failed: {errors}");

        return output;
    }
}

When to use this: One-off batch processing, CLI tools, scripts where latency doesn’t matter.

Limitations: JVM startup takes 500ms-2s per invocation. Communication is limited to stdin/stdout/stderr (text only). No shared objects, no callbacks, no streaming. If you’re calling this in a loop, you’re paying that startup penalty every time.

Method 2: Persistent Java Process with stdin/stdout

Avoid repeated JVM startup by keeping a long-running Java process and communicating through stdin/stdout:

public class PersistentJavaProcess : IDisposable
{
    private Process _process;
    private StreamWriter _input;
    private StreamReader _output;

    public PersistentJavaProcess(string jarPath)
    {
        _process = new Process
        {
            StartInfo = new ProcessStartInfo
            {
                FileName = "java",
                Arguments = $"-jar \"{jarPath}\"",
                RedirectStandardInput = true,
                RedirectStandardOutput = true,
                UseShellExecute = false,
                CreateNoWindow = true
            }
        };
        _process.Start();
        _input = _process.StandardInput;
        _output = _process.StandardOutput;
    }

    public string SendCommand(string command)
    {
        _input.WriteLine(command);
        _input.Flush();
        return _output.ReadLine(); // Assumes line-delimited responses
    }

    public void Dispose()
    {
        _input?.Close();
        _process?.Kill();
        _process?.Dispose();
    }
}

Better than Method 1 because you pay the JVM startup cost once. But you’re still limited to text-based communication, and you need to design a request/response protocol (usually JSON lines or a custom delimiter).

Method 3: REST API Wrapper

Wrap the JAR’s functionality in a lightweight HTTP server (Spring Boot, Javalin, or even a simple com.sun.net.httpserver.HttpServer), then call it from C# with HttpClient:

// C# client side
public class JavaApiClient
{
    private readonly HttpClient _client;

    public JavaApiClient(string baseUrl = "http://localhost:8080")
    {
        _client = new HttpClient { BaseAddress = new Uri(baseUrl) };
    }

    public async Task ProcessDocumentAsync(string filePath)
    {
        var content = new MultipartFormDataContent();
        content.Add(new ByteArrayContent(File.ReadAllBytes(filePath)), 
                     "file", Path.GetFileName(filePath));

        var response = await _client.PostAsync("/api/parse", content);
        response.EnsureSuccessStatusCode();
        return await response.Content.ReadAsStringAsync();
    }

    public async Task AnalyzeTextAsync(string text)
    {
        var response = await _client.PostAsJsonAsync("/api/analyze", 
                       new { text });
        return await response.Content
                     .ReadFromJsonAsync();
    }
}

Pros: Well-understood pattern, works across machines, easy to scale horizontally.Cons: HTTP overhead (2-15ms per call), JSON serialization costs, need to run and manage a separate Java service, complex object graphs require custom DTOs.

Method 4: gRPC Bridge

For higher performance than REST, use gRPC with Protocol Buffers:

// proto definition
syntax = "proto3";

service JavaLibrary {
    rpc ProcessData (DataRequest) returns (DataResponse);
    rpc StreamResults (StreamRequest) returns (stream ResultChunk);
}

message DataRequest {
    string input = 1;
    map parameters = 2;
}

message DataResponse {
    string result = 1;
    int32 processingTimeMs = 2;
}

// C# gRPC client
var channel = GrpcChannel.ForAddress("http://localhost:50051");
var client = new JavaLibrary.JavaLibraryClient(channel);

var response = await client.ProcessDataAsync(new DataRequest
{
    Input = "sample data",
    Parameters = { { "mode", "detailed" } }
});

Console.WriteLine($"Result: {response.Result} ({response.ProcessingTimeMs}ms)");

Pros: Binary protocol (faster than JSON), strongly typed contracts, supports streaming.Cons: Still requires a separate Java process, schema management overhead, more complex setup.

Method 5: In-Process Bridge with JNBridgePro (Recommended)

The highest-performance option: load the JVM directly into your .NET process and call Java classes as native .NET objects using JNBridgePro.

How It Works

JNBridgePro generates .NET proxy assemblies from your Java JAR files. These proxies handle all the JVM communication — method calls, object creation, type conversion — transparently. Your C# code doesn’t know it’s talking to Java.

Step-by-Step Setup

1. Download and install JNBridgePro

2. Generate proxies from your JAR: Open the Proxy Generation Tool, add your JAR to the classpath, select the classes you need, and generate a .NET assembly.

3. Reference the proxy assembly in your C# project and start coding:

// Example: Using Apache Tika for document parsing
using org.apache.tika;
using org.apache.tika.metadata;
using org.apache.tika.parser;

public class DocumentParser
{
    private readonly Tika _tika;

    public DocumentParser()
    {
        _tika = new Tika();
    }

    public string ExtractText(string filePath)
    {
        var file = new java.io.File(filePath);
        return _tika.parseToString(file);
    }

    public Dictionary ExtractMetadata(string filePath)
    {
        var metadata = new Metadata();
        var file = new java.io.File(filePath);
        var parser = new AutoDetectParser();
        var handler = new org.xml.sax.helpers.DefaultHandler();

        using var stream = new java.io.FileInputStream(file);
        parser.parse(stream, handler, metadata, new ParseContext());

        var result = new Dictionary();
        foreach (string name in metadata.names())
        {
            result[name] = metadata.get(name);
        }
        return result;
    }
}

Notice the code reads like standard C#. The Tika, Metadata, and AutoDetectParser objects are actually Java classes — but JNBridgePro makes them look and behave like native .NET types.

Real-World Example: Stanford NLP from C

using edu.stanford.nlp.pipeline;
using edu.stanford.nlp.ling;
using java.util;

public class NlpProcessor
{
    private readonly StanfordCoreNLP _pipeline;

    public NlpProcessor()
    {
        var props = new Properties();
        props.setProperty("annotators", 
            "tokenize,ssplit,pos,lemma,ner,parse,sentiment");
        _pipeline = new StanfordCoreNLP(props);
    }

    public List ExtractEntities(string text)
    {
        var document = new CoreDocument(text);
        _pipeline.annotate(document);

        var entities = new List();
        foreach (CoreEntityMention em in document.entityMentions())
        {
            entities.Add((em.text(), em.entityType()));
        }
        return entities;
    }
}

Performance Comparison

We measured each method calling a simple Java computation method (Fibonacci calculation) 10,000 times from C#:

The gap is dramatic. JNBridgePro’s shared-memory mode completes 10,000 calls in under a second — the same workload takes minutes with Process.Start and tens of seconds with REST. For latency-sensitive applications, there’s no comparison.

Which Method Should You Use?

The right choice depends on your specific requirements:

Use Process.Start when you need to run a JAR once (batch job, deployment script, CI pipeline). Don’t use it for anything performance-sensitive.

Use REST/gRPC when the Java and .NET components run on different machines, or when you need the Java service to scale independently. Good for microservice architectures where loose coupling matters more than raw speed.

Use JNBridgePro when performance matters, when you’re calling Java methods frequently, when you need to work with complex Java object graphs, or when you want the simplest possible C# API. It’s the right choice for most enterprise integration scenarios.

Common JAR Integration Scenarios

Scenario 1: Legacy Business Logic

Your company has a Java library that implements complex business rules — pricing engines, risk calculations, regulatory compliance checks. These were developed over years and would cost millions to rewrite. With JNBridgePro, your new .NET front-end calls the existing Java logic directly. No rewrite. No risk of introducing bugs in translation.

Scenario 2: Open-Source Java Libraries with No .NET Equivalent

Some Java libraries have no quality .NET equivalent:

Apache Tika — Document content extraction (supports 1,000+ file formats)
Stanford NLP — Natural language processing
Apache POI — Advanced Excel/Word manipulation
Deeplearning4j — Deep learning on the JVM
JasperReports — Enterprise reporting engine
Lucene — Full-text search (yes, there’s Lucene.NET, but the Java version leads by 2+ years)

<!– /wp:list —

What Is the Best Way to Run a Java JAR File from C#?

The five main methods to run a Java JAR file from C# are: (1) Process.Start — spawns java.exe as a child process, simplest but slowest; (2) REST API wrapper — wraps the JAR in a web service; (3) gRPC service — high-performance RPC with Protobuf; (4) In-process bridge (JNBridgePro) — direct method calls with microsecond latency; (5) IKVM bytecode translation — converts JAR to .NET assembly, limited to Java 8.

Quick Comparison: All 5 Methods at a Glance

Rather than wait for a .NET port or settle for a lesser alternative, use the Java library directly.

Scenario 3: Gradual Migration

Migrating from Java to .NET (or vice versa) doesn’t have to be all-or-nothing. Start new development in your target platform while keeping existing Java components running through a bridge. Migrate individual components when it makes sense, not when you’re forced to.

Deployment Considerations

Regardless of which method you choose, remember:

JDK/JRE must be installed on the deployment target (or bundled with your application)
Match architectures — if your .NET app is x64, your JVM must be x64
Classpath management — all JAR dependencies must be accessible at runtime
Memory planning — the JVM needs its own heap allocation on top of your .NET process memory
Docker considerations — use a base image with both .NET SDK and JDK installed, or a multi-stage build

Getting Started

Ready to integrate a Java JAR into your .NET application? Start here:

Identify your JAR — what classes and methods do you need to call?
Choose your method — Process.Start for simple cases, JNBridgePro for everything else
Generate proxies (if using JNBridgePro) from your JAR’s classes
Write C# code against the generated .NET types
Test and benchmark — verify correctness and measure performance

For detailed setup instructions, see our complete guide to calling Java from C#.

Frequently Asked Questions

Can you run a Java JAR file directly from C# without installing Java?

No — running a Java JAR requires a JVM (Java Runtime Environment or JDK) installed on the machine, regardless of which method you use. Even in-process bridges like JNBridgePro load the JVM within the .NET process. The only exception is IKVM, which translates Java bytecode to .NET CIL — but it has significant limitations with modern Java versions and complex libraries.

What is the fastest way to call Java from C# and .NET?

In-process bridges like JNBridgePro offer the lowest latency — microsecond-level method calls between C# and Java. Process.Start (spawning java.exe) is the slowest at 100ms–2s per invocation due to JVM startup overhead. REST APIs and gRPC fall in between at 1–50ms depending on network and serialization.

Is Process.Start a good way to run JAR files from C# in production?

Process.Start works for simple, infrequent calls but is not recommended for production systems that need performance or reliability. Each call spawns a new JVM process (100ms+ overhead), you lose type safety, error handling is limited to exit codes and stdout parsing, and you must manage process lifecycle manually. Use it for scripts and utilities, not for tight integration.

Can I pass complex objects between C# and a Java JAR?

With Process.Start, you’re limited to strings (command-line arguments, stdin/stdout). REST and gRPC support structured data via JSON/Protobuf. In-process bridges like JNBridgePro provide full object marshaling — you can pass .NET objects to Java methods and receive Java objects back with automatic type conversion, including collections, custom classes, and exceptions.

Does running a Java JAR from .NET work in Docker containers?

Yes. All five methods work in Docker, but your container needs both the .NET runtime and a JDK/JRE installed. Multi-stage Docker builds help keep image sizes manageable. JNBridgePro supports Linux containers with .NET Core/.NET 8/9. See our Docker and Kubernetes guide for container architecture patterns.

Continue Reading

- [Java .NET Integration: All Your Options Compared](https://jnbridge.com/jnbridgepro/java-dotnet-integration-options-compared)

- [Java C# Bridge: Best Tools for 2026](https://jnbridge.com/jnbridgepro/java-csharp-bridge-best-integration-tools)

- [How to Call Java from VB.NET: Complete Guide](https://jnbridge.com/jnbridgepro/call-java-from-vb-net-integration-guide)

Bridge vs REST vs gRPC: How to Choose Your Java/.NET Communication Method

JNBridge — Fri, 27 Feb 2026 23:03:03 +0000

I work on Java/.NET integration tooling at JNBridge. This is a deep comparison of the three main approaches teams use to connect Java and .NET. Originally published on the JNBridge blog.

The Three Contenders
How Each Approach Works
Latency Comparison: The Numbers That Matter
Architecture Trade-Offs
Operational Complexity
When to Use REST for Java .NET Communication
When to Use gRPC for Java .NET Communication
When to Use an In-Process Bridge
Hybrid Architectures: Using Multiple Approaches
FAQ

When your Java and .NET systems need to communicate, three approaches dominate the conversation: REST APIs, gRPC, and in-process bridging. Each solves the same fundamental problem — getting data and commands across the JVM/CLR boundary — but with dramatically different trade-offs in latency, complexity, and architectural flexibility.

This guide provides a direct, numbers-driven comparison to help you choose the right Java .NET communication method for your specific requirements.

The Three Contenders

	REST	gRPC	In-Process Bridge
Protocol	HTTP/1.1 + JSON	HTTP/2 + Protobuf	Shared memory / IPC
Topology	Separate processes	Separate processes	Same process
Serialization	Text (JSON/XML)	Binary (Protobuf)	None (direct references)
Latency per call	5–50ms	1–10ms	Microseconds
Example tools	Spring Boot + HttpClient	grpc-java + Grpc.Net.Client	JNBridgePro

How Each Approach Works

REST: HTTP + JSON Over the Network

Your Java code runs as a web service (typically Spring Boot). Your .NET code sends HTTP requests with JSON payloads. The Java service processes the request and returns a JSON response.

// .NET calling Java via REST
var response = await httpClient.PostAsJsonAsync(
    "http://java-service:8080/api/process",
    new { documentId = 12345, operation = "extract" }
);
var result = await response.Content.ReadFromJsonAsync<ProcessResult>();

What happens per call: .NET serializes C# object → JSON string → HTTP request → TCP transmission → Java deserializes JSON → processes → serializes result → JSON string → HTTP response → TCP transmission → .NET deserializes JSON → C# object.

gRPC: HTTP/2 + Protocol Buffers

You define a service contract in a .proto file, generate client/server stubs in both languages, and communicate over HTTP/2 with binary Protobuf serialization.

// document_service.proto
service DocumentService {
  rpc Process (ProcessRequest) returns (ProcessResponse);
}
message ProcessRequest {
  int64 document_id = 1;
  string operation = 2;
}

// .NET calling Java via gRPC
var client = new DocumentService.DocumentServiceClient(channel);
var response = await client.ProcessAsync(new ProcessRequest {
    DocumentId = 12345,
    Operation = "extract"
});

What happens per call: .NET serializes to Protobuf binary → HTTP/2 frame → TCP → Java deserializes Protobuf → processes → serializes Protobuf → HTTP/2 frame → TCP → .NET deserializes → C# object. Fewer bytes than JSON, multiplexed connections, but still a network round-trip.

In-Process Bridge: Direct Method Calls

The JVM and CLR run inside the same OS process. JNBridgePro generates .NET proxy classes that directly invoke Java methods through shared memory.

// .NET calling Java via JNBridgePro
DocumentProcessor processor = new DocumentProcessor();
ProcessResult result = processor.process(12345, "extract");
// Direct method call — no serialization, no network

What happens per call: .NET proxy invokes JVM method through shared-memory channel → Java executes → result reference returned. No serialization. No network. No HTTP framing. Just a cross-runtime function call.

Latency Comparison: The Numbers That Matter

Per-call latency tells one story. But real-world operations rarely involve a single call. Here's how the three approaches scale with call count:

Calls per operation	REST (avg 15ms/call)	gRPC (avg 3ms/call)	Bridge (avg 5μs/call)
1 call	15ms	3ms	0.005ms
10 calls	150ms	30ms	0.05ms
50 calls	750ms	150ms	0.25ms
100 calls	1,500ms	300ms	0.5ms
500 calls	7,500ms	1,500ms	2.5ms

At 100 calls per operation, REST adds 1.5 seconds of pure integration overhead. gRPC adds 300ms. An in-process bridge adds half a millisecond. This isn't theoretical — enterprise operations that traverse complex Java object graphs routinely make hundreds of cross-runtime calls.

Architecture Trade-Offs

Coupling

REST: Loosest coupling. Java and .NET share only an HTTP contract. Either side can be rewritten, redeployed, or replaced independently. Different teams can own each service.

gRPC: Moderate coupling. The .proto contract is shared and versioned. Changes require coordinated updates to both sides, but the binary contract is more explicit than REST's often-informal JSON contracts.

Bridge: Tightest coupling. .NET code directly references Java classes. Changes to Java APIs immediately affect .NET code — but this is often desirable. You get compile-time type checking instead of runtime HTTP errors.

Scalability

REST/gRPC: Java and .NET scale independently. You can run 10 instances of the Java service behind a load balancer while running 2 instances of the .NET application.

Bridge: Java and .NET scale together (same process). Each application instance includes both runtimes. This is simpler to reason about but means you can't scale the Java component independently.

Failure Isolation

REST/gRPC: If the Java service crashes, the .NET application can handle it gracefully (retry, circuit breaker, fallback). The failure is contained.

Bridge: If the JVM crashes, the .NET process crashes too (they share a process). However, in-process crashes are also rarer — there's no network to timeout, no connection pool to exhaust, no DNS resolution to fail.

Operational Complexity

REST

Deploy and monitor two separate services
Manage service discovery and DNS
Handle connection pooling, timeouts, retries
Version API contracts (breaking changes require coordination)
Cross-service observability (distributed tracing)
TLS certificate management

gRPC

Everything from REST, plus:
Proto file management and code generation pipeline
HTTP/2 load balancer configuration (not all LBs support gRPC natively)
Client-side load balancing considerations
Protobuf schema registry and evolution

In-Process Bridge

Single deployment artifact (includes both runtimes)
JRE/JDK must be available on the target machine (or in the container image)
Memory planning for both CLR and JVM heaps
Single set of logs, single monitoring target
No network configuration required

For teams already running microservices with mature DevOps practices, the operational complexity of REST/gRPC is absorbed into existing infrastructure. For teams without that infrastructure, the simplicity of a single-process deployment is significant.

When to Use REST for Java .NET Communication

Choose REST when:

Java and .NET are owned by different teams with independent release cycles
Call frequency is low (fewer than 10 cross-platform calls per user request)
You need the flexibility to replace either side independently
You're already invested in a microservices architecture with service mesh, API gateway, and observability tooling
The Java functionality is coarse-grained (whole operations, not individual method calls)

When to Use gRPC for Java .NET Communication

Choose gRPC when:

You need better performance than REST but still want separate services
Strong typing at the contract level is important (proto schemas are explicit)
You need bidirectional streaming (gRPC supports server streaming, client streaming, and bidirectional streaming)
Payload sizes are large (Protobuf is 3-10x smaller than JSON for the same data)
Your infrastructure supports HTTP/2 natively

When to Use an In-Process Bridge

Choose JNBridgePro when:

Call frequency is high (tens to hundreds of cross-platform calls per operation)
You need direct access to Java class internals, not just service endpoints
Latency is critical (trading, real-time processing, user-facing applications)
You're integrating a Java library into a .NET application (not connecting two services)
You want the simplest possible deployment (one process, no network dependencies)
You're migrating between platforms and need temporary tight integration

See our full comparison of all Java .NET integration options for a broader view including IKVM, Javonet, and JNI.

Hybrid Architectures: Using Multiple Approaches

The best enterprise architectures often combine approaches:

Example: E-Commerce Platform

Bridge for the .NET order processing service that calls a Java fraud detection library hundreds of times per order (in-process, microsecond latency)
gRPC between the order service and the Java inventory service (separate teams, moderate call frequency, strong contracts)
REST between the platform and a third-party Java shipping API (external service, infrequent calls, maximum decoupling)

Don't force a single integration pattern across every boundary. Match the approach to the specific relationship between the components.

FAQ

Is REST fast enough for Java .NET integration?

For low-frequency calls (fewer than 10 per operation), REST is typically fast enough. The 5-50ms overhead per call is negligible when you're making one or two calls. It becomes problematic when you need dozens or hundreds of calls per operation — the latency compounds linearly and can add seconds to response times.

Can gRPC replace an in-process bridge?

gRPC reduces latency compared to REST (roughly 3-5x improvement) but still involves network serialization. For 100+ calls per operation, gRPC still adds hundreds of milliseconds where an in-process bridge adds less than a millisecond. gRPC also can't provide direct access to Java object graphs — you can only access what you explicitly define in proto contracts.

Does in-process bridging work with containers and Kubernetes?

Yes. A .NET application using JNBridgePro deploys as a single container that includes both the .NET runtime and a JRE. It scales like any other container. The key consideration is memory sizing — allocate enough for both the CLR and JVM heaps.

What about WebSocket or SignalR for Java .NET communication?

WebSocket provides persistent, bidirectional connections — useful for real-time streaming between Java and .NET services. However, it still involves network serialization and doesn't reduce per-message latency below the millisecond range. It's a better fit for push-based scenarios (live updates, event streams) than for request-response patterns.

Can I switch from REST to a bridge later?

Yes, and this is a common migration path. Many teams start with REST for initial integration, discover performance issues as call frequency grows, and move to in-process bridging. JNBridgePro generates .NET proxy classes that mirror Java APIs — so the migration primarily involves replacing HTTP client calls with direct method calls on the proxy objects.

More on Java-.NET integration architecture: