Anatomy of a .NET Project That Calls Java (Shared Memory Bridge)

1) 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.

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 separated post: Changing to TCP: Configuration, SSL, Whitelisting & Startup.

2) Project Layout

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.

BridgeDemo/
├── BridgeDemo.sln
├── BridgeDemo/    # .NET project
│   ├── Program.cs
│   ├── App.config
│   ├── bridgeDemo.dll    # Added as reference to project, built by JNBProxyGenerator from JavaClass or JAR
│   ├── JNBShare.dll   # Added as reference to project
│   ├── JNBSharedMem_x86/x64.dll
│   ├── jnbauth_x86/x64.dll
│   └── bin/Release/...    # Executable + runtime dlls
├── Java Side/    # Java side
│   ├── bridgeDemo/javaToCall.java,javaToCall.class
│   ├── jnbcore.jar
│   ├── javaToCall.jar          # Java dependency in this demo
│   ├── bcel-6.10.0.jar    # Only needed for shared mem
│   ├── javaSide.properties
│   ├── classWhiteList.txt
│   └── start Java side.bat

3) .NET Side

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.

4) 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

5) 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.

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+.)

JNBridge Blog