将原生API迁移至Scala：JNI与Scala Native方案对比咨询

Hey there! Let’s break down which approach makes sense for your scenario—this all boils down to your project’s existing code, maintenance goals, performance needs, and target platforms. Here’s a practical breakdown:

Go with JNI if... #

• You already have existing JNI/C or Java wrapper code: If your team has already built out JNI bindings or Java wrappers for this native API, reusing that work is a no-brainer. JNI’s been around forever, so troubleshooting issues or finding examples is way easier than with newer tools like Scala Native.
• Cross-JVM language compatibility matters: If your codebase mixes Scala with Java or Kotlin, JNI’s Java layer acts as a natural bridge—your Scala code can call the Java wrappers directly without any extra hoops.
• The native API relies on complex data structures: As you noted, JNI lets you work directly with the native API’s structs, pointers, and memory layouts in C. This avoids the hassle of mapping those complex types to Scala Native’s type system, which can get tricky if the API uses low-level memory operations heavily.

Go with Scala Native if... #

• You want to eliminate double-wrapping overhead: Scala Native compiles Scala code directly to native machine code (via LLVM) instead of running on the JVM. That means no more "JNI C → JVM → Scala" layers—your Scala code talks straight to the native API, which simplifies maintenance and cuts down on cross-boundary performance hits.
• You prefer a unified Scala-first development experience: Scala Native supports almost all of Scala’s syntax and standard library features. You can use pattern matching, higher-order functions, and Scala’s type system to write your native bindings, instead of juggling C, Java, and Scala code like you would with JNI.
• You need simpler portability: Scala Native produces standalone native binaries, so you don’t have to worry about JVM dependencies, classpath issues, or compiling separate native libraries (.so/.dll) for different platforms. If you’re targeting environments without a JVM (like lightweight containers or embedded devices), this is a huge win.
• Performance is critical: While JNI performance is decent, it still has overhead from JVM-native context switching. Scala Native skips that entirely—your code runs as native machine code, making it a better fit for high-frequency calls to the native API.

A Middle Ground? #

If parts of your native API are super complex (and you have existing JNI code for them) but other parts are straightforward, you could mix approaches. Just be warned: mixing JVM and Scala Native code adds interop overhead, so only do this if the reuse benefits outweigh the complexity.

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