Archive for category: JNBridgePro

What We’re Building

In this post we’ll break down the anatomy of a simple interop project where a .NET application calls into a Java class using JNBridgePro with shared memory. If you need to call Java from a .NET project, understanding these moving parts is essential.

The goal is to make the moving parts visible:

• how a proxy connects the .NET and Java worlds,
• what files live on each side,
• other considerations for shared memory setups.

Switching this project to TCP (plus added considerations like SSL, IP/class whitelisting, and Java-side startup) will be covered in a separate post: Changing to TCP: Configuration, SSL, Whitelisting & Startup.

Project Layout for Java .NET Interop

Here’s the directory structure of a demo project (BridgeDemo). At a glance, you can see two main areas:

• .NET project (BridgeDemo) – the C# application, configuration file, and runtime DLLs.
• Java side (Java Side) – the original Java class and supporting JARs and properties.

.NET Side: Calling Java with JNBridgePro Shared Memory

On the .NET side, the project is built around referenced assemblies, supporting DLLs, and the App.config that defines how it connects to the Java side.

Referenced Assemblies

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

Both are added under References in Visual Studio and have Copy Local = True, ensuring they’re automatically placed in the output folder when you build. This way, BridgeDemo.exe can find them at runtime without extra configuration.

Supporting DLLs

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

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

App.config

At runtime, BridgeDemo.exe uses this configuration to tell JNBridge how to locate and load the Java side. Below is a sample configuration for the Shared Memory transport:

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

• scheme – transport type (sharedmem or tcp).
• jvm64 – points to the 64-bit JVM to load (jvm32 used if needed).
• jnbcore – path to jnbcore.jar, which contains the bridge runtime.
• bcel – only required when using Shared Memory; omitted for TCP.
• classpath – tells JNBridge where to find your Java classes or JARs (the Java Side folder in this project).

The classpath section determines whether the .NET side connects to a Java package directory containing .class files, a JAR, or both if listed together. Learn more about how JNBridgePro connects .NET and Java.

Java Side

The Java side hosts the actual code and bridge runtime that the .NET process connects to. It generally includes core/supporting JARs, the Java code or JAR, and a properties file defining how the JVM bridge runs.

Core and Supporting JARs

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

Java Code or Packaged JAR

You may have either of the following, depending on how your build is structured:

• A package directory (for example, BridgeDemo/) with .class files.
• Or a JAR archive (such as BridgeDemo.jar) containing the compiled classes.

Which of these is used depends on the classpath specified in the .NET project’s App.config.

Java-Side Properties File

This file (for example, javaSide.properties) controls how the JVM runs the bridge. Typical entries include:

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

Considerations for Shared Memory Setups

Shared Memory provides the fastest .NET↔Java communication since both run in the same process, but it requires correct architecture alignment and file placement.

The JVM architecture must match your .NET build target:

• 64-bit .NET → use 64-bit jvm.dll.
• 32-bit .NET → use 32-bit jvm.dll. (Note: running x86 shared memory in JNBridgePro v12 may hit a hidden runtime dependency.)

Supporting DLLs must also match:

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

You can omit the unused architecture’s DLLs (for example, keep only the x64 set for a 64-bit-only build). If the app may run in both modes (for example, AnyCPU), include all four — JNBridge will automatically load the correct pair at runtime.

All bridge DLLs (JNBShare.dll, JNBSharedMem_x*.dll, jnbauth_x*.dll) must reside in the same directory as your executable.

Handling ClassNotFoundException and NoClassDefFoundError

These errors during shared-memory startup usually come from missing permissions or classloader issues in older JVMs.

• Permissions – Ensure the user running the app has Read & Execute, List Folder Contents, and Read access to all Java class and JAR folders (jnbcore.jar, bcel-6.x.x.jar, and any app JARs). Missing access prevents the JVM from loading classes, especially under ASP.NET.
• Classloader conflicts (Java 8 and earlier) – If permissions are correct but errors persist, move the affected .jar from the classpath to the boot classpath using -Xbootclasspath/p: and remove it from the regular classpath.

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

In this example, javaToCall.jar was removed from the classpath and added to the boot classpath, allowing the JVM to load it earlier and resolve the conflict. (The -Xbootclasspath/p: option works only through Java 8 and was removed in Java 9+.)

Ready to build your own Java .NET interop project? Download JNBridgePro and visit the developer center for more resources.

Related Articles

Related JNBridgePro guides:

• TCP Configuration: SSL & Whitelisting
• JNBridgePro v12 Crash Fix (x86 Shared Memory)
• How to Call Java from C#
• How to Call C# from Java
• JNBridgePro + Claude Code Demo

This post continues from our earlier walkthrough, Anatomy of a .NET Calling Java Project (Shared Memory), and uses the same BridgeDemo project to demonstrate how to change from Shared Memory to JNBridge TCP configuration.

While Shared Memory offers high performance for co-located components, TCP mode is used when the .NET and Java sides run on different machines. When using TCP, you can optionally enable additional features such as SSL encryption, IP whitelisting, and class whitelisting — features that aren’t applicable to Shared Memory connections.

Overview of JNBridgePro TCP Mode

When the bridge runs in TCP mode, the .NET side and the Java side communicate through a socket connection rather than shared memory. This offers several advantages:

• Cross-platform independence – the .NET and Java components can run on different hosts or operating systems.
• Remote accessibility – the bridge can connect across LAN or WAN networks.
• Security options – TCP supports SSL, IP whitelisting, and class-level restrictions (class whitelisting).

Unlike Shared Memory, the Java side must be started first in TCP mode so that the .NET side can connect to it. Learn more about how JNBridgePro works.

Updating the .NET Configuration (App.config) for TCP

In BridgeDemo, open App.config and locate the <dotNetToJavaConfig> section. Change the scheme from sharedmem to jtcp, and specify the host, port, and optional SSL parameters.

• scheme – must be set to jtcp
• host – the machine where the Java side is running
• port – must match the port defined in java.properties

Example:

<jnbridge>
  <dotNetToJavaConfig
    scheme="jtcp"
    host="localhost"
    port="8085"
    useSSL="true"
    clientCertificateLocation=".\testclient.p12"
    clientCertificatePassword="pw"
    sslAlternateServerNames="myServer" />
</jnbridge>

If you are not using SSL, simply omit those attributes or set useSSL to false.

Updating the Java-Side Configuration (java.properties)

On the Java side, update java.properties to switch the bridge to TCP, define the connection port, and enable optional security features like IP and class whitelisting or SSL.

Example — javaSide.properties:

javaSide.serverType=tcp
javaSide.workers=5
javaSide.timeout=10000
javaSide.port=8085
javaSide.useClassWhiteList=true
javaSide.classWhiteListFile=./classWhiteList.txt
dotNetSide.ipWhitelist=127.0.0.1
javaSide.keyStore=./keystore.jks
javaSide.keyStorePassword=changeit
javaSide.trustStore=./cacerts.jks
javaSide.trustStorePassword=changeit

Adding Whitelisting for Java .NET TCP Communication

When using TCP, you can restrict which classes are exposed to .NET and which clients are allowed to connect. These options improve security and control without affecting performance.

Class Whitelisting

Create a file named classWhiteList.txt in the same directory as java.properties. Each line specifies a fully qualified Java class name that can be accessed from the .NET side.

Example — classWhiteList.txt:

bridgeDemo.JavaToCall

Then, enable class whitelisting in java.properties:

javaSide.useClassWhiteList=true
javaSide.classWhiteListFile=./classWhiteList.txt

Only the classes listed here can be loaded by the bridge; all others are blocked automatically.

IP Whitelisting

IP whitelisting limits which machines can connect to the Java bridge. Add the following property to java.properties:

dotNetSide.ipWhitelist=127.0.0.1

Enabling SSL for Secure Java .NET Communication

SSL enables encryption, server authentication, and client authentication, protecting both sides of the bridge and preventing unauthorized access or code execution.

To implement SSL, you must complete all of the steps outlined in the “Secure communications using SSL” section of the JNBridgePro User Guide (p. 78):

1. Generate and install certificates – Each Java side requires an X.509 server certificate whose Common Name (CN) matches the host where the Java side runs. Each .NET side requires its own client certificate, consisting of a public certificate and a corresponding private-key file.
2. Create and install the keystore and truststore on the Java side – Install the Java side’s server certificate in a keystore file. Install each authorized .NET side’s client certificate in a truststore file. Both files must have passwords and be referenced in the JavaSide.properties file.
3. Install certificates on the .NET side – Import the client certificate into the Windows Certificate Store. Leave the public certificate file accessible on disk so it can be referenced in the bridge configuration.
4. Configure the .NET side for SSL – specify properties in app.config for SSL.

After these steps are completed, all communication between .NET and Java occurs over an encrypted, mutually authenticated SSL channel. The IP and class whitelists, worker-thread pool, and timeout settings continue to apply normally within this secure channel. For more on Java SSL/TLS configuration, see the Oracle JSSE Reference Guide.

Starting the Java Side

The Java side must be started manually before any .NET connections are made. This launches the JNBridge Java component, loads all required classes, and applies the configuration defined in the properties file. Use the following command:

java -cp ".;javaToCall.jar;jnbcore.jar" com.jnbridge.jnbcore.JNBMain /props "javaSide.properties"

This command must be run from the directory that contains the listed JAR files and the javaSide.properties file. When you execute it, Java uses the classpath (-cp) to locate javaToCall.jar (your Java classes) and jnbcore.jar (the JNBridge runtime).

Ready to try TCP mode? Download JNBridgePro and explore the knowledge base for more guides. Need help? Contact us.

Related Articles

Related JNBridgePro guides:

• Shared Memory Bridge Anatomy
• JNBridgePro v12 Crash Fix
• How to Call Java from C#
• How to Call C# from Java

If you need to call C# from Java, you’re facing one of the most common cross-platform integration challenges in enterprise software development. Whether you need to access a .NET library from a Java application, integrate with a legacy C# system, or bridge teams working across both platforms, this guide covers every viable approach to calling .NET from Java — with working code examples, performance analysis, and clear recommendations.

This is the companion guide to our post on how to call Java from C#. While the concepts are related, calling C# from Java presents unique challenges because Java applications must initiate communication with the .NET Common Language Runtime (CLR), which requires different tooling and techniques.

Can You Call C# Code from Java?

Yes, you can call C# code from Java using several proven methods. The most common approaches include exposing C# functionality through REST APIs, using gRPC for high-performance remote procedure calls, leveraging the Java Native Interface (JNI) with native C++ wrappers, running .NET executables as subprocesses, and using dedicated bridging tools like JNBridgePro that enable direct in-process communication between the Java Virtual Machine (JVM) and the .NET CLR.

The best approach depends on how tightly your Java and C# code needs to be coupled, your performance requirements, and whether you need the .NET code running in the same process as your Java application or as a separate service. Let’s explore each method in depth.

Why Call C# from Java?

Enterprise development teams face this integration challenge in several common scenarios:

• Accessing .NET-only libraries: Your Java application needs functionality that only exists in a C# or .NET library — a proprietary SDK, a Windows-specific API, or a specialized calculation engine built in .NET.
• Legacy system integration: Your organization has critical business logic in a C#/.NET codebase that must be consumed by newer Java applications without a full rewrite.
• Cross-team collaboration: One team develops in Java while another builds in C#, and their systems must share data and functionality in real time.
• Platform migration: You’re migrating from .NET to Java (or vice versa) and need both systems running simultaneously during the transition period.
• Best-of-breed architecture: You want to use the strongest libraries from each ecosystem — perhaps a Java-based data pipeline with a .NET-based machine learning model or financial calculation engine.

Understanding your specific use case helps determine which Java-.NET interoperability approach will serve you best.

Overview of All Approaches

When you need to invoke C# from Java, you’re fundamentally connecting two different runtime environments — the JVM (Java Virtual Machine) and the CLR (Common Language Runtime). Each approach handles this connection differently:

• Network-based approaches (REST, gRPC) keep Java and .NET in separate processes communicating over HTTP or TCP
• Native interop (JNI + native code) bridges through a compiled C/C++ layer that can load the CLR
• Subprocess execution runs the .NET application as a separate OS process
• In-process bridging (JNBridgePro) runs both the JVM and CLR in the same process with automatic proxy generation and type marshaling

Each method involves different trade-offs in latency, development complexity, runtime overhead, and long-term maintenance. The sections below provide code examples and analysis for each approach.

Approach 1: REST APIs and HTTP Services

The most widely discussed method for calling .NET from Java involves wrapping your C# code in HTTP endpoints using ASP.NET Core. Your Java application then sends HTTP requests to the .NET web service and receives JSON responses.

How It Works

1. Create an ASP.NET Core Web API project exposing your C# functionality as REST endpoints
2. Deploy the .NET service (IIS, Kestrel, Docker container, etc.)
3. Use HttpClient or a similar HTTP library in Java to call the endpoints

C# Service (ASP.NET Core):

[ApiController]
[Route("api/[controller]")]
public class CalculationController : ControllerBase
{
    [HttpPost("risk-score")]
    public ActionResult<RiskResult> CalculateRisk([FromBody] RiskInput input)
    {
        var engine = new RiskEngine();
        var result = engine.Calculate(input.Portfolio, input.Parameters);
        return Ok(result);
    }
}

Java Client:

HttpClient client = HttpClient.newHttpClient();
String json = "{\"portfolio\": \"ACME-401K\", \"parameters\": {\"horizon\": 30}}";
HttpRequest request = HttpRequest.newBuilder()
    .uri(URI.create("http://localhost:5000/api/calculation/risk-score"))
    .header("Content-Type", "application/json")
    .POST(HttpRequest.BodyPublishers.ofString(json))
    .build();
HttpResponse<String> response = client.send(request, HttpResponse.BodyHandlers.ofString());
RiskResult result = objectMapper.readValue(response.body(), RiskResult.class);

Pros

• Language-agnostic — standard HTTP communication that works between any two technology stacks
• Well-understood architecture with extensive tooling and documentation
• Independent scaling and deployment of Java and .NET components
• Easy to add authentication, rate limiting, and monitoring

Cons

• Network latency on every call — typically 5–50ms per request, even on localhost
• JSON serialization and deserialization overhead on both sides
• Requires deploying and maintaining a separate .NET web service
• Complex error handling across HTTP boundaries (timeouts, retries, circuit breakers)
• Not suitable for fine-grained, method-level integration requiring hundreds of calls per operation

REST works best when Java and .NET are genuinely separate services with infrequent, coarse-grained communication. If your Java code needs to call dozens of C# methods per user request, the accumulated network overhead becomes a serious bottleneck.

Approach 2: gRPC with Protocol Buffers

gRPC provides better performance than REST by using binary serialization (Protocol Buffers) and HTTP/2 for transport. It’s a strong choice when you need structured, strongly-typed communication between Java and .NET with better performance than REST.

How It Works

1. Define your service contract in a .proto file
2. Generate C# server code and Java client stubs from the contract
3. Implement the service in C#, call it from Java

Proto Definition:

syntax = "proto3";
service RiskService {
  rpc CalculateRisk (RiskInput) returns (RiskResult);
}
message RiskInput {
  string portfolio_id = 1;
  int32 horizon_days = 2;
}
message RiskResult {
  double score = 1;
  string rating = 2;
}

Java gRPC Client:

ManagedChannel channel = ManagedChannelBuilder.forAddress("localhost", 5000)
    .usePlaintext()
    .build();
RiskServiceGrpc.RiskServiceBlockingStub stub = RiskServiceGrpc.newBlockingStub(channel);
RiskResult result = stub.calculateRisk(
    RiskInput.newBuilder()
        .setPortfolioId("ACME-401K")
        .setHorizonDays(30)
        .build()
);
System.out.println("Risk score: " + result.getScore());

Pros

• 2–10x faster than REST (binary serialization, HTTP/2 multiplexing, persistent connections)
• Strongly typed contracts prevent interface drift between Java and .NET teams
• Built-in streaming support for large data transfers
• Excellent tooling in both Java and .NET

Cons

• Still network-bound — latency per call is lower than REST but still measured in milliseconds
• More complex setup than REST (protoc compilation, code generation pipeline)
• Contract management overhead — .proto files must stay synchronized
• Still requires running a separate .NET service process
• Not suitable for in-process, method-level calls to C# objects

Approach 3: JNI with a Native C++ Bridge

The Java Native Interface (JNI) is a framework built into the JVM that allows Java code to call native C/C++ functions. By writing a native C++ layer that hosts the .NET CLR (using CLR Hosting APIs or COM interop), you can create a bridge from Java through C++ into C#.

How It Works

1. Write a Java class with native method declarations
2. Implement the native methods in C++ using JNI
3. In the C++ code, initialize the .NET CLR and invoke C# methods
4. Return results back through C++ to Java

Java Side:

public class DotNetBridge {
    static {
        System.loadLibrary("DotNetBridge");
    }
    public native double calculateRiskScore(String portfolioId, int horizonDays);
}

C++ Bridge (simplified):

#include <jni.h>
#include <metahost.h>
#include <mscoree.h>
JNIEXPORT jdouble JNICALL Java_DotNetBridge_calculateRiskScore(JNIEnv *env, jobject obj, jstring portfolioId, jint horizon) {
    // Initialize CLR, load assembly, invoke C# method
    ICLRMetaHost *pMetaHost = NULL;
    CLRCreateInstance(CLSID_CLRMetaHost, IID_ICLRMetaHost, (LPVOID*)&pMetaHost);
    // ... CLR hosting code, method invocation, result extraction ...
    return riskScore;
}

Pros

• True in-process communication — no network latency
• Direct access to the CLR from within the JVM process
• Maximum control over the integration layer

Cons

• Extreme complexity — requires expertise in Java, C++, and C# plus JNI and CLR hosting APIs
• Manual memory management across three runtime environments (JVM, native heap, CLR)
• Platform-specific native code (Windows-only for CLR hosting; Mono/CoreCLR for cross-platform)
• Extremely difficult debugging — native crashes, memory leaks, and runtime conflicts
• Every new C# method requires corresponding C++ wrapper code
• Not viable for most enterprise teams without deep systems programming expertise

JNI is the technically low-level “correct” approach, but the development and maintenance cost is prohibitive for all but the most specialized use cases. Most teams that start down this path eventually abandon it for a higher-level solution.

Approach 4: Running .NET as a Subprocess

The simplest approach: run a .NET console application as a separate process from Java using ProcessBuilder, exchanging data through command-line arguments, standard I/O streams, or files.

ProcessBuilder pb = new ProcessBuilder("dotnet", "run", "--project", "RiskCalculator", "--", "ACME-401K", "30");
pb.redirectErrorStream(true);
Process process = pb.start();
BufferedReader reader = new BufferedReader(new InputStreamReader(process.getInputStream()));
String result = reader.readLine();
int exitCode = process.waitFor();
System.out.println("Risk score: " + result);

Pros

• Dead simple to implement — no special libraries or frameworks needed
• Complete process isolation between Java and .NET
• Works with any .NET application that has a CLI interface

Cons

• Massive overhead per invocation — .NET runtime startup costs 100ms–2s per call
• Data exchange limited to strings (stdout/stdin) or files
• No shared state between invocations
• Impractical for frequent or real-time interactions
• Rudimentary error handling (exit codes and stderr parsing)
• Security concerns with passing sensitive data via command-line arguments

This approach only makes sense for infrequent, batch-style operations — for example, triggering a .NET report generator from a Java scheduling system once per hour.

Approach 5: In-Process Bridging with JNBridgePro

JNBridgePro takes a fundamentally different approach to Java-.NET interoperability: it runs both the JVM and the .NET CLR in the same process, generating Java proxy classes that let you call C# methods as if they were native Java code. This eliminates network latency, serialization overhead, and the need for complex C++ wrapper code.

How It Works

JNBridgePro’s proxy generation tool analyzes your .NET assemblies (DLL files) and creates corresponding Java classes containing proxy objects. These proxies handle all type marshaling between Java and .NET types automatically — including complex objects, collections, exceptions, and event callbacks.

At runtime, JNBridgePro manages an embedded .NET CLR within your Java process (or vice versa), routing method calls through an optimized shared-memory channel. Both garbage collectors are coordinated to prevent memory leaks and ensure proper object lifecycle management.

Key Capabilities

• Bidirectional calls: C# code can call back into Java, enabling event-driven and callback-based architectures
• Automatic type conversion: .NET List<T> ↔ Java ArrayList, Dictionary<K,V> ↔ HashMap, and all primitive type mappings
• Exception propagation: .NET exceptions become Java exceptions with complete stack traces preserved
• Coordinated garbage collection: No manual memory management — both runtimes’ garbage collectors work together
• Shared-memory transport: In-process communication with microsecond-level latency
• Support for modern .NET: Works with .NET Framework 4.x, .NET 6, 7, 8, and 9
• Support for modern Java: Compatible with Java 8 through Java 21+

For technical details, explore the JNBridgePro Developer Center.

Comparison Table: All C# from Java Integration Methods

JNBridgePro delivers in-process performance comparable to JNI but without the complexity of maintaining C++ bridge code, manual cross-runtime memory management, or platform-specific native libraries.

Step-by-Step: Calling C# from Java with JNBridgePro

Here’s a complete walkthrough for using JNBridgePro to call C# methods from Java in a real project.

Step 1: Install JNBridgePro

Download JNBridgePro and install both the Java-side and .NET-side components. The installer includes the proxy generation tool, runtime libraries, and documentation.

Step 2: Generate Java Proxy Classes

Launch the JNBridgePro proxy generation tool and point it at your .NET assemblies (DLL files). The tool analyzes the .NET types and generates corresponding Java proxy classes for each C# class, interface, and enum you want to access.

Step 3: Add Proxies to Your Java Project

Add the generated proxy JAR file and the JNBridgePro runtime JAR to your Java project’s classpath (or Maven/Gradle dependencies).

Step 4: Configure the Runtime

Create a properties file to configure the JNBridgePro runtime:

# jnbcore.properties
dotnet.side=shared-memory
dotnet.assembly.path=./lib/MyDotNetLibrary.dll
dotnet.runtime=coreclr

Step 5: Call C# Methods from Java

With proxies generated, calling C# from Java looks like standard Java code:

import com.jnbridge.jnbcore.DotNetSide;
import MyDotNetLibrary.*; // Generated proxy package

public class Main {
    public static void main(String[] args) {
        // Initialize JNBridgePro runtime
        DotNetSide.init("jnbcore.properties");

        // Create .NET objects and call methods — just like native Java
        RiskEngine engine = new RiskEngine();
        RiskResult result = engine.Calculate("ACME-401K", 30);

        System.out.println("Risk Score: " + result.getScore());
        System.out.println("Rating: " + result.getRating());
        System.out.println("Confidence: " + result.getConfidence());

        // .NET collections work like Java collections
        List<String> factors = result.getRiskFactors();
        for (String factor : factors) {
            System.out.println("Factor: " + factor);
        }
    }
}

No HTTP calls. No serialization code. No C++ wrappers. The .NET RiskEngine object behaves exactly like a native Java object, with full IDE support including code completion, type checking, and debugging.

Performance Considerations

When choosing how to call C# code from Java, performance characteristics vary dramatically across approaches:

Network-based approaches (REST, gRPC) add milliseconds of latency per call. For a business operation requiring 20 C# method calls, you’re accumulating 100ms–1,000ms of pure network overhead — before any actual computation. This compounds under load and introduces failure modes like connection exhaustion, timeouts, and service discovery issues.

Subprocess execution is the slowest option by far. Each invocation pays the full .NET runtime startup cost (100ms–2s), making it viable only for very infrequent operations.

JNI with CLR hosting offers excellent raw performance but carries enormous development risk. Incorrectly managed native references cause memory leaks and crashes that are extremely difficult to diagnose in production environments. Cross-runtime debugging requires specialized tools and deep expertise.

In-process bridging (JNBridgePro) delivers the optimal balance: microsecond-level method call latency with automatic memory management and full type safety. Because both the JVM and CLR share the same OS process, there’s no serialization overhead and no network stack involved — data passes through optimized shared-memory channels.

For applications requiring frequent Java-to-C# interaction (hundreds or thousands of method calls per operation), in-process approaches are the only viable option. Between the two in-process options (JNI and JNBridgePro), JNBridgePro eliminates months of C++ development and ongoing maintenance cost.

What About jni4net, IKVM, and Javonet?

Developers researching how to call C# from Java often encounter several alternative tools in Stack Overflow answers and older blog posts:

jni4net is an open-source library that bridges Java and .NET using JNI. While it appears in many search results and Stack Overflow discussions, the project has been largely unmaintained since 2015. It does not support modern .NET (Core, .NET 5+) and lacks documentation for current Java versions. It can work for simple prototypes on .NET Framework but is not suitable for production enterprise systems.

IKVM translates Java bytecode to .NET CIL, allowing Java code to run on the CLR. This is primarily useful in the opposite direction (running Java code in .NET), and has limitations with complex Java libraries that depend on JVM internals. The project has had periods of dormancy, though community forks exist.

Javonet is a commercial tool that provides cross-runtime method invocation between Java and .NET. It offers a different architecture and licensing model from JNBridgePro and is worth evaluating alongside it for your specific requirements.

GraalVM Native Image allows compiling C# (via .NET’s NativeAOT) or Java into native shared libraries. While technically interesting, it imposes severe restrictions on the source code (limited reflection, no dynamic class loading) and requires significant build pipeline complexity.

JNBridgePro remains the most mature and widely deployed dedicated solution for enterprise Java-.NET interoperability, with active development since 2001, professional technical support, and a comprehensive knowledge base.

When to Use Each Approach

Choose REST APIs when your Java and C# systems are genuinely separate services that communicate infrequently, and you’re already invested in a microservices architecture. This is the most common approach but rarely the best for tight integration.

Choose gRPC when you need better performance than REST with strong contract typing, but your Java and .NET components can operate as independent services with well-defined interfaces.

Choose JNI + C++ + CLR Hosting only if you have a team with deep expertise in C/C++, JNI, and CLR hosting APIs, and you need maximum control over a very narrow, well-defined integration surface. This is rarely the right choice.

Choose subprocess execution for simple, infrequent batch operations where a .NET CLI tool needs to be triggered from a Java scheduler or workflow engine. Avoid for anything requiring low latency or frequent calls.

Choose JNBridgePro when you need:

• Direct method-level access to C# classes from Java code
• In-process performance without network overhead or serialization
• Automatic type marshaling between .NET and Java types
• Bidirectional communication — Java calling .NET AND .NET calling back into Java
• Production-grade reliability with professional support and active maintenance
• Integration with existing .NET libraries or legacy C# systems without modification

For most enterprise scenarios involving Java-.NET interoperability — especially legacy system integration, gradual platform migration, and cross-platform library access — JNBridgePro provides the most productive and reliable path forward.

Ready to evaluate? Download a free trial of JNBridgePro to test with your own codebase, or contact the JNBridge team to discuss your integration requirements.

Frequently Asked Questions

Can Java call C# code directly?

Java cannot call C# code directly because Java runs on the JVM while C# runs on the .NET CLR — two separate runtime environments with different type systems, memory models, and execution engines. However, you can bridge them using network-based approaches (REST APIs, gRPC), native interop (JNI with CLR hosting), or dedicated bridging tools like JNBridgePro that run both runtimes in the same process and handle type conversion automatically.

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

The fastest way to call C# from Java is using in-process bridging, which runs the .NET CLR and the JVM within the same application process. This eliminates network latency and serialization overhead entirely, reducing per-call latency to microseconds rather than the milliseconds required by REST or gRPC. Both JNI (with CLR hosting) and JNBridgePro offer in-process performance, but JNBridgePro eliminates the need for C++ wrapper code and manual memory management.

Is jni4net still maintained?

No, jni4net has not been actively maintained since approximately 2015. While it still appears frequently in Stack Overflow answers and search results, it does not support modern .NET versions (.NET Core, .NET 5/6/7/8/9) and is not recommended for new projects. For actively maintained Java-.NET bridging solutions, consider JNBridgePro, which supports current versions of both .NET and Java with professional technical support.

Can you use .NET libraries in a Java application?

Yes, you can use .NET libraries (DLL assemblies) in a Java application. The most practical approaches are: (1) wrapping the .NET library in a REST API or gRPC service that your Java application calls over the network, or (2) using an in-process bridging tool like JNBridgePro that generates Java proxy classes from .NET assemblies, allowing you to call .NET library methods as if they were native Java methods.

How does JNBridgePro handle type conversion between Java and .NET?

JNBridgePro automatically marshals types between the JVM and CLR. Primitive types (int, double, string, boolean) are converted transparently. Complex types are represented as proxy objects — when you access a property or call a method on a proxy, JNBridgePro routes the call to the actual .NET object. Collections like List<T> and Dictionary<K,V> are converted to their Java equivalents (ArrayList, HashMap). Exceptions thrown in .NET are caught and re-thrown as Java exceptions with the original stack trace preserved.

What is the difference between calling C# from Java vs. calling Java from C#?

Both directions of Java-.NET interoperability use similar underlying techniques, but the tooling and setup differ. When calling Java from C#, the .NET application hosts the JVM. When calling C# from Java, the Java application hosts the CLR. JNBridgePro supports both directions with the same licensing and similar proxy generation workflows. For a detailed guide on the reverse direction, see our post on how to call Java from C#.

Does JNBridgePro work with .NET 8 and Java 21?

Yes, JNBridgePro supports modern versions of both platforms, including .NET 8, .NET 9, and Java 21+. It also maintains backward compatibility with .NET Framework 4.x and older Java versions (Java 8+). Check the JNBridgePro product page for the latest compatibility matrix.

Related Articles

Continue exploring Java-.NET integration:

• How to Call Java Code from C#
• Anatomy of a Shared Memory Bridge
• JNBridgePro + Claude Code Demo
• JNBridge TCP Configuration Guide

JNBridgePro lets your .NET code call Java classes as if they were native .NET types. But setting up a project from scratch can be daunting — proxy generation, classpath wiring, transport configuration — there are a lot of moving parts to get right.

So we used Claude Code to build a reference project that handles all of that, and then documented the entire thing in a CLAUDE.md file that Claude Code can read. The result: you can point Claude Code at the project, tell it what Java library you want to call from .NET, and it has enough context to walk you through every change.

What’s in the Box

A .NET Framework console app that calls Java’s log4j logging library and a custom Java class through JNBridge-generated proxy DLLs. The project is organized into three folders — Java source, proxy generation tooling, and the .NET project — with orchestrator scripts that build and run everything in one step.

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

Two Ways to Run: Shared Memory vs. TCP

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

buildAndRunSharedMem.bat — Shared Memory Mode

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

1. Compiles Java source and packages it into a JAR
2. Generates .NET proxy DLLs — JNBridge scans your JARs and creates C# wrapper classes for each Java class you want to call
3. Builds the C# project with dotnet build
4. Generates the runtime config — injects your JVM paths from env.bat into the output config file
5. Runs the demo

buildAndRunTCP.bat — TCP Mode

This runs Java as a separate process and connects over TCP (port 8085). Useful for debugging the Java side independently or running Java on a different machine.

1. Compiles Java and generates proxies (same as above)
2. Builds the C# project
3. Swaps in the TCP config instead of the shared-memory config
4. Launches the Java side in a separate console window
5. Runs the .NET app, which connects to the Java side over TCP
6. Cleans up the Java process when the demo exits

Getting Started with JNBridgePro

1. Install JNBridgePro and Download Demo

Download JNBridgePro v12.0 from jnbridge.com and run the installer.

Download Demo with claude.md

2. Request a License

After installation, run the JNBridge registration tool to request a license. Go to Registration Key → copy registration key → select “request license” to complete the online license request. We’ll email you a license.

Then, add the license to the build directory or JNBridge install directory.

3. Edit env.bat

This is the only file you need to customize. Open env.bat at the project root and set JAVA_HOME to point to your Java 8 JDK:

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

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

4. Run It

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

Adapting It with Claude Code

This is where the CLAUDE.md pays off. Open Claude Code in the project directory and tell it what you want — “swap log4j for my JDBC driver,” “add a new Java class to the proxies,” “switch to TCP mode.” Claude Code reads the documentation and knows the full build pipeline, so it can make the right changes across all the files without you having to trace through the wiring yourself.

Ready to try it? Download JNBridgePro and the Demo to get started. Or check out the Developer Center for more guides and documentation.

Related Articles

Learn more about JNBridgePro:

• How to Call Java from C# — Complete Guide
• How to Call C# from Java — Complete Guide
• Shared Memory Bridge Anatomy
• TCP Configuration: SSL & Whitelisting