JNI调用Kotlin函数时，显式转换C++原生类型是否必要？

首先明确问题背景：我们有一个Kotlin单例类的静态函数：

object SampleObjectClass {
    fun SampleFunction(Int_data: Int, Float_data: Float, String_data: String) {
        // TODO:
    }
}

在C++中通过JNI调用该函数时，传递数值参数存在两种可行方式：

// 变量声明
int   int_data = 10;
float float_data = 10.10;
const char * string_data = "Hello From Cpp";
jstring java_string;

// 将char*转换为jstring
java_string = env->NewStringUTF(string_data);

// 方式1：依赖JNI隐式转换
env->CallStaticVoidMethod(SampleObjectClass, SampleFunctionMethodID, int_data, float_data, java_string);

// 方式2：显式转换为JNI类型
env->CallStaticVoidMethod(SampleObjectClass, SampleFunctionMethodID, (jint) int_data, (jfloat) float_data, java_string);

以下是针对问题的具体解答：

一、显式转换与隐式转换的优劣对比 #

隐式转换的优劣势 #

• 优势：代码简洁清爽，不需要额外的类型转换语法，减少冗余代码，阅读时更流畅。
• 劣势：
  • 代码意图模糊：不熟悉JNI的开发者可能会困惑参数类型是否完全匹配JNI的要求；
  • 平台移植风险：虽然主流平台上int和jint、float和jfloat的内存布局一致，但如果在特殊平台上C++原生类型与JNI类型的位数/存储方式不同，隐式转换可能导致意外的截断或数据错误；
  • 类型不匹配警告不醒目：比如把long类型隐式转为jint，编译器可能仅在高警告级别下提示截断风险，容易被忽略。

显式转换的优劣势 #

• 优势：
  • 代码意图清晰：明确告知阅读者此处是将C++原生类型转换为JNI标准类型，大幅提升代码的可读性和维护性；
  • 降低移植风险：显式转换强制指定类型转换规则，即使平台上C++类型与JNI类型存在差异，编译器也会明确提示潜在问题（比如截断风险）；
  • 便于排查问题：当JNI调用出现参数类型错误时，显式转换的代码更容易定位问题根源。
• 劣势：会增加少量冗余的类型转换语法，相比隐式转换稍显繁琐。

二、类型隐式转换的支持范围 #

是的，仅C的原生数值类型（如int、float、long、double等）支持向对应的JNI基本类型（jint、jfloat、jlong、jdouble）隐式转换。原因是JNI的基本类型本质是对C原生数值类型的typedef（例如多数平台上jint就是int的别名，jfloat就是float的别名），完全符合C++隐式转换的规则。

而char*属于C的指针类型，jstring是JNI中代表Java字符串的引用类型句柄，两者不属于同一类型体系，没有对应的隐式转换规则。jstring的创建必须通过JNI环境提供的NewStringUTF（或NewString）函数完成，因为Java字符串的内存由JVM管理，需要JNI桥接层来完成C字符串到Java字符串的内存转换与生命周期管理。

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