Our great sponsors
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
cljfx
Declarative, functional and extensible wrapper of JavaFX inspired by better parts of react and re-frame
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
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.
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/