3 ms·

C++ library would crash your process or ruin your threading. Java one won't. Interfaces tend to be more stable. For complex things like Excel parsing Java is th

C++ library would crash your process or ruin your threading. Java one won't. Interfaces tend to be more stable. For complex things like Excel parsing Java is the way to go.

justincormack 13y ago
Thats not an answer to the question about interoperability. Java/C interop is a complete pain so the world is divided into two, C (native) libraries, which the non JVM languages can mostly interop with, and the JVM libraries that JVM languages can use. Most stuff is implemented eventually twice.
zaphar 13y ago
Java libraries can ruin your threading too. Java doesn't magically make everything you write threadsafe.
- guard-of-terra 13y ago
  You can guard against that. In Java, making things thread-safe is usually straight-forward. Java libraries tend to mis-handle classloader recycling, but most projects can ignore that.
memracom 13y ago
A lot of people are using the word "interface" to mean sticking two bits of object code together with the compiler and linker. In plain English, the word "interface" covers a lot more than that specific technique. Even most Java developers make a distinction between what the "interface" keyword does, and the broader CS term "interface". Why on earth would you want to stick some C code (or God forbid, C++ code) inside the same process as the JVM? If you control the OS, there are better ways to do the same thing with two separate proceses. And even if you don't control the OS, we do have techniques (most of them implemented inside Apache Camel) for hooking up a Java process and some other kind, without sharing bodily fluids. Apache Camel is safe hex, use it!
- guard-of-terra 13y ago
  "to mean sticking two bits of object code together with the compiler and linker" That's what I mean here. You drop your .jar into a folder and it tends to fit. Even if build options or library version differ. And you always have tests to check that!

C++ library would crash your process or ruin your threading. Java one won't. Interfaces tend to be more stable. For complex things like Excel parsing Java is the way to go.

justincormack 13y ago

Thats not an answer to the question about interoperability. Java/C interop is a complete pain so the world is divided into two, C (native) libraries, which the non JVM languages can mostly interop with, and the JVM libraries that JVM languages can use. Most stuff is implemented eventually twice.

zaphar 13y ago

Java libraries can ruin your threading too. Java doesn't magically make everything you write threadsafe.

guard-of-terra 13y ago
You can guard against that. In Java, making things thread-safe is usually straight-forward. Java libraries tend to mis-handle classloader recycling, but most projects can ignore that.

memracom 13y ago

A lot of people are using the word "interface" to mean sticking two bits of object code together with the compiler and linker. In plain English, the word "interface" covers a lot more than that specific technique. Even most Java developers make a distinction between what the "interface" keyword does, and the broader CS term "interface". Why on earth would you want to stick some C code (or God forbid, C++ code) inside the same process as the JVM? If you control the OS, there are better ways to do the same thing with two separate proceses. And even if you don't control the OS, we do have techniques (most of them implemented inside Apache Camel) for hooking up a Java process and some other kind, without sharing bodily fluids. Apache Camel is safe hex, use it!

guard-of-terra 13y ago
"to mean sticking two bits of object code together with the compiler and linker" That's what I mean here. You drop your .jar into a folder and it tends to fit. Even if build options or library version differ. And you always have tests to check that!