4 ms·

I'm not very familiar with Java's native interface, but you could potentially implement the native and non-native approaches as separate classes with a common i

I'm not very familiar with Java's native interface, but you could potentially implement the native and non-native approaches as separate classes with a common interface, and choose to inject the correct dependency to the calling code at runtime by detecting OS features?

KMag 6y ago
It clearly can be done, perhaps by using reflection and catching a class loading exception, but it's pretty common boilerplate that should optionally be handled by the language runtime's FFI. Let's say you want to have a native-looking prompt window via wxWidgets, and fall back to Swing if wx isn't installed. Or, you want to use some particular optimized native BLAS library if it's installed, or fall back to doing the linear algebra in Java if it's not available. In these cases, and many others, "detecting OS features" involves checking LD_LIBRARY_PATH (or PATH on Win32) for libraries, checking they're for the correct architecture, etc. The OS already provides dlopen() or its equivalent for this purpose. Properly detecting the OS and emulating the OS's algorithm for finding native libraries is just wasteful when the OS already exposes the functionality. As an added bonus, an FFI that replaces a method body allows someone who doesn't have the C/C++/Rust/FORTRAN handy, or can't read it, to see roughly what the native code should be doing.