Setting up a Java/.NET bridge project from scratch is one of those tasks that shouldn't be hard but somehow always is. Proxy generation, classpath wiring, transport configuration, build scripts — there are enough moving parts that you'll spend your first afternoon just getting "Hello World" to compile.
So we tried something different: we pointed Claude Code at a reference project, gave it a CLAUDE.md file documenting every file and build step, and let it handle the wiring. The result was surprisingly good.
What the Reference Project Does
The project is a .NET Framework console app that calls Java's log4j logging library and a custom Java class through JNBridge-generated proxy DLLs. It's organized into three folders:
- Java source — your Java classes
- Proxy generation tooling — JNBridge's proxy generator config
- The .NET project — the C# app that calls into Java
Orchestrator scripts build and run everything in one step.
The key file is CLAUDE.md. It documents every file, every build step, and every configuration flag. This means Claude Code understands the full project structure — when you ask it to swap in a different Java library or change the transport mode, it knows exactly which files to touch and why.
Two Transport Modes: Pick Your Architecture
The demo ships with two build scripts, each demonstrating a different JNBridge transport mode.
Shared Memory Mode (In-Process)
buildAndRunSharedMem.bat embeds the JVM directly inside the .NET process. No separate Java process to manage.
The pipeline:
- Compiles Java source → packages into a JAR
- Generates .NET proxy DLLs (JNBridge scans your JARs and creates C# wrapper classes)
- Builds the C# project with
dotnet build - Generates runtime config — injects JVM paths from
env.bat - Runs the demo
This is the fastest option — no network overhead, no serialization. Your .NET code calls Java methods like they're native .NET calls.
TCP Mode (Separate Process)
buildAndRunTCP.bat runs Java as a separate process and connects over TCP (port 8085). Useful when you need to:
- Debug the Java side independently
- Run Java on a different machine
- Isolate the JVM from the .NET process
Same build pipeline, but it swaps in TCP config, launches the Java side in a separate console window, and cleans up when the demo exits.
Getting Started
1. Install JNBridgePro
Download JNBridgePro and run the installer.
Then grab the demo project with CLAUDE.md.
2. Get a License
After installation, run the JNBridge registration tool:
- Go to Registration Key → copy registration key
- Select "Request License" to complete the online request
- License arrives via email — drop it in the build directory
3. Edit One File
Open env.bat at the project root and set your Java home:
set JAVA_HOME=C:\Program Files\Java\jdk1.8.0_202
That's it. All build scripts read their Java paths from this one file.
4. Run It
Double-click buildAndRunSharedMem.bat. If everything's set up correctly, you'll see .NET calling Java.
The AI Part: Why CLAUDE.md Matters
This is where the project gets interesting for the Dev.to crowd.
The CLAUDE.md file is essentially a machine-readable project handbook. Open Claude Code in the project directory and tell it what you want:
- "Swap log4j for my JDBC driver"
- "Add a new Java class to the proxies"
- "Switch to TCP mode"
Claude Code reads the documentation and knows the full build pipeline, so it can make the right changes across all the files without you having to trace through the wiring yourself.
This pattern — documenting your project structure in a way that AI tools can consume — is something I think we'll see a lot more of. It's not just about Java/.NET integration; any project with complex build pipelines benefits from having a CLAUDE.md (or equivalent) that maps out the dependency graph.
Try It
- Download JNBridgePro (free trial)
- Grab the demo project
- Developer Center for more guides
If you're working on Java/.NET interop — or just curious about using AI to manage complex project setups — give it a spin and let me know how it goes in the comments.
Top comments (0)