.NET and Java Data Sharing with Binary Serialization

Many organizations today use different .NET and Java technologies to develop various high-traffic applications. Thus, they need to share data between such technologies at runtime. Such data sharing is possible through databases, but is slow and doesn’t scale well. Alternatively, using in-memory distributed caches as a shared data store between multiple applications is much slower and linearly scalable.

Key Takeaways:

Incompatibility of Native Serialization: Native .NET and Java binary formats cannot share runtime data directly because they use entirely disparate type systems and embed language-specific, fully qualified type names inside their serialized byte streams.

Performance Bottlenecks of Text Alternatives: Utilizing XML or JSON as a cross-platform data bridge degrades in-memory distributed cache performance, introducing a 3x to 5x increase in serialization latency and expanding network payload sizes by more than 100% due to verbose text parsing and schema validation.

NCache Type-ID System Resolution: NCache eliminates cross-platform data mismatching by substituting complex language-specific assembly attributes with compact, technology-neutral Type-IDs mapped globally via a single configuration file (config.ncconf).

Zero-Reflection Dynamic Performance: To bypass the slow execution of traditional reflection-based data mapping, NCache utilizes runtime dynamic code generation to compile optimized serialization streams, maintaining sub-millisecond execution speeds across mixed .NET and Java caching clusters.

• NCache Details
• Portable Data Types
• Register Classes for Portable Data Sharing

What is .NET and Java Data Sharing?

.NET and Java data sharing is the process of exchanging runtime object data between heterogeneous application environments. By using a shared, in-memory distributed cache as an intermediate data store, organizations eliminate slow database trips and enable real-time cross-platform communication.

XML Serialization: Necessity and Issues

But even with this approach, you must consider the incompatibility of .NET and Java data types. Therefore, you have to transform the data into XML for sharing. Additionally, most distributed caches either don’t provide any built-in mechanism for sharing data between .NET and Java applications or only provide XML-based data sharing. If a cache doesn’t offer a built-in data-sharing mechanism, you must define the XML schema and use third-party XML serialization to construct and read all the XML data.

Unfortunately, the XML serialization process is notably slow and resource-hungry. It involves XML validation, parsing, and transformations, hampering application performance and consuming extra memory and CPU resources.

Distributed caching aims to improve your application performance and scalability. It achieves this goal by allowing your applications to cache their data and reducing expensive database trips, causing scalability bottlenecks. XML-based data sharing is the antithesis of these goals. With increased application transaction loads, XML manipulation becomes a performance bottleneck.

• NCache Details
• Portable Data Types
• Register Classes for Portable Data Sharing

Challenges of Using Native Binary Serialization for Data Sharing

Given all this, you could assume that binary-level serialization and data sharing are better options, avoiding any XML transformations. However, the native .NET and Java binary serialization are incompatible as they interpret objects differently, this is due to them having different type systems. Moreover, the serialized byte stream of an object also includes data type details, such as fully qualified names, which are dissimilar in .NET and Java, preventing data type compatibility between .NET and Java necessitating another alternative.

While XML and JSON formats provide readable cross-platform data, benchmarks show that text parsing can increase serialization latency by up to 3x to 5x and expand network payload sizes by more than 100% compared to optimized binary serialization in a high-throughput distributed cache.

Serialization Methods Comparison

The matrix below outlines the critical trade-offs between native, text-based, and NCache’s proprietary serialization approaches:

Serialization Type	Platform Interoperability	Payload Size / Overhead	CPU & Memory Efficiency
Native Binary	No (Tied to .NET / Java runtime)	Minimal / Low	High
XML / JSON	Yes (Text-based standard)	Large / Heavy Bloat	Low (Heavy text parsing)
NCache Data Sharing	Yes (Type-ID Translation)	Minimal / Highly Compact	High (Dynamic Code Gen)

• NCache Details
• Portable Data Types
• Register Classes for Portable Data Sharing

Runtime Data Sharing in NCache

Fortunately, NCache offers interoperable binary serialization that is common for both .NET and Java to handle these incompatibilities. It identifies objects based on type-ids consistent across .NET and Java instead of fully qualified names that are technology-specific. This approach not only provides interoperability but also reduces the size of the generated byte stream. As you can see in the all-attribute-list included under sharing-type as part of the <data-sharing> section in the  config.ncconf  as demonstrated below:

Secondly, NCache’s interoperable binary serialization implements a custom protocol that generates byte streams in a format that .NET and Java implementations can easily interpret. Here is an example of NCache config.ncconf with data interoperable class mapping. As shown below, first you need to declare the .NET classes as part of the sharing-class tag.

Then you declare the java classes as part of the sharing-class tag as well, but as a separate section:

Basically, NCache can serialize a .NET object and de-serialize it in Java with no code change as long as a compatible Java class is available. NCache facilitates a runtime code generation mechanism, for in-memory code serialization and de-serialization for your interoperable classes at runtime using the compiled form. Therefore, this binary-level serialization is more compact and faster than any XML transformation.

Conclusion

In summary, using NCache to share data between .NET and Java to scale and boost your application performance is incredibly efficient. It lets you avoid XML serialization, which is extremely slow and resource-hungry. So, what are you waiting for? Sign up for a fully working 30-day trial of NCache Enterprise and try it out for yourself.

• NCache Details
• Edition Comparison
• Download NCache

Frequently Asked Questions (FAQ)

Q: How does NCache locate and map fields if a .NET class and a Java class have different attribute names?

A: NCache maps mismatched attribute names using the serialization-order property within the <sharing-class> configuration of your config.ncconf file. Instead of relying on exact string matches of field names, NCache aligns data values sequentially based on the designated order integer, allowing cross-platform parsing to execute successfully even if the property names differ between language frameworks.

Q: Does NCache require the installation of third-party plugins or external serialization libraries to support cross-language data sharing?

A: No. NCache includes a native, built-in interoperable binary protocol. It bypasses both native runtime formatters and public third-party utilities by using an internal translation system. All definitions are managed natively via the cache configuration schema, meaning you do not need to import external serialization frameworks into your application assemblies.

Q: What happens behind the scenes when a Java application updates a cached object that was originally written by a .NET application?

A: When the Java application calls a write operation, NCache uses its internal Type-ID mapping to identify the shared layout schema. The Java client serializes the updated fields using the custom binary protocol and updates the entry in the distributed cluster. When a .NET client subsequently pulls that item, NCache reads the neutral payload format and dynamically builds the matching .NET object topology in-memory, ensuring that state transitions remain fully transparent to both application environments.

Q: Why is a database an inefficient medium for runtime data sharing compared to an interoperable distributed cache?

A: While databases natively inherently support multi-language connections, using them for real-time application data sharing creates severe disk I/O bottlenecks and prevents linear scalability. Moving transactional data through a shared distributed cache keeps data access purely in-memory, substituting expensive network roundtrips and relational database locking mechanisms with high-speed memory lookups.