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

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

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

---

What We're Building

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

The goal is to make the moving parts visible:

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

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

Project Layout

The directory structure has two main areas:

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

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

.NET Side: Calling Java with Shared Memory

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

Referenced Assemblies

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

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

Supporting DLLs

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

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

App.config

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

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

Key attributes:

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

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

Java Side

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

Core and Supporting JARs

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

Java Code or Packaged JAR

Depending on your build, you'll have either:

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

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

Java-Side Properties File

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

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

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

Considerations for Shared Memory Setups

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

Architecture Matching

The JVM architecture must match your .NET build target:

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

Supporting DLLs must also match:

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

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

Keep Bridge DLLs Beside the Executable

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

• JNBShare.dll
• JNBSharedMem_x*.dll
• jnbauth_x*.dll

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

Handling ClassNotFoundException and NoClassDefFoundError

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

1. Permissions

Ensure the user running the app has:

• Read & Execute
• List Folder Contents
• Read access

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

2. Classloader conflicts on Java 8 and earlier

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

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

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

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

Shared Memory vs TCP

Shared memory is usually the right fit when:

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

TCP is usually better when:

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

Wrapping Up

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

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

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