特性、平台与方法选择

以下多平台规则适用于默认 JNI 后端。JVMCI 每次构建生成一个 Windows 或 Linux x86-64 目标，并要求受支持的 Zulu 运行时；详见 JNI 与 JVMCI 后端。原生库具有平台特异性。仅请求你的发布支持的平台，使用规范目标名，例如 windows-x86_64、linux-x86_64、linux-aarch64、android-aarch64、macos-x86_64 和 macos-aarch64。仅指定 OS 的名称会扩展为多个目标，托管构建最多允许四个不同的已扩展目标。显式 platforms 请求优先于项目默认值；两者都缺失时服务会回退为 linux-x86_64。在发布自动化中明确目标列表，而不要依赖该回退。

就特性而言，显式 features 优先于 processorId；否则依次考虑所属处理器预设、项目默认值，最后才是 disable-annotation-check。注解选择提供最强控制力。@Nativify 具有类保留期；静态方法、实例方法和构造器可以直接选择。类初始化器通过类级注解或 disable-annotation-check 选择。由于 JVM 不允许 <init> 或 <clinit> 本身声明为 native，初始化器主体会通过生成的静态原生辅助方法进行保护。抽象方法仍不符合条件。

native-unsafe 与 native-llvm-direct-call 是相互独立的 LLVM_CONFIG 编译器特性，可同时启用。该组合已在现有 Java 8 工作负载中验证，但尚未穷尽所有 JVM、平台或输入；发布前请用有代表性的工作负载测试精确特性集及目标原生行为。

invokedynamic 和 lambda 现在会直接本机化，并保留正确的调用方 bootstrap Lookup 与动态调用点缓存语义。多维数组创建仍可能需要提取；某些基本类型数组场景仍不受支持。JNI 穿越可能增加开销，因此请用代表性工作负载同时验证正确性与性能。