3 ms·

> [...] and this cost is worth it only when native calls are relatively common. In Java they are rare and easily abstracted away, [...] but it's clearly the rig

by cesarb 2y ago

> [...] and this cost is worth it only when native calls are relatively common. In Java they are rare and easily abstracted away, [...] but it's clearly the right one for Java given the frequency of native calls [...] Native calls are rare in Java because they're such a pain. If it wasn't so hard to do native calls in Java, it would be common even for non-experts to make use of non-Java libraries.

pron 2y ago
I don't think so, given that there are more popular Java libraries than popular libraries with a C ABI. There is a small number of very popular C libraries that result in the majority of native call uses. But in any event, calling native libraries in Java is now no longer a pain thanks to FFM (and jextract [1]) so we'll see. Note that interaction with native libraries often requires a more careful management of native memory that, though much easier now with FFM, is still significantly trickier (and more dangerous in terms of introducing undefined behaviour) than interacting with Java code regardless of how that interaction is declared in code. In Java, as in Python, interaction with native code -- in the vast majority of cases -- is best encapsulated inside a Java library and not often directly exposed to application programmers. [1]: https://github.com/openjdk/jextract https://github.com/openjdk/jextract
kaba0 2y ago
Interestingly enough, this actually turned into a positive over time — also, java was usually fast enough (compared to python) to avoid reaching for native all the time, so it wasn’t as big a pain point, it managed to create an almost completely pure, 99.9% java ecosystem. This means that even very very complex java apps will basically work on every OS, unlike python and to a smaller extent nodejs, where some cryptic dependency is only for windows/linux, etc.

3 ms·

> [...] and this cost is worth it only when native calls are relatively common. In Java they are rare and easily abstracted away, [...] but it's clearly the rig

by cesarb 2y ago

pron 2y ago
I don't think so, given that there are more popular Java libraries than popular libraries with a C ABI. There is a small number of very popular C libraries that result in the majority of native call uses. But in any event, calling native libraries in Java is now no longer a pain thanks to FFM (and jextract [1]) so we'll see. Note that interaction with native libraries often requires a more careful management of native memory that, though much easier now with FFM, is still significantly trickier (and more dangerous in terms of introducing undefined behaviour) than interacting with Java code regardless of how that interaction is declared in code. In Java, as in Python, interaction with native code -- in the vast majority of cases -- is best encapsulated inside a Java library and not often directly exposed to application programmers. [1]: https://github.com/openjdk/jextract https://github.com/openjdk/jextract
kaba0 2y ago
Interestingly enough, this actually turned into a positive over time — also, java was usually fast enough (compared to python) to avoid reaching for native all the time, so it wasn’t as big a pain point, it managed to create an almost completely pure, 99.9% java ecosystem. This means that even very very complex java apps will basically work on every OS, unlike python and to a smaller extent nodejs, where some cryptic dependency is only for windows/linux, etc.