But native code dependencies in those languages usually work similarly to JNI in java, where you write wrapper code in c or c++ to convert from native apis to the interpretor's interface. So interfacing with native code isn't fundamentally easier than for java. Python does have ctypes, but that isn't what libraries like numpy use, probably because of performance.
I think there are a couple of other reasons why Java doesn't have the same problems with brittle builds. One is that for python and ruby and to a lesser extent node, it is more often necessary to use native code to get desirable performance, so there are more cases where native code is used. Another is that in the JVM ecosystem, it is more common for packages to be distributed in binary form rather than as sources, so you don't run into problems compiling dependencies, because you download a package that already has the compiled library in it.
> it is more common for packages to be distributed in binary form rather than as sources, so you don't run into problems compiling dependencies
Not sure what you mean here. Java bytecode is similar to source code, just easier for machines to parse, also easy to decompile. Mainstream Java is an interpreted language (requires JVM), not compiled.
Don't see what's the difference with packaging, say, python code to a zip archive.
I mean that java libraries that do use native code don't ship packages with c source code, that the user is expected to compile locally, as is common in python, ruby, and node. But instead they typically have a jar that includes a pre-compiled binary library, or several to support multiple platforms. So as long as you are using one of the supported platforms, it just works. But if you are on a platform that doesn't have a pre-compiled library, you will probably need to build the package yourself.
Its relatively common in Python for C/C++ code to be shipped pre-compiled as part of binary wheels (for at least the most common architectures). You do still end up falling back to sdists if your Python version or OS don't line up with any of the supplied binary wheels from the author. e.g. take a look at the pre-compiled set for pydantic-core https://pypi.org/project/pydantic-core/#files
Gotcha, yes, in my experience as long as a python library installs as a prebuilt wheel (.whl), then it's ok. If it tries to compile on my machine (setup.py) -- it never is able to.
I think there are a couple of other reasons why Java doesn't have the same problems with brittle builds. One is that for python and ruby and to a lesser extent node, it is more often necessary to use native code to get desirable performance, so there are more cases where native code is used. Another is that in the JVM ecosystem, it is more common for packages to be distributed in binary form rather than as sources, so you don't run into problems compiling dependencies, because you download a package that already has the compiled library in it.