C与Java间char*缓冲区通用数据传递及JNI替代方案问询

Can we parse a raw char* from C directly in Java? #

Short answer: Yes, but you’ll need to work around Java’s lack of raw memory access using direct ByteBuffers. Here’s how to pull it off:

• In your JNI layer, skip unpacking the char* into a C struct first. Instead, use JNI’s NewDirectByteBuffer() function to wrap the raw pointer and data length into a Java ByteBuffer. This creates a direct reference to the native memory block—no data copying involved.
• On the Java side, use the ByteBuffer’s built-in methods (getInt(), getShort(), get(byte[]), etc.) to manually parse fields according to the message’s structure. For example, if the C message starts with a 4-byte integer header, you’d call buffer.getInt(0) to read it. You’ll need to mirror the original C struct’s field offsets and data types in your Java code.

Important notes:

• Memory management is critical: You must ensure the native char* is freed once Java finishes processing it. You can either have JNI trigger the free operation after use, or use Java’s Cleaner/PhantomReference to handle cleanup automatically.
• This approach still ties you to hardcoding field rules in Java—so if the provider changes the spec, you’ll need to update those parsing logic manually.

Better alternatives to JNI for frequent message spec changes #

JNI is notoriously brittle when specs shift often—you’re stuck updating C code, recompiling, and syncing changes with Java. Here are three far more flexible options:

1. Use JNA/JNR-FFI instead of handwritten JNI #

These libraries let you call C functions directly from Java without writing any C glue code:

• With JNA, you define C function signatures in Java interfaces, and the char* return value maps to a JNA Pointer object. You can then use Pointer methods (like getInt(long offset) or getString(long offset)) to read data, similar to the ByteBuffer approach but without JNI boilerplate.
• The biggest win: When the message spec changes, you only update the Java parsing logic—no C code or compilation required. Performance is slightly lower than handwritten JNI, but for 100 messages/second, it’s completely negligible.

2. Adopt a cross-language serialization framework #

If you can modify the C side (or convince the provider to adapt), switch to a schema-based format like Protocol Buffers or FlatBuffers:

• Define your message schema in a .proto (PB) or .fbs (FlatBuffers) file. Both tools generate type-safe C and Java code from the schema automatically.
• On the C side, convert the raw char* data into the serialized format (or have the provider send data in this format directly). On the Java side, just use the generated classes to parse the data.
• When specs change, update the schema file, regenerate code for both languages, and you’re done. No manual parsing logic to tweak—this is the most scalable option for frequent spec updates.

3. Wrap the C API in a lightweight intermediate service #

If modifying the C side isn’t feasible, build a small proxy service (in C, Go, or Python) that:

• Calls the legacy C API to fetch the char* data.
• Parses it into a flexible format like JSON or MessagePack.
• Exposes an HTTP/TCP endpoint for Java to fetch the formatted data.
• On the Java side, use libraries like Jackson or Gson to deserialize the data into Java objects. When specs change, you only update the proxy’s parsing logic and Java DTOs—no JNI/JNA code to touch. This is the most flexible option, though it adds tiny network overhead (irrelevant for 100 messages/second).

内容的提问来源于stack exchange，提问作者Javadee