-
Some years ago, I wrote a custom JNI wrapper over libuv [0] for a Java/Kotlin project I was working on. It’s mind-blowing how much work it took to get cross-compilation and everything else working. That said, as someone who’s been writing C code for years, it wasn’t the worst experience I’ve had; it was mostly just tedious.
[0]: https://github.com/1791-labs/carlie
-
InfluxDB
InfluxDB – Built for High-Performance Time Series Workloads. InfluxDB 3 OSS is now GA. Transform, enrich, and act on time series data directly in the database. Automate critical tasks and eliminate the need to move data externally. Download now.
-
As far as I understand it, with JNA, all calls into C code go through libffi: https://github.com/java-native-access/jna/blob/master/www/Fu...
This means that every call sets up some libffi data structures and libffi uses this information to perform the native call. Likewise in the other direction for return values. With JNI (and Panama), Hotspot can directly emit the argument/return code a the call, not too dissimilar from what a C or C++ compiler would do. There is still some overhead from maintaining JVM invariants. For example, I think a thread blocked in an FFI call can still participate in a safepoint. But that applies to JNI as well.
-
cljfx
Declarative, functional and extensible wrapper of JavaFX inspired by better parts of react and re-frame
More broadly, non-Electron apps have been uncommon for a while. I just don't work in the webspace and I need to write code that's relatively performant. I understand it's all possible with Electron.. but it's a bit daunting to have a client-server web stack and multiple languages and some numbercrunching backend
JavaFX was a nice solution that's crossplatform and near-native. It has a very nice react-like library in Clojure called `cljfx`
https://github.com/cljfx/cljfx/
