I'm not sure if it's still true, but I believe back at Google the interop with C/C++ was even more integrated - if I'm not mistaken the "java" binary got recompiled from scratch (but thanks for caching, not much hit), and your C/C++ code got compiled in with it - so no ".so" loading - you still have single binary (and I think the .jar also went at the end of the file).
Or maybe that was for python (e.g. compile CPython along with any ffi modules as one) + .zip file with classes.
In any case, even if above was not 100% true, it's doable with system like bazel/buck/etc., and still allow you for smooth incremental development (or say in the default "fastbuild" .so files may still be used - locally, but in "opt" the full static link, or through a --config)
My main issue with bazel is that adopting it means giving up good editor integrations for anything besides JVM (maybe C/C++ as well, I haven't touched that). And even then, only IntelliJ has good support.
I think a lot of smaller (read: most) companies adopt bazel without realizing this. You will pay dearly in terms of developer experience in exchange for the benefits bazel purports to offer.
There are some workarounds. In my company we have a script that generated IDE files automatically. It uses `bazel query` and `bazel build` to find all external and non native dependencies, and then generates IDE config and files for rust, java, python, etc.
Positives: your IDE experience becomes native and you don't need to interact with bazel for normal IDE work flows.
Negatives: need to run the generate script anything non native changes. Also need to deal with bazel build files etc for the git workflow, obviously.
We're small company, and this method has worked great, and we have a pretty complex build with python accessing rust and java (via jni). Java accessing rust and c (via jni).
Yes that's true. To this day using bazel + IntelliJ and I can't jump into some header files from other @repos// (it could be that I'm on Windows, and this doesn't work there). Need to give it a try on Linux/OSX.
Or maybe that was for python (e.g. compile CPython along with any ffi modules as one) + .zip file with classes.
In any case, even if above was not 100% true, it's doable with system like bazel/buck/etc., and still allow you for smooth incremental development (or say in the default "fastbuild" .so files may still be used - locally, but in "opt" the full static link, or through a --config)