Native (JNI) method declaration or native library load
ID |
scala.correctness.avoid_native_calls |
Severity |
info |
Remediation Complexity |
hard |
Remediation Risk |
medium |
Remediation Effort |
high |
Resource |
Portability |
Language |
Scala |
Description
Reports @native method declarations and the System.loadLibrary / System.load calls that bind them, which hand execution to code outside the JVM.
Rationale
Native code leaves every guarantee the JVM provides at the boundary: memory safety, exception semantics, the security manager and the garbage collector no longer apply, so a defect in the library corrupts the whole process rather than raising an exception. The dependency is also platform-specific, so the artifact stops being portable and each supported architecture needs its own binary, its own build and its own supply-chain review.
The following code illustrates the pattern detected by this rule:
class Hashing {
// FLAGGED: Native (JNI) method declaration or native library load
@native def fastHash(data: Array[Byte]): Long
}Remediation
Prefer a pure Scala or Java implementation, or a JDK API that already wraps the platform call. When the native dependency is unavoidable, isolate it behind a small interface so callers can be tested without it, validate every value crossing the boundary, and document the platforms for which a binary is shipped.