DEV Community: JNBridge

Java and .NET Without REST: Direct Interop Guide

JNBridge — Thu, 24 Sep 2026 13:45:00 +0000

REST is a good default for distributed systems, but it is not a law of nature. If a C# application needs to reuse an existing Java library—or Java needs to call a .NET assembly—turning every class operation into an HTTP endpoint can create more architecture than the problem requires.

This guide compares the main ways to connect Java and .NET without treating REST as the automatic answer. The key is to decide whether you actually need a service boundary, an asynchronous workflow, or a runtime interoperability boundary.

Start with the boundary, not the transport

When someone says “put a REST API around it,” they may be solving several different problems at once:

isolating deployment and failures;
making a capability available to many consumers;
supporting clients in several languages;
crossing a network boundary;
reusing code that happens to run on another runtime.

The first four are legitimate reasons to design a service. The last one may only require direct interoperability.

Suppose a .NET desktop application needs a mature Java calculation library. A REST wrapper means building and operating a Java service, inventing request and response contracts, mapping objects to JSON, handling versioning, securing an endpoint, and deploying another process. That can be worthwhile—but it should be an intentional architecture decision, not a reflex.

Where REST wrappers become awkward

REST works best with coarse-grained resources and operations. It becomes less natural when the real interface is object-oriented, internal, high-churn, or fine-grained.

Wrapper explosion

Every method that crosses the boundary needs an endpoint, payload schema, validation path, error contract, documentation, and tests. A team can accidentally build a second application whose main job is translating between two existing applications.

Lost type semantics

Rich Java and .NET types often become JSON documents plus handwritten mapping code. Overloads, enums, exceptions, object identity, callbacks, and references need new representations. The public contract may be clean, but it is not free.

Chattiness and latency

An object model designed for local calls may make dozens of small calls during one business operation. Mapping each call to HTTP adds serialization, network handling, and request-level observability overhead.

Operational surface area

A new service brings another deployment, health model, certificate path, log stream, monitoring target, and incident runbook. Those costs are justified for an intentional distributed boundary, but harder to defend for internal library reuse.

The main alternatives

Java and .NET can cooperate without REST in several ways. Each option solves a different class of problem.

Pattern	Best fit	Poor fit
Runtime bridge with generated proxies	Typed, direct reuse of Java or .NET classes	Systems that must be fully independent services
Message queue	Asynchronous workflows and event processing	Immediate object-level responses
Shared database	Simple state exchange and reporting	Shared business logic or strong ownership boundaries
Files or object storage	Batch transfers and large artifacts	Interactive operations
Custom sockets or binary protocol	Specialized latency or protocol requirements	Teams that do not want to own protocol infrastructure
REST/gRPC	Coarse-grained, independently deployed services	Thin wrappers around many internal library calls
Rewrite	Retiring an obsolete platform completely	Stable systems whose behavior is expensive to reproduce

The important distinction is that these patterns are not interchangeable. A queue is not a faster REST call. A shared database is not an API. A runtime bridge is not automatically a microservice.

Direct interoperability with generated proxies

A Java/.NET bridge can expose selected types from one runtime as generated proxy types in the other. The application uses local-looking classes and methods while the bridge handles communication, data conversion, object references, and exceptions.

The build flow is usually:

Select the Java classes or .NET assemblies that should cross the boundary.
Generate proxies for that deliberately small surface.
Add the generated JAR or assembly to the consuming project.
Configure where the JVM and CLR sides run.
Call through the proxies using normal Java or C# syntax.

For example, a .NET application consuming a Java risk engine can work with generated .NET proxy classes:

// Generated proxies expose the selected Java API to C#.
var engine = new RiskEngine();

var request = new RiskRequest();
request.setAccountId(accountId);
request.setPositions(positions);

RiskResult result = engine.calculate(request);
Console.WriteLine($"Score: {result.getScore()}");

The exact bootstrap and proxy names depend on the selected bridge configuration, but the architectural point is stable: the consuming code sees a typed API instead of constructing an HTTP request for every method.

The reverse direction works the same way. A Java application can consume selected .NET classes through generated Java proxies.

A bridge still needs a well-designed boundary

Direct calls do not make boundary design irrelevant. Cross-runtime calls are more expensive than ordinary in-process calls, and a large proxy surface can couple two codebases too tightly.

Use the same discipline you would apply to an internal API:

expose stable, meaningful operations rather than every implementation class;
send batches or domain objects instead of making one call per field;
keep object ownership and lifetimes explicit;
translate exceptions into failures the caller can act on;
benchmark realistic object graphs, arrays, callbacks, and concurrency;
regenerate proxies as part of a controlled upgrade workflow.

A useful pattern is a small facade on the provider side. The facade can turn a chatty library into a few coarse operations without forcing the team to build and operate a web service.

Shared memory or separate processes?

“Without REST” does not necessarily mean “everything in one process.” A bridge can support different runtime topologies.

Shared-memory or in-process-style deployment minimizes call overhead when both runtimes run on the same machine and share a lifecycle. It is useful for desktop software, local services, hardware-facing applications, and performance-sensitive library reuse.

TCP/binary deployment keeps the Java and .NET sides in separate processes or on separate machines. It adds isolation while retaining a proxy-based programming model. This is useful when operations require separate restart behavior, security controls, or deployment ownership.

Topology should be an explicit choice. Do not use the lowest-latency option if process isolation is the more important requirement.

When REST or gRPC is still the right answer

Avoiding REST should not become a goal by itself. A service boundary is the better design when:

several independent consumers need the capability;
provider and consumer must deploy independently;
the contract should be language-neutral and externally documented;
the call is naturally coarse-grained;
network isolation or organizational ownership is part of the architecture;
horizontal scaling and service-level observability matter more than object-level reuse.

gRPC is often a stronger option than REST when the team wants an explicit schema, generated clients, streaming, and efficient binary transport. It still creates a service boundary, which is exactly what you want in those scenarios.

A decision framework

Before adding another API, answer these questions:

Who is the consumer? An internal Java/.NET application or a broad set of clients?
What is being reused? A stable library or an independently owned business capability?
How many operations are needed? A few coarse calls or dozens of thin wrappers?
What is the call shape? Batched domain operations or fine-grained object interaction?
Who owns both sides? One team or separate organizations with different release cycles?
What failure isolation is required? Shared lifecycle or independently recoverable processes?
What must be observable? Cross-runtime calls inside one application or a separately operated service?

Choose the smallest boundary that satisfies those requirements.

Production checklist

Whichever pattern you choose, validate more than the happy path:

version the boundary and document compatibility;
test arrays, collections, nulls, exceptions, and object lifetimes;
measure realistic payloads and call frequency;
define startup, shutdown, and restart behavior for both runtimes;
centralize logs and correlation identifiers;
test deployment upgrades and rollback;
limit the exposed surface to what consumers actually need.

Final takeaway

Java and .NET do not need REST merely because they use different runtimes.

Use REST or gRPC when you want a real distributed service. Use messaging for asynchronous workflows. Use files or shared storage for batch exchange. Use a generated-proxy bridge when the actual requirement is direct, typed reuse of existing Java or .NET code.

The best architecture is not the one with the most fashionable transport. It is the one whose boundary matches the ownership, deployment, latency, and maintenance model of the system.

The expanded source guide is available at Java .NET Without REST.

Use NI-DAQmx from Java Without Owning a JNI Layer

JNBridge — Mon, 21 Sep 2026 13:46:51 +0000

If a Java application needs data from National Instruments hardware, the awkward part is rarely the acquisition logic. It is the missing Java API: NI-DAQmx supports C, .NET, Python, and LabVIEW, leaving JVM teams to decide whether to maintain native glue or put another boundary around the driver.

This guide shows a third option: call the supported NI-DAQmx .NET class library from Java through generated proxies. The result is ordinary-looking Java code, block-based sample reads, and no project-specific JNI layer to rebuild whenever the driver or JDK changes.

Why the obvious JNI route becomes expensive

JNI can call the NI-DAQmx C API, but it makes your team responsible for the entire native boundary.

For every operation you expose, you need to own:

a Java native-method declaration;
a C implementation that invokes the matching DAQmx function;
conversions for task handles, channel strings, arrays, and timeouts;
buffer allocation and channel/sample layout;
translation of numeric status codes into useful Java exceptions;
builds and tests across JDK, driver, architecture, and operating-system changes.

The failure model matters, too. A normal Java exception stays inside the runtime. A bad native pointer or buffer calculation can terminate the whole JVM.

JNA and the Foreign Function & Memory API can remove some hand-written C, but they do not remove the ownership problem. You still bind and maintain a large procedural API, manage handles and buffers, and reproduce capabilities already present in NI's supported object-oriented .NET library.

Bridge to the maintained API instead

The NI-DAQmx .NET assembly exposes classes such as Task, AnalogMultiChannelReader, channel collections, timing objects, and enums. A Java/.NET bridge can generate Java proxy classes from that assembly, preserving its object model on the JVM side.

With JNBridgePro, the build-time flow is:

Point the proxy generator at NationalInstruments.DAQmx.dll.
Select the types your application needs.
Generate a JAR containing Java proxies for those .NET types.
Add the proxy JAR and bridge runtime to the Java project.

At runtime, Java calls a proxy. The bridge invokes the real .NET object and returns the result, including arrays and exceptions, across the runtime boundary.

This is an important architectural distinction. The application is not calling a hand-built REST facade or duplicating the driver API. It is using the API that NI already maintains.

What the Java code looks like

Here is a condensed acquisition example. It creates a four-channel voltage task, configures a finite sample clock, and reads 100 samples per channel.

import com.jnbridge.jnbcore.DotNetSide;
import NationalInstruments.DAQmx.*;

public class AnalogInDemo {
    public static void main(String[] args) throws Exception {
        DotNetSide.init("sharedmemory.properties");

        Task task = new Task();
        task.Get_AIChannels().CreateVoltageChannel(
            "Dev1/ai0:3",
            "",
            AITerminalConfiguration.Differential,
            -10.0,
            10.0,
            AIVoltageUnits.Volts
        );

        task.Get_Timing().ConfigureSampleClock(
            "",
            1000.0,
            SampleClockActiveEdge.Rising,
            SampleQuantityMode.FiniteSamples,
            100
        );

        AnalogMultiChannelReader reader =
            new AnalogMultiChannelReader(task.Get_Stream());

        task.Start();
        double[][] data = reader.ReadMultiSample(100);
        task.Stop();
        task.Dispose();

        System.out.printf(
            "Read %d samples on %d channels%n",
            data[0].length,
            data.length
        );
    }
}

Several details are worth calling out:

Proxy packages mirror .NET namespaces, so the code imports NationalInstruments.DAQmx.*.
.NET properties appear through Get_ and Set_ methods, such as Get_AIChannels().
The .NET double[,] returned by ReadMultiSample arrives as a Java double[][], organized by channel and sample.
DAQmx exceptions can cross the bridge as catchable Java exceptions instead of becoming native-process failures.

Keep the boundary coarse enough

A bridge removes JNI maintenance, but it does not make boundary design irrelevant. The fastest call is still the call you do not make.

DAQmx already encourages the right shape: configure work with a small number of calls, let the driver buffer samples, and read blocks. Do not make one cross-runtime call per sample. Read a block with ReadMultiSample, then process that block in Java.

The same rule applies to other hardware SDKs:

create a small facade when the vendor API is excessively chatty;
return arrays or domain batches instead of individual values;
keep object lifetimes explicit;
dispose driver resources deterministically;
test shutdown and failure paths, not only the successful read.

Choose the runtime topology deliberately

There are two useful deployment shapes.

Shared memory hosts the CLR with the Java process and minimizes per-call overhead. It is a good fit for same-machine acquisition where latency matters and the two runtimes share a lifecycle.

TCP/binary runs the .NET side in a separate process or on another machine. It adds a process boundary but provides stronger isolation and options such as TLS and class whitelisting.

The Java API can remain the same across both topologies; configuration determines where the .NET side runs. That gives a team room to begin with a low-latency local deployment and later isolate the driver process if operations require it.

Test without physical hardware

NI MAX can create simulated NI-DAQmx devices. A simulated device exposes the same channels and driver API as physical hardware and produces sample data, which makes it useful for development and CI-oriented smoke tests.

A practical validation plan is:

Install NI-DAQmx with .NET support.
Create a simulated device in NI MAX.
Generate proxies from the installed DAQmx assembly.
Run a finite analog-input read.
Test an invalid channel to verify exception translation.
Repeat a block read under realistic rate and channel-count settings.
Replace the simulated device name with the physical device when hardware is available.

The code path does not need to change when moving from a simulated device to the real one.

When a service boundary is still better

Direct bridging is not the answer to every integration problem.

Put DAQmx behind REST, gRPC, or messaging when acquisition should be an independently deployed service, multiple remote consumers need a stable language-neutral contract, or asynchronous delivery is part of the design.

Use a direct bridge when the Java application needs broad, low-latency access to the existing .NET object model and creating another service would be ceremony rather than intentional architecture.

The decision is less about which transport is fashionable and more about the boundary you actually need: library reuse, process isolation, or a true distributed service.

Final takeaway

The missing NI-DAQmx Java API does not force a choice between rewriting the acquisition layer and maintaining JNI glue forever.

Generated proxies let Java use the supported .NET API, preserve type information, carry arrays and exceptions across the boundary, and keep application code focused on acquisition rather than native interop plumbing.

The full walkthrough, including setup details and the working demo, is in the original NI-DAQmx Java guide.

5 Production-Safe Ways to Connect C# and Java

JNBridge — Thu, 17 Sep 2026 13:44:56 +0000

Most C#-to-Java demos make the first call look easy. Production is where the real questions appear: who owns the contract, what crosses the boundary, what happens when one runtime fails, and how much operational machinery does the integration add?

This guide compares five approaches that actually survive production—generated proxies, REST, messaging, gRPC, and custom sockets—and gives you a practical way to choose among them.

The short version

Start with the boundary your system needs, not a favorite technology.

If your requirement is...	Start with...
Call an existing Java library directly from C#	Generated proxy bridge
Keep Java and .NET as independently deployed services	REST or gRPC
Process work asynchronously and absorb traffic spikes	Message queue
Share a typed streaming contract between services	gRPC
Implement a specialized binary protocol with unusual latency constraints	Custom sockets

The distinction between a library boundary and a service boundary is the most important decision in this entire comparison.

1. Generated proxies and runtime bridging

A Java/.NET bridge generates C# proxy classes from Java bytecode. Your .NET code calls those proxies as typed objects while the bridge handles JVM startup, method invocation, object identity, marshalling, exceptions, and garbage-collection coordination.

The application code can look like this:

using com.example.analytics;

var engine = new AnalyticsEngine();
double score = engine.computeScore("customer-42");

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

AnalyticsEngine is a generated .NET proxy backed by the real Java object. Developers get normal C# method signatures and IDE completion instead of string-based reflection calls.

Use this when:

the Java asset is a JAR or library, not a service;
C# must call many Java classes or methods;
calls are frequent or latency-sensitive;
complex object graphs, callbacks, or exceptions cross the boundary;
you want to reuse Java code without designing an API wrapper around every operation.

Watch for:

JDK and .NET version compatibility;
JVM lifecycle and classpath configuration;
platform-specific deployment details;
choosing between an in-process or remote bridge topology.

JNBridgePro is one production-oriented implementation of this model. It supports generated proxies and both in-process shared-memory and TCP/binary deployment options.

2. REST API

REST is the familiar service-boundary choice. Put the Java logic behind Spring Boot, Quarkus, Jakarta EE, or another HTTP server, then call it with HttpClient from .NET.

using System.Net.Http.Json;

var client = new HttpClient
{
    BaseAddress = new Uri("https://analytics.internal/")
};

var response = await client.PostAsJsonAsync(
    "scores",
    new { CustomerId = "customer-42" });

response.EnsureSuccessStatusCode();
var result = await response.Content.ReadFromJsonAsync<ScoreResponse>();

REST works best when the Java component should already be an independently deployed service.

Use this when:

the call is coarse-grained;
HTTP latency is acceptable;
teams need independent deployment and scaling;
the contract should be language-neutral and externally visible;
your organization already operates HTTP services well.

Watch for:

JSON serialization differences such as BigDecimal versus decimal;
retries that accidentally duplicate non-idempotent work;
API versioning and backward compatibility;
authentication, tracing, rate limits, and another network failure mode;
endpoint sprawl when a C# application needs broad access to a Java library.

REST is a strong architecture when you really want a service. It is expensive ceremony when you only need to reuse a local Java API.

3. Message queues and event streams

With RabbitMQ, Kafka, Azure Service Bus, or a similar broker, C# publishes a command or event and Java consumes it asynchronously.

This changes more than the transport. The caller no longer gets an immediate method return; the architecture becomes eventually consistent.

Use this when:

work can happen asynchronously;
producers and consumers need independent scaling;
bursts should be buffered instead of overwhelming Java workers;
replay, fan-out, or durable event history matters;
temporary consumer downtime must not lose work.

Watch for:

idempotency and duplicate delivery;
dead-letter queues and poison messages;
schema evolution;
ordering guarantees;
observability across an asynchronous workflow;
correlation when a later event represents the result.

Do not add a queue to imitate a synchronous method call. Use one because asynchronous processing is part of the business and operational model.

4. gRPC

gRPC provides a typed remote procedure call boundary. You define messages and services in Protocol Buffers, then generate both C# and Java clients or servers.

syntax = "proto3";

service Analytics {
  rpc ComputeScore (ScoreRequest) returns (ScoreReply);
}

message ScoreRequest {
  string customer_id = 1;
}

message ScoreReply {
  double score = 1;
}

Compared with REST/JSON, gRPC typically offers a more compact wire format, generated contracts, HTTP/2 multiplexing, and first-class streaming.

Use this when:

Java and .NET are separate internal services;
both teams can share and govern a .proto repository;
streaming or high call volume matters;
generated clients are preferable to hand-maintained HTTP models.

Watch for:

protobuf compatibility rules and field-number discipline;
deadlines, cancellation, and retry policies;
HTTP/2 support through every proxy and load balancer;
debugging and browser visibility compared with JSON;
the fact that this is still a network boundary.

gRPC solves service-to-service communication well. It does not remove the operational cost of running another service.

5. Custom sockets or named pipes

At the lowest level, a C# process and Java process can exchange bytes over TCP, Unix domain sockets, or named pipes. You control framing, encoding, batching, backpressure, and connection pooling.

That control is the reason to choose custom sockets—and the reason to avoid them by default.

Use this when:

the protocol already exists;
a device or vendor format requires it;
payload framing or latency requirements cannot be met by supported alternatives;
the team has long-term ownership of both ends.

Watch for everything: reconnect behavior, partial reads, framing, timeouts, authentication, encryption, version negotiation, backpressure, observability, and graceful shutdown.

A fast prototype can become a private integration framework your team must maintain indefinitely.

Comparison matrix

Method	Boundary	Type safety	Typical call style	Operational cost	Best fit
Proxy bridge	Library/runtime	Generated APIs	Fine-grained, synchronous	Low to medium	Direct Java library reuse
REST	Network service	OpenAPI or models	Coarse-grained request/response	Medium	Public or conventional HTTP services
Message queue	Async broker	Schema-dependent	Commands and events	Medium to high	Event-driven workflows
gRPC	Network service	Protobuf-generated	RPC and streaming	Medium	Internal typed services
Custom socket	Process/network	Manual	Protocol-specific	Very high	Specialized protocols

Latency numbers vary too much by payload, topology, TLS, serialization, and infrastructure to choose from a generic benchmark. Measure your real object sizes and call patterns.

A decision tree you can use in an architecture review

Ask these questions in order:

Is the Java component already an intentional service?

If yes, keep that boundary and choose REST or gRPC.
Does the caller need an immediate result?

If no, consider a queue or event stream.
Is the asset fundamentally a library that C# needs to use directly?

If yes, evaluate generated proxies before building service wrappers.
Do you need streaming or a shared cross-language RPC contract?

If yes, gRPC is usually a better fit than REST.
Does an external protocol force raw sockets?

If no, avoid owning custom transport infrastructure.
How many Java APIs must C# reach?

Broad, object-heavy access strongly favors a bridge. A few coarse operations fit a service boundary better.

Production checks that demos usually omit

Whichever approach you choose, test failure behavior before performance tuning.

What happens when Java starts slowly or is unavailable?
Can a call be retried safely?
How are Java exceptions represented in C#?
Who owns schema or proxy regeneration after an upgrade?
Can logs and traces follow one request across the boundary?
How are credentials and transport encryption managed?
Which runtime shuts down first during deployment?
Can you reproduce the production topology in CI?

For bridge-based calls, test arrays, collections, callbacks, exceptions, and object identity—not just strings and integers. For service boundaries, test timeouts, partial failures, backward compatibility, and overload behavior.

Final rule of thumb

If C# needs to reuse Java as a library, treat it as an interoperability problem and evaluate generated proxies first.

If Java and .NET should be independently deployed services, use REST or gRPC intentionally. If the workflow is truly asynchronous, use a broker. Reach for custom sockets only when the protocol itself is part of the requirement.

The safest production design is usually the one whose boundary matches the system you actually have—not the trendiest transport.

For the longer architecture guide and implementation details, see the original JNBridge article.

Calling a Java Logging Package from .NET

JNBridge — Mon, 14 Sep 2026 13:50:33 +0000

Most Java/.NET interop demos stop at returning a string. Logging is a better test: it touches a real Java library, configuration, object marshalling, and two runtimes that need to produce one coherent output.

This walkthrough uses JNBridgePro 12.1 to call Apache log4j from C#. The .NET and Java code both write through the same Java logging stack, so their messages appear together under one configuration.

What we are building

The finished console application does three things:

calls log4j classes directly from C# through generated .NET proxies
invokes an existing Java class whose doIt() method also logs through log4j
runs with either an in-process shared-memory bridge or a separate Java process over TCP/binary

The example uses log4j, but the workflow is the same for any Java JAR or class library that a .NET application needs to reuse.

Prerequisites

You will need:

a Java JDK
the .NET SDK and, for this demo target, the .NET Framework 4.8 targeting pack
JNBridgePro 12.1 (an evaluation license is enough)
log4j.jar, log4j-core.jar, and the compiled loggerDemo.JavaClass

The sample files ship in demos\tutorials\logDemo.zip. This walkthrough assumes they are unpacked under C:\NewGui\LogDemo.

1. Build the Java classpath in JNBProxy

Launch JNBProxy and choose Create new .NET → Java project.

Add both log4j JARs to the classpath, then add the folder containing the loggerDemo package. You can drag the files and folder into the classpath panel or use Edit classpath….

Next, load the types:

Use Add Classes from JAR for log4j.jar.
Repeat for log4j-core.jar.
Use Add Classes from Classpath for loggerDemo.JavaClass.
Leave Include supporting classes enabled.

Select the classes you want to expose, click Add+, and build the proxy assembly as LoggerDemoProxy.dll.

The generated assembly gives C# a typed surface for the Java APIs. Package names become .NET namespaces, and Java methods appear as methods on the proxy classes.

2. Export a runnable .NET project

From the exposed-proxies gear menu, choose Export demo project… and select the proxy DLL you just built.

Name the project LoggerDemo, choose .NET Framework 4.8 (Windows), and export it. JNBProxy can also export projects for modern .NET on Windows or Linux.

One easy mistake matters here: do not give the project the same name as the proxy assembly. A project called LoggerDemoProxy would emit an assembly that collides with LoggerDemoProxy.dll. Keeping the project as LoggerDemo avoids that runtime failure.

The export includes:

LoggerDemo.sln
a C# console project with references to the proxy assembly and JNBridge runtime
shared-memory and TCP configuration files
the Java-side runtime and classpath files
env.bat
one-click build/run scripts for both communication modes
a README explaining the generated layout

That starter project is useful beyond demos: it provides a known-good baseline before you fold the bridge into a larger solution.

3. Prove the generated bridge first

Set JAVA_HOME in env.bat. The script derives the 64-bit jvm.dll path used by shared-memory mode; you can also confirm that path in the generated App.config.

Run buildAndRunSharedMem.bat before adding application logic. The exported stub round-trips a call through java.lang.Object. If it prints a Java hash string, the JVM, classpath, and proxy runtime are connected.

If you instead get ClassNotFoundException or NoClassDefFoundError, check for a moved JAR, an incorrect class-folder root, or missing read permissions. Fix the classpath before debugging the C# code.

4. Call log4j from C

Replace the generated Program.cs with this:

using System;
using org.apache.log4j;
using java.lang;
using loggerDemo;

namespace LoggerDemo
{
    class Program
    {
        static Category cat =
            Category.getInstance("com.jnbridge.demos.logger.LoggerDemo");

        [STAThread]
        static void Main(string[] args)
        {
            BasicConfigurator.configure();

            cat.info(new JavaString("Entering application"));

            DotNetClass dotNetClass = new DotNetClass();
            JavaClass javaClass = new JavaClass();

            for (int i = 0; i < 5; i++)
            {
                dotNetClass.Log();
                javaClass.doIt();
            }

            cat.info(new JavaString("Exiting application"));
        }
    }

    public class DotNetClass
    {
        static Category cat =
            Category.getInstance("com.jnbridge.demos.logger.DotNetClass");

        public void Log()
        {
            cat.debug(new JavaString("Logged from .NET"));
        }
    }
}

There are three details worth noticing.

First, the using directives mirror Java package names: org.apache.log4j, java.lang, and loggerDemo. The application calls Category, BasicConfigurator, and JavaClass as typed APIs, with IntelliSense available in Visual Studio.

Second, the strings passed to info() and debug() are wrapped in java.lang.JavaString. Those overloads expect a Java Object; a CLR string is not itself a Java object, while the proxy wrapper is.

Third, the loop alternates a .NET-originated logging call with JavaClass.doIt(). Both ultimately use the same log4j configuration and output.

Run buildAndRunSharedMem.bat again. You should see the Java and .NET messages interleaved in one console log.

Shared memory versus TCP

The exported project supports two topologies.

Shared-memory mode loads the JVM into the .NET process:

<dotNetToJavaConfig
    scheme="sharedmem"
    jvm64="C:\Program Files\Java\jdk-11\bin\server\jvm.dll"
    jvm32=""
    jnbcore="jnbcore.jar"
    bcel="bcel-6.10.0.jar"
    classpath=".;log4j.jar;log4j-core.jar;C:\NewGui\LogDemo"
/>

This is the simplest and fastest option when both runtimes can live in one process. The JVM starts automatically before the first proxy call.

TCP/binary mode keeps Java in a separate process:

<dotNetToJavaConfig
    scheme="jtcp"
    host="localhost"
    port="8085"
    useSSL="false"
/>

In this topology, the Java classpath moves to the Java-side configuration. buildAndRunTCP.bat builds the .NET project, starts the Java side, runs the demo, and shuts Java down afterward. TCP mode also supports SSL and class whitelisting for tighter deployment boundaries.

The reusable pattern

The useful part of this demo is not log4j itself. It is the repeatable integration sequence:

add the Java JARs and class folders
expose the required classes and generate typed proxies
export a working starter project
prove the bridge before adding application code
choose shared memory or TCP based on deployment needs

That lets a .NET team reuse a proven Java library without translating it, wrapping every method in HTTP, or hiding integration details behind string-based runtime calls.

The complete illustrated walkthrough, including every JNBProxy screen and the generated project layout, is available in the original JNBridge guide.

C# and Java Interprocess Communication: Sockets, APIs, and Bridges Compared

JNBridge — Thu, 13 Aug 2026 13:23:32 +0000

When Java and C# need to cooperate, a lot of teams jump straight to "just expose a REST API." Sometimes that is the right answer. Sometimes it is a workaround for the wrong boundary.

If your C# and Java systems need to exchange a small amount of business data, REST or gRPC may be the cleanest path. If they need to move work asynchronously, messaging fits better. If they are already separate services, sockets can still make sense in specialized environments. And if the real problem is that one runtime needs to call the other's library or object model directly, a bridge is often the better fit.

This is the practical comparison I wish more teams made before they committed to the wrong architecture.

The first question: what kind of boundary do you actually have?

Most interprocess communication choices are not about language at all. They are about the shape of the integration boundary.

Ask a few simple questions:

Is the Java side a service already?
Does the C# side need synchronous answers?
Is the interaction coarse-grained or fine-grained?
Do the runtimes need to share object models?
Is the work better handled as a command, an event, or a direct method call?

Once you answer those, the right integration pattern usually becomes obvious.

Sockets: useful when you need full protocol control

Raw sockets are the low-level option. Java has java.net.Socket, and .NET has System.Net.Sockets. Both can move bytes efficiently over TCP, and both give you complete control over framing, serialization, and connection behavior.

That makes sockets a reasonable choice when:

you already have a custom protocol
latency matters and every layer counts
the payloads are small and predictable
the environment is tightly controlled

The downside is that sockets are not an application protocol. Your team owns the hard parts:

framing and message boundaries
serialization and versioning
timeouts and reconnect logic
authentication and encryption
diagnostics and observability

If the protocol is already a strategic asset, that control is valuable. If not, sockets can turn into a maintenance tax very quickly.

REST APIs: best for coarse-grained service boundaries

REST is still the default answer for a reason. It is easy to understand, easy to debug, firewall-friendly, and widely supported by both Java and .NET tooling.

REST works well when the C# and Java systems are intentionally separate services and the interaction is business-level rather than object-level. Examples include:

create an order
look up inventory
submit a document for processing
request a calculation result

REST is especially attractive when operations teams need visibility. Logs are easy to inspect, requests can be replayed with curl or Postman, and API gateways know what to do with HTTP.

The tradeoff is that REST is also a wrapper. It adds serialization, network hops, and a service boundary even when what you really want is direct reuse of an existing library.

gRPC: strong contracts with better performance than REST

If REST feels too loose or too chatty, gRPC is often the next place to look. It gives you typed contracts, generated clients, and efficient binary transport over HTTP/2.

gRPC is a strong fit when:

the Java and .NET apps are independent services
both teams can agree on a schema-first contract
you want streaming or lower-latency calls
you want more structure than ad hoc JSON

The catch is operational compatibility. HTTP/2, TLS, ingress proxies, load balancers, and service meshes all need to behave nicely. If your environment is already service-oriented, that is manageable. If not, it can become a distraction.

Messaging: best when the two runtimes should not wait on each other

Messaging solves a different problem. Instead of asking one side to wait for the other, you publish work and let a consumer process it later.

This is a great fit for:

workflows
event-driven systems
telemetry pipelines
background jobs
batch processing

Common brokers include RabbitMQ, Kafka, Azure Service Bus, and ActiveMQ. A C# service can enqueue work for Java consumers, or Java can emit events that C# systems react to later.

Messaging improves resilience, but it changes the programming model. You now need:

idempotent handlers
retry policies
dead-letter queues
correlation IDs
schema evolution
monitoring and alerting

Use messaging when the business process is naturally asynchronous. Do not force it in when the user expects an immediate response.

Bridges: best when you need direct Java and .NET API reuse

Sometimes the real need is not service-to-service communication. Sometimes one runtime needs the other runtime's library, SDK, or object model.

That is where a bridge fits.

With a proxy-based bridge such as JNBridgePro, a Java app can call .NET classes or a C# app can call Java classes without wrapping everything in HTTP. The generated proxies let developers work with familiar types and method calls while the bridge handles runtime startup, marshalling, and exception translation.

This is often the right answer when:

the target is a library, not a service
the calls are fine-grained
the integration needs to feel native
you want to reuse working code instead of rewriting it

That is a very different problem from "two services need to exchange JSON."

A quick comparison

Pattern	Best fit	Strengths	Tradeoffs
Sockets	Custom protocols, controlled environments	Low overhead, flexible, universal	You own everything above TCP
REST	Independent service boundaries	Simple, observable, familiar	More overhead than binary protocols
gRPC	Typed service contracts	Fast, structured, good for streaming	Needs HTTP/2-compatible infrastructure
Messaging	Async workflows and events	Decoupled, resilient, scalable	Not a direct function call
Bridge	Direct library/object reuse	Native-style calls, less wrapper code	Tighter runtime coupling

How to choose without overthinking it

A simple rule of thumb works surprisingly well:

choose REST if the boundary is already a business service
choose gRPC if you want a stronger contract and better performance
choose messaging if the work should be asynchronous
choose sockets only when you need protocol-level control
choose a bridge when one runtime needs to call the other's APIs directly

If your Java code needs to invoke a .NET DLL repeatedly during one user action, forcing that through HTTP is usually the wrong abstraction. If the systems are already separate services, then HTTP or gRPC is often the cleanest route.

A production checklist that matters more than the diagram

Before you commit to any pattern, check the boring stuff:

Who owns retries and timeouts?
What happens on partial failure?
How do you log exceptions across runtimes?
What is the deployment story?
Who supports the system at 2 a.m.?
How expensive is versioning?
Do you need sync or async semantics?

The wrong choice is usually the one that looks elegant on a slide but becomes hard to operate in production.

Final thought

The best C# and Java interprocess communication pattern is not the one that sounds most modern. It is the one that matches the boundary you actually have.

If the problem is direct library reuse, a bridge is often the cleanest answer. If the problem is service integration, REST or gRPC may be better. If the problem is async work, use messaging. If you need complete protocol control, sockets still have a place.

The important thing is to choose intentionally, not by habit.

C# Lucene Options: Run Java Lucene from .NET or Use Lucene.NET?

JNBridge — Mon, 10 Aug 2026 13:22:37 +0000

If you work in .NET long enough, you eventually run into a Java library that is too useful to ignore. Apache Lucene is a classic example: it is the engine behind a lot of serious search systems, and it still shows up in enterprise environments where the Java side is already proven and the .NET side needs to catch up.

That leaves teams with a practical question: should you switch to Lucene.NET, wrap Lucene behind REST, or call the real Java library from C#?

Originally published on the JNBridge blog.

The three realistic Lucene options

For most .NET teams, the decision comes down to one of three paths:

Option	Best for	Tradeoffs
Lucene.NET	You can live with the .NET port and its API/feature differences	Port parity can lag Java Lucene versions and behavior may not match exactly
REST wrapper around Java Lucene	You already run Lucene as a separate service	Adds serialization, latency, and another deployment boundary
JNBridgePro calling Java Lucene directly	You need the actual Java Lucene library from .NET	Requires bridge setup, but keeps direct access to the real Java API

In practice, the right answer depends on what you need to preserve.

If you only need “search-like” behavior, Lucene.NET may be enough.
If you need the exact Java Lucene implementation, a bridge is usually the safer production choice.
If your Java Lucene code is already a service, REST may be acceptable.

Why Lucene.NET is sometimes enough

Lucene.NET is the obvious place to start when your team wants a .NET-native codebase and can tolerate differences from Java Lucene.

It can be a good fit when:

the feature set you need exists in the .NET port
you do not need exact Java parity
the search component is not tightly coupled to other Java libraries
the team prefers a pure .NET stack for operational simplicity

But Lucene.NET is still a port. That matters when you depend on a very specific analyzer, query behavior, or version-specific Lucene capability that exists first in Java.

Why a REST wrapper is often a compromise

A REST API can be the easiest way to put a boundary around Lucene if the Java side is already running separately.

That works well when:

Lucene is already part of a separate Java service
calls are coarse-grained
latency is acceptable
you want clear service boundaries and independent deployment

The downside is that search workloads often want more than a few coarse service calls. If your .NET application needs frequent access to Lucene internals, REST can turn a library integration problem into a distributed systems problem.

Why direct Java access is often the best production answer

If your team needs the real Java Lucene library inside a .NET application, JNBridgePro is the option worth evaluating first.

JNBridgePro runs the JVM alongside the CLR and generates .NET proxies for Java classes. That means your C# code can talk to Java Lucene as if it were a native .NET dependency, without rewriting the search logic or hiding the API behind a custom REST layer.

That matters when you need:

exact Java Lucene behavior
complex query or analyzer interactions
low latency
fewer translation layers between C# and Java
a production path that avoids rewrite risk

A practical decision checklist

Before you pick a path, ask these questions:

Do you need the exact Java Lucene implementation, or just a search engine with similar behavior?
Is the Java code already a service boundary, or is it a library you want to call directly?
How often will the .NET side call Lucene?
Do you need complex objects, callbacks, or rich API access?
What is the cost of a mismatch if Lucene.NET behaves differently?
How much deployment overhead can your team tolerate?

Those answers usually make the decision obvious.

My short recommendation

If you can stay on Lucene.NET without losing critical behavior, that can be the simplest path.

If the Java Lucene code already lives behind a service boundary, REST may be good enough.

But if the .NET application needs the real Java Lucene library and you want to avoid rewrite risk, JNBridgePro is usually the strongest option.

Canonical source: How to Use Java Libraries in .NET Core/.NET 8/9

C# J2EE Support: Connecting .NET Applications to Legacy Java Enterprise Systems

JNBridge — Thu, 06 Aug 2026 13:24:29 +0000

If you’re a .NET team staring at a Java enterprise stack that refuses to go away, you’re not alone. A lot of migration work is really integration work in disguise: a new C# front end, an ASP.NET Core portal, or a cloud modernization effort that still depends on old J2EE business logic, EJBs, JMS queues, or app-server code that has already survived every rewrite attempt.

That is why “C# J2EE support” is still a real architecture problem in 2026. The question is not whether Java enterprise systems are legacy. The question is how to connect to them without turning stable business logic into a risky rewrite project.

Originally published on the JNBridge blog.

What C# J2EE support means

C# J2EE support is the ability for .NET applications to interoperate with Java enterprise systems, including legacy J2EE apps, Java EE services, application-server components, and Java business logic.

In plain English:

your business logic still lives in Java
your new application is written in C#
the two sides need to talk without forcing a rewrite

That old J2EE name still shows up in real systems because enterprises rarely replace everything at once. Banks, insurers, logistics companies, healthcare vendors, manufacturers, and government systems often still depend on Java enterprise code that has been hardened in production for years.

If the Java side owns important business behavior, the safest path is usually to reuse it first and modernize around it.

Why .NET teams still need J2EE integration

A .NET J2EE integration project usually starts with a business constraint, not a technology preference.

Typical scenarios include:

a new ASP.NET Core portal calling into Java business rules
a C# desktop app needing access to Java libraries
a cloud migration where the Java app server stays in place for now
a modernization project where the Java workflow is still the source of truth
a vendor SDK distributed only as Java classes

The temptation is to rewrite the Java side in C#. On paper, that looks clean. In practice, it often means recreating behavior the business already depends on, retesting edge cases, and rediscovering years of hidden assumptions.

That is why many teams choose integration first. Keep the Java system working. Let the .NET side call into it. Then decide later whether any piece is worth rewriting.

Common ways to connect C# and J2EE

There is no single right answer. The best option depends on how much of the Java object model the .NET side needs, how fast the calls must be, and who owns the Java runtime.

Approach	Best fit	Strengths	Tradeoffs
REST API wrapper	Coarse service calls	Simple, language-neutral, easy to monitor	Requires Java-side API work; may hide rich object behavior
SOAP / legacy web services	Existing enterprise Java services	Often already present in J2EE systems	Verbose contracts, older tooling, slower evolution
Messaging / JMS bridge	Asynchronous workflows	Durable, scalable, good for long-running processes	Not ideal for immediate request-response logic
Database-level integration	Reporting or simple handoff	Minimal app changes in some cases	Tight coupling to schema; bypasses business logic
Java/.NET bridge	Direct Java class or library reuse	Preserves Java behavior and object model	Requires bridge runtime planning and deployment discipline
Full rewrite	Retiring the Java system	One stack after completion	High cost, high risk, heavy testing burden

Many real systems end up using more than one pattern. A .NET app might use REST for one Java service, messaging for background jobs, and a bridge for a complicated Java library that would be painful to wrap by hand.

When APIs are enough

If the J2EE system already exposes stable service interfaces and your .NET application only needs high-level operations, an API boundary can be the right choice.

APIs work best when:

the Java team owns and maintains the service
calls are coarse-grained and business-oriented
independent scaling matters
network latency is acceptable
the .NET side does not need the full Java object model
monitoring, authentication, and versioning are already in place

This is often the right answer when the Java app server is already treated as a service boundary.

But APIs become less attractive when the .NET side needs many fine-grained calls, complex object interaction, callback behavior, or access to Java libraries that were never designed as services.

When bridging is better than wrapping everything

Java/.NET bridging becomes interesting when the Java asset is not just a remote application, but a library, SDK, rules engine, or enterprise component that .NET developers need to call directly.

A bridge can make sense when:

the Java API surface is large
object identity or object graphs matter
the Java code is stable and trusted
rewriting would create business risk
hand-writing a REST wrapper for every method would be wasteful
the .NET app needs lower-latency or more natural calls

JNBridgePro supports this by generating proxies between the runtimes. Instead of manually translating every Java class into a custom endpoint, .NET code can call Java functionality through generated .NET-facing proxies while the Java code continues to run as Java.

That is especially useful for C# J2EE support scenarios where the business logic is packaged in Java classes or enterprise libraries that can be invoked outside the original UI.

A practical architecture checklist

Before choosing an integration pattern, map the system honestly. Legacy enterprise Java systems often hide more assumptions than the documentation suggests.

Ask these questions:

What is the real unit of reuse: a Java class, business service, EJB, batch job, app-server endpoint, database procedure, or vendor JAR?
Are the calls coarse business operations or many fine-grained method calls?
Who controls the Java runtime, app server, JDK version, and configuration?
Does the Java code assume sessions, transactions, thread-local context, or container-managed resources?
What happens if the Java side is unavailable, slow, or returns partial results?
How are credentials, authorization, audit logging, and data boundaries handled?
Is the Java code strategic, or is it something you can safely retire later?

Those questions matter because an architecture is only good if it is supportable in production.

Example: a modern .NET app with an existing J2EE rules engine

Imagine an insurance company building a new C# portal for brokers. The portal needs fast access to rating rules that already live inside a Java enterprise system. Those rules have been audited, tested, and refined over years.

A rewrite would require the team to reproduce every rule in C#, revalidate edge cases, and run parallel testing for months. A database shortcut would bypass business logic. A REST wrapper might work if the rating operation is coarse and stable.

But if the portal needs direct access to a Java rules library with rich objects and multiple call paths, bridging may be cleaner.

In a bridged design, the C# portal can call Java rating classes through generated proxies. The Java code remains the source of truth. The .NET team can build the new user experience without duplicating the enterprise logic.

That is the kind of integration decision that keeps modernization moving without forcing the business into a rewrite.

Final thought

C# J2EE support is not just about connecting two languages. It is about preserving working enterprise logic while modernizing the front end, the deployment model, or the cloud strategy around it.

If the Java side is already exposed as a service, APIs may be enough. If the .NET side needs direct access to Java classes, libraries, or object graphs, a Java/.NET bridge is often the better fit.

The goal is simple:

keep the Java system stable
let the .NET application move forward
choose the integration pattern that fits the real boundary

Canonical source: C# J2EE Support: Connecting .NET Applications to Legacy Java Enterprise Systems

How to Connect Java to C# and Run .NET Libraries from Java

JNBridge — Mon, 03 Aug 2026 13:25:29 +0000

If most "Java to C#" articles seem to assume the direction is always C# calling Java, this one flips the problem around.

Enterprise teams run into the reverse interop case all the time: a Java application needs a .NET library that already works, already carries business rules, and already has production history. Rewriting that library into Java is usually the most expensive way to solve the problem.

This is a developer-first walkthrough of the real options for calling .NET from Java, loading .NET DLLs in Java, and choosing the path that fits your call pattern instead of forcing everything through a service boundary.

The reverse interop problem

Java and .NET are both mature managed runtimes, but they do not share memory, type systems, or calling conventions.

That means the answer to "how do I use a C# library from Java?" is never just import.

Typical examples include:

A Java service that needs a .NET PDF renderer
A Java app that acquired a vendor DLL as part of a merger
A Java platform that needs a compliance or rules engine written in C#
A modernization project that is moving away from .NET, but not fast enough to rewrite everything at once

In each case, the business question is the same: how do we reuse the working code without turning the integration itself into a second project?

Four practical ways to connect Java to C

There are really four broad options.

1. Proxy-based bridging

This is the closest thing to "native" interoperability.

With a bridge such as JNBridgePro, you point the proxy generator at your .NET assemblies and generate Java proxy classes. Those proxies look like regular Java classes, but at runtime they forward calls into the CLR.

// Generated proxy for a .NET class
var renderer = new com.mycompany.dotnet.PdfRenderer();
byte[] pdf = renderer.render("template.html", data);
Files.write(Path.of("output.pdf"), pdf);

The Java developer experiences a normal object model. The bridge handles CLR startup, type marshalling, and exception translation.

Use this when you have:

close-grained calls
object-heavy APIs
shared business logic that should not be wrapped in HTTP
a real need to reuse .NET code in-process

2. REST or gRPC

If the boundary is naturally service-oriented, this is often the cleanest answer.

Wrap the .NET component in an ASP.NET Core API or a gRPC service, then call it from Java.

This works well when:

the .NET component is already a service
the call pattern is coarse-grained
latency is acceptable
the Java and .NET pieces will remain independently deployed

The tradeoff is obvious: you gain architectural clarity, but you also pay for serialization, network hops, and another runtime to operate.

3. COM interop

COM still exists in a lot of enterprises, especially in Windows-only environments.

If you are already on Windows and have legacy components that expose COM interfaces, this may be a viable bridge. It is not the first choice for greenfield systems, but it still has a place in old enterprise estates.

The downside is just as obvious: it is Windows-only, and it is not the best long-term modernization path.

4. Native hosting via coreclr

In some cases, teams try to host the CLR natively from the Java side or build custom loaders around the runtime.

That can work for specialized scenarios, but it quickly becomes a maintenance problem if you need robust exception handling, version compatibility, thread management, and production support.

If the use case is enterprise production software, a supported bridge is usually the safer choice.

Why bridging usually beats rewriting

Rewriting sounds neat on slides because it promises purity.

In practice, rewrites usually force teams to rebuild:

business rules that already work
integration behavior discovered only in production
test coverage accumulated over years
edge cases nobody fully documented
deployment and rollback behavior that production already depends on

If the .NET code still has value, a bridge-first strategy gives you time to modernize deliberately instead of freezing delivery for a rewrite.

How to decide which path fits

Use this simple decision rule:

choose REST or gRPC if you already want a service boundary
choose COM only when you are trapped in a Windows-only legacy environment
choose native hosting only for specialized cases with very clear operational ownership
choose bridging when the integration is close-grained and you need Java and .NET to cooperate directly

If your Java code needs to call a .NET DLL many times per user action, forcing the call through HTTP is often the wrong abstraction.

If your integration is one request in, one response out, the service boundary is probably fine.

How to run a C# library from Java in production

The production checklist is more important than the demo.

When you load .NET DLLs in Java, make sure you have a plan for:

runtime version compatibility
exception translation
thread ownership and apartment models
startup latency
classpath and assembly loading
logging across both runtimes

The best bridge in the world does not help if the surrounding operational model is brittle.

A final rule of thumb

If the existing .NET library is useful, stable, and hard to replace, the first question should not be "how do we rewrite it in Java?"

The first question should be "how do we let Java use it safely?"

That is the real problem this article solves.

C# JVM and JDK Integration: How .NET Teams Can Use Java Without Rewriting

JNBridge — Fri, 31 Jul 2026 13:21:44 +0000

If you’ve ever searched for “C# JVM” or “C# JDK integration,” you already know the real problem: your .NET team needs to use Java code, but the answer is not another rewrite project. The useful question is how to connect the two runtimes in a way that keeps production systems stable while the business keeps moving.

Originally published on the JNBridge blog, this guide maps the Java platform back to the .NET world and shows the practical integration options that actually hold up in production.

What People Usually Mean by “C# JVM”

Strictly speaking, C# does not run on the JVM in mainstream .NET deployments. What people usually mean is:

a .NET application needs to call Java classes or JARs
a Java system needs to serve a C# or .NET application
an existing Java dependency should be reused instead of rewritten

That’s why “C# JVM integration” is really about interoperability between two runtimes:

.NET / CLR on the Microsoft side
JVM / JDK on the Java side

If your team understands that distinction, the rest of the architecture choices get much easier.

JVM vs. CLR: The Mental Model

The JVM and CLR are both managed runtimes. They compile code, manage memory, and handle execution at runtime. The analogy is helpful:

Java	.NET
JVM	CLR
JDK	.NET SDK
JAR	Assembly
`javac`	`dotnet build` / Roslyn

The key difference is not just language. It’s operational ownership. If your Java code is already stable, rewriting it in C# can introduce new defects, new timelines, and new support burdens for very little payoff.

The Integration Options That Actually Exist

There are really five broad ways to connect .NET and Java:

1. REST APIs

Put Java behind an HTTP service and call it from .NET. This is the most familiar approach, and it’s great when the boundary is already service-oriented.

Best for: distributed systems, coarse-grained calls, clear ownership boundaries

Tradeoff: serialization overhead and higher latency

2. gRPC

gRPC gives you binary payloads and strong contracts. If you already want service boundaries, it can be a big step up from ad hoc JSON endpoints.

Best for: service-to-service communication

Tradeoff: still a network hop, still a separate service to run

3. Translation / Recompilation

Tools like IKVM take a different path: convert Java bytecode into .NET assemblies.

Best for: limited Java 8-era codebases with simple dependencies

Tradeoff: modern Java support is the hard part, and supportability tends to become the issue later

4. Native Library Boundaries

If you can turn the Java side into a native artifact or wrap it another way, you can call across a lower-level boundary.

Best for: specialized cases

Tradeoff: complexity goes up fast, especially when reflection and dynamic loading are involved

5. In-Process Bridging

This is the option most teams actually want once they stop chasing rewrite fantasies: keep Java running on a real JVM, keep .NET on the CLR, and connect them with a purpose-built bridge.

That lets .NET call Java with typed proxies instead of hand-rolled HTTP wrappers.

Why Bridging Beats Rewriting

Rewriting sounds cleaner than it is. In practice, rewrites usually force teams to rebuild:

business rules that already work
edge cases that only show up in production
integration contracts with surrounding systems
test coverage accumulated over years

The cost is not just engineering time. It’s also the risk of changing behavior you don’t fully understand yet.

If the Java code is already producing value, the better move is often to bridge first and modernize later.

When JNBridgePro Fits

JNBridgePro is built for teams that need direct Java/.NET interoperability without forcing a rewrite.

That matters when:

your Java dependencies are too valuable to replace
your .NET app needs to call Java APIs directly
you want a real JVM, not a translation layer
you need production support for modern Java and .NET runtimes

It’s a good fit for enterprise teams that care more about delivery risk than theoretical purity.

A Simple Decision Rule

Use this rule of thumb:

choose REST or gRPC if you already want a service boundary
choose translation only if your Java footprint is small and simple
choose bridging if you need Java and .NET to cooperate closely in production
choose a rewrite only when the old system is actually disposable

That last point matters. A lot of systems are old. Very few are disposable.

Final Thought

If you’re asking about C# JVM integration, you usually don’t need a language migration. You need a reliable way to keep Java and .NET working together while avoiding the cost and risk of a rewrite.

That’s the problem this article is really about.

Modernize Legacy .NET Without a Full Rewrite: A Practical Roadmap

JNBridge — Mon, 11 May 2026 13:25:49 +0000

Legacy .NET systems usually aren't "old code" so much as years of production rules, edge cases, integrations, and compliance work that the business still depends on. The safest modernization plan is often not a rewrite — it's a staged path that keeps the working system alive while you peel off risk one piece at a time.

This is a developer-to-architect walkthrough of how to choose between infrastructure upgrades, APIs, strangler-fig replacement, and direct application bridging when a full rewrite is too risky.

Originally published on the JNBridge blog.

The Legacy .NET Modernization Challenge

Enterprise .NET applications often contain 10-20 years of accumulated business logic, regulatory compliance features, and integration points that represent millions of dollars in development investment. These systems face mounting pressure from multiple directions:

Cloud Migration Requirements: Organizations need applications that can deploy to Azure, AWS, or hybrid environments without extensive infrastructure dependencies.

Integration Demands: Modern business requires seamless data exchange with SaaS applications, mobile systems, and third-party APIs.

Developer Experience Problems: Recruitment and retention suffer when technology teams work exclusively with outdated frameworks and deployment practices.

Security and Compliance Updates: Regulatory requirements and security standards evolve faster than monolithic application update cycles can accommodate.

The Hidden Value in Legacy .NET Systems

Before considering any modernization approach, recognize what your legacy .NET application does exceptionally well:

Battle-tested business logic refined through years of production use
Deep integration with Windows-based enterprise systems
Performance-optimized code for specific business processes
Compliance-certified workflows that meet regulatory requirements
Extensive configuration options that support diverse business scenarios

The goal of .NET modernization without rewrite is enhancing these strengths rather than replacing them.

Why Full Rewrites Fail for .NET Applications

Independent analysis of 1,471 IT projects found heavy tail risk in large transformations, including significant black-swan overruns (source).

The track record for complete .NET application rewrites is sobering. Research indicates that 68% of enterprise application rewrite projects exceed their original timeline by more than 12 months, with 31% ultimately failing to deliver functional replacements.

The .NET Framework Dependency Web

Legacy .NET applications rarely exist in isolation. They typically depend on:

Shared libraries developed over multiple years
COM components that interface with specialized hardware or legacy systems
Third-party controls that may not have modern equivalents
Database stored procedures containing complex business rules
Windows-specific services for background processing

Rewriting means recreating not just the application but its entire ecosystem of dependencies.

Business Logic Archeology Problem

Enterprise .NET applications contain embedded knowledge that exists nowhere else in the organization:

Undocumented business rules implemented in edge case handling
Integration logic for partner systems that lack current documentation
Performance optimizations developed through years of production tuning
Regulatory compliance features implemented by consultants who are no longer available

This “tribal knowledge” cannot be captured in requirements documents or reverse-engineered from user interfaces.

The Parallel Development Trap

Full rewrites require maintaining two versions of your application simultaneously:

Legacy system maintenance – bug fixes, regulatory updates, new business requirements
Replacement system development – building modern equivalent functionality

Most organizations underestimate the cost and complexity of this parallel development period, which typically extends 18-36 months longer than projected.

The Complete Spectrum of .NET Modernization Approaches

Use a portfolio strategy, not a one-size-fits-all plan: Microsoft’s Cloud Adoption Framework maps retire/rehost/replatform/refactor/rearchitect/rebuild/replace decisions (reference).

Successful .NET modernization without rewrite requires choosing the right strategy for your specific situation. Here are five proven approaches, ranked from lowest to highest business disruption:

1. Infrastructure Modernization Only

Scope: Upgrade hosting environment while preserving application code Timeline: 2-6 months Risk Level: Low Business Impact: Minimal

This approach moves existing .NET Framework applications to modern hosting environments (containers, cloud platforms) without changing application code. It delivers immediate operational benefits while preserving all existing functionality.

2. Selective Component Updates

Scope: Modernize specific application components while maintaining core system Timeline: 3-9 months Risk Level: Low-Medium Business Impact: Limited

Replace or upgrade individual components (user interfaces, reporting modules, integration layers) while preserving core business logic. This enables targeted improvements without system-wide changes.

3. API-First Modernization

Scope: Expose legacy functionality through modern APIs Timeline: 6-12 months Risk Level: Medium Business Impact: Moderate

Wrap existing .NET applications with RESTful APIs or GraphQL interfaces, enabling modern applications to consume legacy business logic without direct system integration.

4. Hybrid Architecture Implementation

Scope: Integrate legacy and modern applications through bridging technology Timeline: 3-8 months Risk Level: Medium Business Impact: Low-Medium

Enable direct communication between legacy .NET applications and modern systems without requiring changes to existing code. This approach leverages interoperability solutions to bridge technology gaps.

5. Incremental Component Replacement

Scope: Gradually replace legacy components with modern equivalents Timeline: 12-24 months Risk Level: High Business Impact: High

Systematically replace application components over time using patterns like the strangler fig approach. This provides the benefits of modern architecture while managing implementation risk.

What Makes Incremental .NET Modernization Work?

The most successful .NET modernization projects share common characteristics that distinguish them from failed rewrite attempts:

Preservation of Business Logic Integrity

Incremental approaches maintain existing business rules and workflows while modernizing the technology foundation. This eliminates the risk of losing embedded business knowledge or introducing functional regressions.

Continuous Value Delivery

Rather than waiting 18-24 months for big-bang deployment, incremental modernization delivers benefits in 3-6 month cycles:

Improved deployment capabilities
Enhanced integration options
Modern development tool support
Cloud hosting flexibility
Performance optimizations

Risk Mitigation Through Reversibility

Every modernization step remains reversible until proven successful in production. If new components fail or perform poorly, organizations can quickly revert to previous configurations without business impact.

Team Learning and Skill Development

Incremental projects allow development teams to gradually acquire modern .NET skills while maintaining productivity with existing systems. This eliminates the knowledge gap that often derails rewrite projects.

The Strangler Fig Pattern for .NET Applications

Major platform guidance supports phased modernization to reduce disruption and migration risk (Microsoft Strangler Fig, AWS Strangler Fig).

The strangler fig pattern offers a particularly effective approach for legacy .NET modernization. Named after the vine that gradually encompasses and replaces host trees, this pattern incrementally replaces legacy components while maintaining system functionality.

How Strangler Fig Works with .NET Applications

The pattern operates through three phases:

Phase 1: Interception Layer Create a routing layer that can direct requests to either legacy or modern components. For .NET applications, this often involves:

API gateways for web requests
Service abstractions for business logic
Database abstraction layers for data access

Phase 2: Incremental Replacement Systematically replace individual components while routing production traffic through the interception layer. The strangler fig pattern implementation guide provides detailed technical approaches.

Phase 3: Legacy System Retirement Once all components are replaced and validated, decommission the original legacy system.

Strangler Fig Benefits for .NET Modernization

Reduced Business Risk: New components undergo production validation before taking full responsibility for business processes.

Continuous Operation: Legacy systems continue serving users while modernization proceeds in parallel.

Flexible Timeline: Organizations can adjust modernization pace based on business priorities and resource availability.

Investment Protection: Existing .NET investments continue generating value throughout the modernization process.

Comparing Modernization Timelines and Risk Levels

Understanding the time and risk implications of different approaches helps organizations make informed modernization decisions:

Approach	Timeline	Risk level	Business disruption	Technical debt reduction

Timeline Reality Check

Actual modernization timelines consistently exceed estimates when organizations fail to account for:

Integration complexity with existing enterprise systems
Data migration challenges between different architectural patterns
User acceptance testing requirements for business-critical workflows
Change management across multiple business units
Performance optimization to match legacy system response times

Risk Mitigation Strategies

Organizations that successfully modernize legacy .NET applications implement these risk reduction practices:

Parallel Operation Periods: Run legacy and modern components simultaneously until new systems prove reliable in production environments.

Comprehensive Testing Frameworks: Develop automated testing that validates business logic consistency across old and new implementations.

Rollback Procedures: Maintain documented procedures for quickly reverting to previous configurations if modernization components fail.

Performance Benchmarking: Establish baseline performance metrics and monitor closely during modernization to prevent user experience degradation.

Application Bridging: The Proven Alternative to Rewrites

Application bridging emerges as the most pragmatic modernization strategy for organizations seeking immediate benefits without rewrite risks. This approach enables legacy .NET applications to integrate seamlessly with modern systems while preserving existing business logic.

How Application Bridging Works

Modern bridging technology creates direct communication channels between .NET applications and other technology stacks. For example, legacy .NET Framework applications can directly invoke methods in modern Java services, .NET Core applications, or cloud-based APIs without requiring architectural changes.

Key capabilities include:

Native method invocation across different runtime environments
Shared object models that work across technology boundaries
Exception handling that propagates correctly between systems
Performance optimization that minimizes integration overhead

Bridging vs. Traditional Integration Approaches

Unlike REST APIs, message queues, or file-based integration, bridging provides native-level connectivity between applications:

Performance Advantages: Direct method calls eliminate HTTP overhead and serialization costs, often improving performance by 40-70% compared to REST-based integration.

Development Simplicity: Developers work with familiar object models and method signatures rather than learning new integration protocols.

Maintenance Reduction: Single bridging configuration replaces multiple integration points, reducing operational complexity.

Type Safety: Compile-time validation catches integration errors before deployment, unlike runtime-only validation in API-based approaches.

Real-World Bridging Implementation

A Fortune 500 manufacturing company recently modernized their core .NET inventory management system using application bridging rather than a planned $2.8 million rewrite:

Challenge: Legacy .NET Framework application needed to integrate with new Java-based supply chain management system and cloud analytics platform.

Bridging Solution: Implemented JNBridge interoperability platform to enable direct communication between .NET, Java, and cloud components.

Results:

Timeline: 4 months vs. 28-month rewrite estimate
Cost: $180,000 vs. $2.8 million rewrite budget
Business Impact: Zero operational disruption
Performance: 15% faster than previous REST-based integration

Strategic Benefits of Bridging for .NET Modernization

Immediate Integration Value: Legacy .NET applications can immediately consume modern services and expose functionality to new systems without code changes.

Future Architecture Flexibility: Bridging preserves all future modernization options while delivering immediate benefits. Organizations can still pursue rewrites, component replacement, or other strategies while bridged systems operate.

Investment Protection: Existing .NET development investments continue generating value while new capabilities are added through modern applications.

Team Productivity: .NET developers continue working with familiar tools and frameworks while gaining access to modern ecosystem capabilities.

Building Your .NET Modernization Roadmap

Successful .NET modernization requires a systematic approach that balances immediate business needs with long-term architectural goals. Here’s a proven framework for building your modernization strategy:

Phase 1: Assessment and Planning (Month 1-2)

Legacy System Analysis:

Document current application architecture and dependencies
Identify integration points with other enterprise systems
Catalog business-critical functionality and performance requirements
Assess technical debt and maintenance burden

Modernization Goal Definition:

Cloud deployment requirements
Integration needs with modern applications
Developer experience improvements
Performance and scalability targets

Approach Selection: Use the decision matrix to select the optimal modernization approach based on your specific constraints and objectives.

Phase 2: Proof of Concept (Month 2-3)

Technical Validation:

Test chosen modernization approach with non-critical application components
Validate integration patterns and performance characteristics
Develop deployment and rollback procedures
Train development team on new tools and approaches

Business Case Refinement:

Quantify benefits and costs based on proof-of-concept results
Adjust timeline estimates based on actual implementation experience
Secure stakeholder buy-in for full implementation

Phase 3: Incremental Implementation (Month 3-12)

Component-by-Component Modernization:

Start with least critical components to minimize business risk
Implement comprehensive testing for each modernized component
Monitor performance and user feedback throughout implementation
Adjust approach based on lessons learned from each component

Integration Expansion:

Gradually expand integration capabilities as confidence builds
Add new business functionality that leverages modernized architecture
Document patterns and practices for future modernization cycles

Phase 4: Architecture Evolution (Month 6-18)

Advanced Capabilities:

Implement cloud-native features like auto-scaling and distributed deployment
Add modern monitoring, logging, and observability capabilities
Enhance security with modern authentication and authorization patterns
Optimize performance using cloud platform capabilities

Long-term Strategy:

Evaluate options for further modernization or component replacement
Plan for future technology evolution and business requirements
Establish ongoing modernization practices for continuous improvement

Getting Started with .NET Modernization

Ready to modernize your legacy .NET application? The most successful projects begin with a clear understanding of current capabilities and specific modernization objectives.

Application bridging with JNBridge offers the fastest path to .NET modernization benefits without rewrite risks. Their enterprise-proven platform enables immediate integration between legacy .NET applications and modern systems.

Start your modernization journey: Download JNBridge Pro and test bridging capabilities with your existing .NET applications. Most organizations complete their evaluation within 1-2 weeks and begin seeing modernization benefits within 30 days.

The choice between rewriting and modernizing determines whether your .NET application continues delivering business value or becomes a costly distraction from strategic initiatives. Smart organizations choose modernization approaches that enhance existing investments rather than abandoning them.

Your legacy .NET application represents years of refined business logic and proven reliability. Modernization without rewrite preserves these assets while enabling the contemporary capabilities your organization needs for future growth.

Learn more about calling Java from C# and calling C# from Java to understand how bridging technology enables seamless integration between different technology stacks.

Modernizing a Legacy .NET Application: Practical Checklist

Define latency targets, map object boundaries, establish error handling, and automate integration tests before rollout. Teams that document these four items early reduce production surprises and improve delivery speed.

Modernizing a Legacy .NET Application: Practical Checklist

Bottom line

A full rewrite can be the right answer when the domain is small, well understood, and isolated. Enterprise .NET systems rarely fit that profile. If the application contains valuable business logic, opaque dependencies, or regulatory workflows, modernization works better as a sequence of reversible steps: stabilize the platform, expose seams, bridge where direct reuse matters, and replace components only when the replacement has proven itself in production.

Canonical source: How to Modernize a Legacy .NET Application Without a Full Rewrite.

Run Java from C#: 5 Methods with Code Examples

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

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

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

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

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

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

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

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

Quick Comparison

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

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

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

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

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

When to Use It

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

Code Example

using System.Diagnostics;
using System.Text;

public class JavaProcessRunner

{

    public static async Task<string> RunJavaJarAsync(

        string jarPath,

        string arguments,

        string? javaHome = null)

    {

        var javaExe = javaHome != null

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

            : "java";

var startInfo = new ProcessStartInfo

        {

            FileName = javaExe,

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

            RedirectStandardOutput = true,

            RedirectStandardError = true,

            UseShellExecute = false,

            CreateNoWindow = true

        };

// Pass classpath and other JVM options via environment

        startInfo.Environment["CLASSPATH"] =

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

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

        var output = new StringBuilder();

        var errors = new StringBuilder();

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

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

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

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

process.Start();

        process.BeginOutputReadLine();

        process.BeginErrorReadLine();

using var cts = new CancellationTokenSource(

            TimeSpan.FromSeconds(30));

        try

        {

            await process.WaitForExitAsync(cts.Token);

        }

        catch (OperationCanceledException)

        {

            process.Kill(entireProcessTree: true);

            throw new TimeoutException(

                "Java process timed out after 30s");

        }

if (process.ExitCode != 0)

            throw new Exception(

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

return output.ToString();

    }

}

// Usage

var result = await JavaProcessRunner.RunJavaJarAsync(

    "/app/libs/converter.jar",

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

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

Edge Cases to Handle

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

The Problem

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

Method 2: IKVM — Compile Java Bytecode to .NET

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

When to Use It

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

Code Example

First, convert the JAR:

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

dotnet add package IKVM

# Or use the command-line converter

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

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

using com.example.mylib;

public class IkvmExample

{

    public static void RunJavaCodeInCSharp()

    {

        // Java classes are now .NET classes

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

        // Call Java methods directly — compiled to IL bytecode

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

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

// Java collections work but need casting

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

        list.add("item1");

        list.add("item2");

var iterator = list.iterator();

        while (iterator.hasNext())

            Console.WriteLine(iterator.next());

    }

}

Limitations

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

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

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

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

Method 3: JNI via C++/CLI Wrapper

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

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

When to Use It

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

Code Example

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

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

using namespace System;

using namespace System::Runtime::InteropServices;


public ref class JavaBridge

{

private:

    JavaVM* jvm;

    JNIEnv* env;


public:

    JavaBridge(String^ classPath)

    {

        JavaVMInitArgs vmArgs;

        JavaVMOption options[1];


IntPtr cpPtr = Marshal::StringToHGlobalAnsi(

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

        options[0].optionString =

            static_cast(cpPtr.ToPointer());


vmArgs.version = JNI_VERSION_1_8;

        vmArgs.nOptions = 1;

        vmArgs.options = options;

        vmArgs.ignoreUnrecognized = JNI_FALSE;


jint rc = JNI_CreateJavaVM(

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

        Marshal::FreeHGlobal(cpPtr);


if (rc != JNI_OK)

            throw gcnew Exception(String::Format(

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

    }


String^ CallStaticMethod(

        String^ className,

        String^ methodName,

        String^ arg)

    {

        // Convert .NET strings to native for JNI

        IntPtr clsName = Marshal::StringToHGlobalAnsi(className);

        jclass cls = env->FindClass(

            static_cast(clsName.ToPointer()));


if (cls == nullptr)

            throw gcnew Exception(

                "Java class not found: " + className);


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

        // (Full implementation requires ~50 lines of

        //  careful memory management)

    }


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

};

C# Usage:

using var bridge = new JavaBridge(

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

string result = bridge.CallStaticMethod(

    "com/example/TextProcessor",

    "processText",

    "Hello from C#!");

Console.WriteLine(result);

Why Most Teams Don't Do This

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

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

Method 4: gRPC Sidecar — Run Java as a Microservice

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

When to Use It

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

Code Example

1. Define the service (calculator.proto):

syntax = "proto3";

package calculator;


service Calculator {

    rpc Calculate (CalcRequest) returns (CalcResponse);

    rpc BatchCalculate (stream CalcRequest)

        returns (stream CalcResponse);

}


message CalcRequest {

    string expression = 1;

    int32 precision = 2;

}


message CalcResponse {

    double result = 1;

    string formatted = 2;

}

2. C# client:

using Grpc.Net.Client;

using Calculator;

public class JavaGrpcClient : IDisposable

{

    private readonly GrpcChannel _channel;

    private readonly Calculator.CalculatorClient _client;

public JavaGrpcClient(

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

    {

        _channel = GrpcChannel.ForAddress(address);

        _client = new Calculator.CalculatorClient(_channel);

    }

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

        CalculateAsync(string expression, int precision = 2)

    {

        var response = await _client.CalculateAsync(

            new CalcRequest

            {

                Expression = expression,

                Precision = precision

            });

        return (response.Result, response.Formatted);

    }

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

}

// Usage

using var client = new JavaGrpcClient();

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

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

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

Trade-offs

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

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

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

When to Use It

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

Code Example

using com.jnbridge.jnbcore;

using com.example.mylib;  // Generated proxies

public class JNBridgeExample

{

    public static void RunJavaInsideDotNet()

    {

        // Initialize — starts a JVM in-process

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

            new JNBClassPathInfo

        {

            ClassPath = new[]

            {

                "/app/libs/mylib.jar",

                "/app/libs/dependency.jar"

            },

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

        });

try

        {

            // Use Java objects like C# objects

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

// .NET types are marshaled automatically

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

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

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

            processor.configure(config);

// Process data

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

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

var results = processor.processAll(input);

            Console.WriteLine(

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

        }

        finally

        {

            DotNetSide.shutdown();

        }

    }

}

What Makes It Different

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

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

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

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

Performance Benchmarks

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

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

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

Which Method Should You Use?

Follow this decision tree:

How many times do you call Java per request?

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

→ A few times (< 100/sec):

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

→ Hundreds or thousands of times:

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

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

→ JNBridgePro or JNI (painful)

Cross-platform requirement?

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

How Do You Handle Java Dependencies from C#?

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

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

Key pitfalls to avoid:

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

// Correct cross-platform classpath construction

var separator = RuntimeInformation.IsOSPlatform(

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

var cp = string.Join(separator,

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

Can You Run Java from C# Without a JDK?

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

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

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

Frequently Asked Questions

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

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

Can I run Java code in C# on Linux?

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

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

Each method handles Java exceptions differently:

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

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

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

Wrapping Up

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

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

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

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

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

Explore code samples and tutorials in the JNBridgePro Developer Center →

Originally published on the JNBridge blog.

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

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

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

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

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

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

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

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

The JDK Explained for .NET Developers

CLR vs. JVM: Full Platform Comparison

What Is the Difference Between J2EE and ASP.NET?

Can C# Run on the JVM?

Can Java Run on the CLR? IKVM and GraalVM

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

When You Need In-Process C# JVM Bridging

Getting Started with JNBridgePro

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

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

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

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

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

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

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

Why This Matters to You

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

The JDK Explained for .NET Developers

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

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

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

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

C# JDK Compatibility: What Version Do You Need?

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

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

CLR vs. JVM: Full Platform Comparison

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

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

A few things stand out:

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

What Is the Difference Between J2EE and ASP.NET?

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

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

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

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

Can C# Run on the JVM?

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

There have been historical attempts:

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

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

Can Java Run on the CLR? IKVM and GraalVM

IKVM.NET

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

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

GraalVM

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

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

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

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

1. REST APIs / Web Services

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

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

2. Message Queues (Kafka, RabbitMQ)

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

3. gRPC / Process-Level Interop

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

4. In-Process Bridging with JNBridgePro

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

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

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

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

When You Need In-Process C# JVM Bridging

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

Java Libraries Without REST Wrappers

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

Enterprise Java Systems (.NET J2EE Integration)

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

Incremental Migration

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

Performance-Sensitive Integration

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

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

Getting Started with JNBridgePro

JNBridgePro supports two communication modes:

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

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

The setup workflow:

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

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

Reference the proxy assembly from your .NET project

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

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

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

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

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

What is the equivalent of the JVM in C#?

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

Can you compile C# to run on the JVM?

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

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

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

How does JNBridgePro handle C# JDK compatibility?

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

Does the .NET SDK include JVM or JDK support?

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

The practical takeaway

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

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

DEV Community: JNBridge

Java and .NET Without REST: Direct Interop Guide

Start with the boundary, not the transport

Where REST wrappers become awkward

Wrapper explosion

Lost type semantics

Chattiness and latency

Operational surface area

The main alternatives

Direct interoperability with generated proxies

A bridge still needs a well-designed boundary

Shared memory or separate processes?

When REST or gRPC is still the right answer

A decision framework

Production checklist

Final takeaway

Use NI-DAQmx from Java Without Owning a JNI Layer

Why the obvious JNI route becomes expensive

Bridge to the maintained API instead

What the Java code looks like

Keep the boundary coarse enough

Choose the runtime topology deliberately

Test without physical hardware

When a service boundary is still better

Final takeaway

5 Production-Safe Ways to Connect C# and Java

The short version

1. Generated proxies and runtime bridging

2. REST API

3. Message queues and event streams

4. gRPC

5. Custom sockets or named pipes

Comparison matrix

A decision tree you can use in an architecture review

Production checks that demos usually omit

Final rule of thumb

Related reading on Dev.to

Calling a Java Logging Package from .NET

What we are building

Prerequisites

1. Build the Java classpath in JNBProxy

2. Export a runnable .NET project

3. Prove the generated bridge first

4. Call log4j from C

Shared memory versus TCP

The reusable pattern

C# and Java Interprocess Communication: Sockets, APIs, and Bridges Compared

The first question: what kind of boundary do you actually have?

Sockets: useful when you need full protocol control

REST APIs: best for coarse-grained service boundaries

gRPC: strong contracts with better performance than REST

Messaging: best when the two runtimes should not wait on each other

Bridges: best when you need direct Java and .NET API reuse

A quick comparison

How to choose without overthinking it

A production checklist that matters more than the diagram

Final thought

C# Lucene Options: Run Java Lucene from .NET or Use Lucene.NET?

The three realistic Lucene options

Why Lucene.NET is sometimes enough

Why a REST wrapper is often a compromise

Why direct Java access is often the best production answer

A practical decision checklist

My short recommendation

C# J2EE Support: Connecting .NET Applications to Legacy Java Enterprise Systems

What C# J2EE support means

Why .NET teams still need J2EE integration

Common ways to connect C# and J2EE

When APIs are enough

When bridging is better than wrapping everything

A practical architecture checklist

Example: a modern .NET app with an existing J2EE rules engine

Final thought

How to Connect Java to C# and Run .NET Libraries from Java

The reverse interop problem

Four practical ways to connect Java to C

1. Proxy-based bridging

2. REST or gRPC

3. COM interop

4. Native hosting via coreclr