Enterprise-Grade Java ↔ .NET Integration

In-process. Type-safe. Production-proven.

☕

Java 8-25 Support

Full support for legacy Java 8 through modern Java 25. Backward compatible—run Java 8 bytecode on Java 17 JVM seamlessly.

Learn more →

⚡

Native Performance

In-process JNI-based communication. Zero marshalling overhead. 50%+ faster than REST/gRPC for large payloads.

Benchmarks →

🔒

Cyber-Safe by Design

No network channels, no attack surface. Both runtimes in same process with complete memory isolation.

Security details →

🎯

Type-Safe APIs

Strongly-typed wrappers for all Java/NET APIs. Full IntelliSense support. Compile-time error checking.

See examples →

How It Works

In-Process Integration via JNI

JCOBridge uses pure JNI (Java Native Interface) for bidirectional communication between .NET and JVM. Both runtimes exist in the same process, each executing native code at full speed.

Why This Matters:

✅ Zero Marshalling: Objects remain in their native runtime—no serialization overhead
✅ Zero Network Latency: No REST APIs, no gRPC, no network stack
✅ Memory Efficient: Direct pointer references, not data copies
✅ Type Safe: Strongly-typed wrappers at compile time

vs Alternative Approaches:

Approach	Performance	Complexity	Security
JCOBridge (JNI)	🟢 Native	🟢 Low	🟢 No Attack Surface
REST APIs	🔴 10-100x slower	🟡 Medium	🔴 Network exposed
gRPC	🟡 3-10x slower	🟡 Medium	🔴 Network exposed
Custom Channels	🟡 Varies	🔴 High	🔴 Attack surface

🆕 Java 8-25 Support

Full Version Coverage

JCOBridge supports all major Java versions from Java 8 (2014) through Java 25 (2025).

Java Version	Release Year	Support Status
Java 8 (LTS)	2014	✅ NEW Fully Supported
Java 11 (LTS)	2018	✅ Fully Supported
Java 17 (LTS)	2021	✅ Fully Supported
Java 21 (LTS)	2023	✅ Fully Supported
Java 25 (LTS)	2025	✅ Fully Supported

Extended Support: Oracle provides Java 8 Extended Support until December 2030. Free alternatives (Amazon Corretto, Azul Zulu) provide long-term updates.

Backward Compatibility

Mix Java Versions Seamlessly


┌─────────────────────────────┐
│ Java 17 JVM                 │
│                             │
│  ✅ Java 8 bytecode         │ ← Legacy code
│  ✅ Java 11 bytecode        │ ← Mid-tier code
│  ✅ Java 17 bytecode        │ ← Modern code
│                             │
│  All work together!         │
└─────────────────────────────┘

Key insight: Newer JVMs run older bytecode. Use Java 17 JVM and your Java 8 libraries will work without any code changes.

Example: Mixed Java Versions


// .NET application using Java 17 JVM

// Call legacy Java 8 library
var legacyValidator = new com.company.LegacyLib(); // Java 8
legacyValidator.Validate(data); // ✅ Works!

// Call modern Java 17 library
var modernService = new com.company.ModernLib(); // Java 17  
modernService.Process(data); // ✅ Works!

// Both in same process, zero migration needed!

View Java 8 Integration Guide →

⚡ Performance

Method invocation latency

Benchmarks run on GitHub Actions (ubuntu-latest) with 1,000,000 iterations per test, across .NET 8 / Temurin 17 and .NET 10 / Temurin 25. Results are repeatable across releases — see the full benchmark page for complete tables.

JVM method invocation from .NET (2.6.7, no-argument call):

Resolution strategy	.NET 8 / T17	.NET 10 / T25
`Invoke` (static)	0.495 µs	0.538 µs
`InvokeWithSignature` (static)	0.355 µs	0.327 µs
`Invoke` (instance)	0.370 µs	0.296 µs
`InvokeWithSignature` (instance)	0.313 µs	0.268 µs

InvokeWithSignature delegates argument validation to the JVM, avoiding .NET-side type matching on every call — consistently 20–40% faster than Invoke on hot paths.

JVM→.NET sustained callback latency (2.6.7, full processing):

Configuration	.NET 8 / T17	.NET 10 / T25
`byIndex = false`	5.094 µs	4.680 µs
`byIndex = true` ¹	4.391 µs	4.117 µs

¹ byIndex identifies events by numeric index on the CLR side, eliminating the string key lookup.

With the two-level ShallManageEvent early-discard filter (2.6.7):

Configuration	.NET 8 / T17	.NET 10 / T25
First gate discard, `byIndex = false`	0.569 µs	0.473 µs
First gate discard, `byIndex = true` ¹	44 ns	41 ns
Second gate discard, `byIndex = true` ¹	71 ns	66 ns

When events are discarded at the first gate with byIndex = true, per-event cost drops to 41–44 ns — within the range of raw JNI call overhead on bare-metal hardware, despite the additional CLR interop layer.

Improvements vs 2.6.6

2.6.7 reduces method invocation latency by 25–40% across all resolution strategies and runtime combinations compared to 2.6.6. Sustained callback latency improves by 16–17% on the full-processing path.

Why so fast?

JCOBridge uses pure JNI — both runtimes run in the same process, with no network stack, no serialization, and no data copies. Objects stay in their native runtime; what crosses the JNI boundary is a reference, not a payload. Both the JVM JIT and the .NET JIT can optimize hot paths independently.

For comparison, network-based approaches (REST, gRPC) add TCP/IP stack latency on top of serialization cost — typically in the millisecond range even on localhost. JCOBridge operates in the sub-microsecond to low-microsecond range.

For sustained high-frequency workloads

At high callback rates, GC pressure on cross-boundary object references becomes the primary reliability concern — not raw per-call latency. The HPA Edition addresses this at the JCOBridge layer, ensuring cross-boundary references are properly rooted regardless of GC activity on either side. Technical details →

🔒 Cyber-Safe by Design

✅ JCOBridge Approach

✅ No network ports opened
✅ No external attack surface
✅ Memory isolation between runtimes
✅ Standard OS process security applies
✅ No custom protocols to secure

⚠️ Network-Based Approaches


┌──────────────┐     Network      ┌──────────────┐
│ .NET Process │ ◄──────────────► │ Java Process │
│              │   (Exposed!)     │              │
│  Port: 8080  │                  │  Port: 8081  │
└──────────────┘                  └──────────────┘
      ↑                                  ↑
      │                                  │
   Attack                             Attack
   Surface                            Surface

❌ Network ports exposed
❌ Attack surface created
❌ Requires firewall rules
❌ Authentication/encryption needed
❌ Vulnerable to MITM attacks

Security Benefits

No Network Exposure

Both runtimes exist in the same process. No listening ports, no network traffic, no external exposure.

Reduced Attack Surface

Network-based integration creates attack vectors (port scanning, MITM, DOS). JCOBridge eliminates these entirely.

Simplified Security Model

No need for TLS certificates, authentication tokens, or custom encryption. OS-level process security is sufficient.

Compliance Friendly

Easier to meet security compliance (PCI-DSS, HIPAA, SOC2) when there’s no network communication between components.

Complete API Coverage

Call .NET from Java

✅ Type System

Load any .NET assembly
Access all public types
Generic types fully supported
Nested types and inner classes

✅ Members

Instance & static methods
Properties (get/set)
Fields (get/set)
Indexers
Constructors

✅ Advanced Features

Delegates and events
Extension methods
Nullable reference types

✅ UI Integration

WPF controls in AWT/Swing
WinForms in Java UI
Event handling
Data binding

Example: Call ML.NET from Java


// Java code calling .NET ML.NET library
import microsoft.ml.*;
import microsoft.ml.data.*;

public class FraudDetector {
    public static void main(String[] args) {
        // Create ML.NET context
        MLContext mlContext = new MLContext();
        
        // Load trained model
        ITransformer model = mlContext.Model.Load("fraud-model.zip");
        
        // Make prediction
        var engine = mlContext.Model.CreatePredictionEngine(model);
        var prediction = engine.Predict(transaction);
        
        System.out.println("Fraud probability: " + prediction.Score);
    }
}

Call Java from .NET

✅ Type System

Load any JAR file
Access all public classes
Generic types (List<T>, etc.)
Inner and anonymous classes

✅ Members

Instance & static methods
Fields (get/set)
Constructors (including varargs)
Method overloading

✅ Advanced Features

Functional interfaces (lambdas)
Streams API
Exceptions (try-catch)
Reflection API
Dynamic code (C# dynamic)

✅ UI Integration

Swing/AWT in WPF/WinForms
SWT controls
Event listeners

Example: Apache Kafka from C#


// C# code calling Apache Kafka Java APIs
using Org.Apache.Kafka.Clients.Producer;
using Java.Util;

public class KafkaProducer
{
    public void SendMessage(string topic, string message)
    {
        // Configure Kafka producer
        var props = new Properties();
        props.Put("bootstrap.servers", "localhost:9092");
        props.Put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
        props.Put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
        
        // Create producer
        var producer = new KafkaProducer(props);
        
        // Send message
        var record = new ProducerRecord(topic, message);
        producer.Send(record);
        
        producer.Close();
    }
}

Platform Support

Operating Systems

✅ Windows 10/11
✅ Windows Server 2016+
✅ Linux (Ubuntu, RHEL, CentOS, Debian)
✅ macOS

.NET Versions

✅ .NET Framework 4.6.2+
✅ .NET 6 (LTS)
✅ .NET 8 (LTS)
✅ .NET 9
✅ .NET 10 (LTS)

Java Versions

✅ Java 8 (JRE 1.8.0_161+) 🆕
✅ Java 11 (LTS)
✅ Java 17 (LTS)
✅ Java 21 (LTS)
✅ Java 25 (LTS)

JVM Distributions

✅ Oracle JDK
✅ OpenJDK
✅ Amazon Corretto
✅ Azul Zulu
✅ Eclipse Temurin
✅ Red Hat OpenJDK
✅ IBM Semeru Runtime
✅ And other OpenJDK-based distributions

Common Use Cases

🏦

Legacy System Integration

Integrate Java 8 core banking or payment systems with modern .NET cloud applications without migration.

Avoid $200K-$2M migration costs
Keep proven, certified systems
Add cloud/ML capabilities via .NET

🏭

Industrial Automation

Bridge Java MES/SCADA systems with .NET Azure IoT and analytics platforms.

OPC-UA via .NET libraries
Azure IoT Hub integration
Real-time dashboards

📊

Event Streaming

Use Apache Kafka from C# with native Java client performance.

Full Kafka API access
Kafka Streams in .NET
Kafka Connect connectors in C#

🤖

AI/ML Integration

Add ML.NET models to Java applications, or use Java ML libraries in .NET.

ML.NET in Java apps
TensorFlow Java in .NET
Cross-platform ML pipelines

Lightweight Footprint

Runtime Overhead

10-20 MB

For reference tracking and JNI layer

Deployment Size

< 5 MB

JCOBridge assemblies/JARs

CPU Usage

Minimal

~5-10% overhead vs native calls

Ideal for embedded systems: JCOBridge’s minimal footprint makes it perfect for resource-constrained environments like IoT gateways, industrial controllers, and edge computing devices.

Production Proven

Built on the field-proven DLR plugin from the Sinapse platform, JCOBridge guarantees reliable performance in demanding enterprise environments.

Ready to Bridge Java and .NET?

Get Started Free View Products Java 8 Guide

Community Edition free for development. Commercial licenses for production use.