6 ms·

> The JVM is a wonderful platform. The Java ecosystem interoperates with everything I hear this over and over but it never strikes me as true. The best and mos

> The JVM is a wonderful platform. The Java ecosystem interoperates with everything I hear this over and over but it never strikes me as true. The best and most widely used libraries and interfaces for a given problem always seem to be C++ or C. There's typically some slower and less comprehensive library for Java or .Net.

w0utert 13y ago
I also don't fully agree with the statement that Java (or other JVM based languages) is the pinnacle of interoperability. Try interfacing between e.g. Python and Java some time and you know what I mean. Besides JNI or some other JVM based language, interfacing between Java and something else basically means doing some form of IPC, which isn't fun.
- huherto 13y ago
  For enterprise applications usually you would use REST. And that is pretty easy, almost automatic.
  - notoriousjpg 13y ago
    Can you expand on this? I've never seen this opinion before. I would have guessed rest is too loosely defined for the structural rigidity of most enterprise applications?
- sannysanoff 13y ago
  There's no need to interface cpython and java. Looks like jython is already faster than cpython, so just use it, interface is ok.
  - justincormack 13y ago
    Then you can't use C libraries with it.
- memracom 13y ago
  If you do interoperability right, then you would use Apache Camel which interoperates effortlessly with everything including Python. The right way to interoperate between tools in different languages on different VMs, is to use something like AMQP or ZeroMQ both of which are supported in Camel and in Python. Now if you don't want to use Camel and want to build a Big Ball of Mud, that is your choice, but do not pretend that it is a best practice in the 21st century. The standards for software engineering have moved on.
  - w0utert 13y ago
    >> Now if you don't want to use Camel and want to build a Big Ball of Mud, that is your choice, but do not pretend that it is a best practice in the 21st century. The standards for software engineering have moved on. I don't even understand what you are saying here. Are you implying that if I have a Python application and a Java library that solves some very specific part of what the application does (say, applying some very complex algorithm to a few numbers, or decode some arcane undocumented file format), that I should use something that sells itself as: Apache Camel ™ is a versatile open-source integration framework based on known Enterprise Integration Patterns. Camel empowers you to define routing and mediation rules in a variety of domain-specific languages, including a Java-based Fluent API, Spring or Blueprint XML Configuration files, and a Scala DSL. This means you get smart completion of routing rules in your IDE, whether in a Java, Scala or XML editor. Because 'the standards of software engineering have moved on'? Not everyone is building large-scale enterprise software running on clouds of servers or whatever you have in mind. I can make up a million examples of pieces of software that perform only one single one-shot task (like a command line script) that may want to call out to some external library that implements some part of what the script is supposed to solve, and for those kind of applications, 'the standards of software engineering' should not have to dictate I have to use message queues or a versatile open-source integration framework based on known Enterprise Integration Patterns, amirite? If that library I need to call is written in Java and I need to call it from Python or some other non-JVM language (or even C/C++ because JNI is a pain in the ass as well), I'm SOL :-S
sannysanoff 13y ago
java and C are strong in different areas. I would rather say that choice of C libraries for enterprise or just for any useful web backend is poorer than for java ;)
- a8da6b0c91d 13y ago
  The only thing Java is tier one for is shoveling around XML/HTML and talking to databases. As soon as you leave that CRUD territory and need to work more seriously with algorithms or have high performance requirements, the available stuff is second tier. Off the top of my head, consider computational geometry. CGAL and boost.geometry are amazing. JTS is very slow and missing a lot. It's the same thing over and over with many sorts of libraries.
  - pjmlp 13y ago
    So why are the banks moving to Java and .NET for real time transactions? https://github.com/LMAX-Exchange/disruptor https://github.com/LMAX-Exchange/disruptor
  - profquail 13y ago
    Well-designed libraries usually trump poorly-designed libraries, performance-wise, regardless of which language they're implemented in. C++ isn't a magic bullet; it's plenty easy to write bloated, poorly-performing software in C++, just as it is in Java, C#, Ruby, etc. Here's just one counterexample to your claims: http://stackoverflow.com/questions/4257659/c-sharp-versus-c-performance/19505716#19505716 http://stackoverflow.com/questions/4257659/c-sharp-versus-c-...
guard-of-terra 13y ago
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!
  - 13y ago
tspike 13y ago
Additionally, Unicode is a nightmare in Java.
- pjmlp 13y ago
  Did you ever tried it in C and C++?
- thousande 13y ago
  Mozilla's HTML5 parser is written in Java. One of the reasons java was chosen was the unicode support [1] The Java code is converted to C++ in build time I think [2] [1] https://news.ycombinator.com/item?id=6204760 https://news.ycombinator.com/item?id=6204760 [2] http://ejohn.org/blog/html-5-parsing/ http://ejohn.org/blog/html-5-parsing/
pjmlp 13y ago
> The best and most widely used libraries and interfaces for a given problem always seem to be C++ or C. Where are the enterprise C and C++ libraries and server stacks? The enterprise is all about Java and .NET nowadays.
danieldk 13y ago
The best and most widely used libraries and interfaces for a given problem always seem to be C++ or C. I think it differs hugely per case. E.g. there are not great C++ or C libraries that provide functionality of Akka, Guava, or Java persistence. On the other hand, nothing in Java-land beats Qt, Cocoa, or Eigen. But I agree on interoperability. Interoperability within JVM-land is pretty great. But it is far easier to write a good binding for a C library in e.g. Python, Ruby, Go, or Haskell, than it is in JNI.

w0utert 13y ago

I also don't fully agree with the statement that Java (or other JVM based languages) is the pinnacle of interoperability. Try interfacing between e.g. Python and Java some time and you know what I mean. Besides JNI or some other JVM based language, interfacing between Java and something else basically means doing some form of IPC, which isn't fun.

huherto 13y ago
For enterprise applications usually you would use REST. And that is pretty easy, almost automatic.
- notoriousjpg 13y ago
  Can you expand on this? I've never seen this opinion before. I would have guessed rest is too loosely defined for the structural rigidity of most enterprise applications?
sannysanoff 13y ago
There's no need to interface cpython and java. Looks like jython is already faster than cpython, so just use it, interface is ok.
- justincormack 13y ago
  Then you can't use C libraries with it.
memracom 13y ago
If you do interoperability right, then you would use Apache Camel which interoperates effortlessly with everything including Python. The right way to interoperate between tools in different languages on different VMs, is to use something like AMQP or ZeroMQ both of which are supported in Camel and in Python. Now if you don't want to use Camel and want to build a Big Ball of Mud, that is your choice, but do not pretend that it is a best practice in the 21st century. The standards for software engineering have moved on.
- w0utert 13y ago
  >> Now if you don't want to use Camel and want to build a Big Ball of Mud, that is your choice, but do not pretend that it is a best practice in the 21st century. The standards for software engineering have moved on. I don't even understand what you are saying here. Are you implying that if I have a Python application and a Java library that solves some very specific part of what the application does (say, applying some very complex algorithm to a few numbers, or decode some arcane undocumented file format), that I should use something that sells itself as: Apache Camel ™ is a versatile open-source integration framework based on known Enterprise Integration Patterns. Camel empowers you to define routing and mediation rules in a variety of domain-specific languages, including a Java-based Fluent API, Spring or Blueprint XML Configuration files, and a Scala DSL. This means you get smart completion of routing rules in your IDE, whether in a Java, Scala or XML editor. Because 'the standards of software engineering have moved on'? Not everyone is building large-scale enterprise software running on clouds of servers or whatever you have in mind. I can make up a million examples of pieces of software that perform only one single one-shot task (like a command line script) that may want to call out to some external library that implements some part of what the script is supposed to solve, and for those kind of applications, 'the standards of software engineering' should not have to dictate I have to use message queues or a versatile open-source integration framework based on known Enterprise Integration Patterns, amirite? If that library I need to call is written in Java and I need to call it from Python or some other non-JVM language (or even C/C++ because JNI is a pain in the ass as well), I'm SOL :-S

sannysanoff 13y ago

java and C are strong in different areas. I would rather say that choice of C libraries for enterprise or just for any useful web backend is poorer than for java ;)

a8da6b0c91d 13y ago
The only thing Java is tier one for is shoveling around XML/HTML and talking to databases. As soon as you leave that CRUD territory and need to work more seriously with algorithms or have high performance requirements, the available stuff is second tier. Off the top of my head, consider computational geometry. CGAL and boost.geometry are amazing. JTS is very slow and missing a lot. It's the same thing over and over with many sorts of libraries.
- pjmlp 13y ago
  So why are the banks moving to Java and .NET for real time transactions? https://github.com/LMAX-Exchange/disruptor https://github.com/LMAX-Exchange/disruptor
- profquail 13y ago
  Well-designed libraries usually trump poorly-designed libraries, performance-wise, regardless of which language they're implemented in. C++ isn't a magic bullet; it's plenty easy to write bloated, poorly-performing software in C++, just as it is in Java, C#, Ruby, etc. Here's just one counterexample to your claims: http://stackoverflow.com/questions/4257659/c-sharp-versus-c-performance/19505716#19505716 http://stackoverflow.com/questions/4257659/c-sharp-versus-c-...

guard-of-terra 13y ago

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!
- 13y ago

tspike 13y ago

Additionally, Unicode is a nightmare in Java.

pjmlp 13y ago
Did you ever tried it in C and C++?
thousande 13y ago
Mozilla's HTML5 parser is written in Java. One of the reasons java was chosen was the unicode support [1] The Java code is converted to C++ in build time I think [2] [1] https://news.ycombinator.com/item?id=6204760 https://news.ycombinator.com/item?id=6204760 [2] http://ejohn.org/blog/html-5-parsing/ http://ejohn.org/blog/html-5-parsing/

pjmlp 13y ago

> The best and most widely used libraries and interfaces for a given problem always seem to be C++ or C. Where are the enterprise C and C++ libraries and server stacks? The enterprise is all about Java and .NET nowadays.

danieldk 13y ago

The best and most widely used libraries and interfaces for a given problem always seem to be C++ or C. I think it differs hugely per case. E.g. there are not great C++ or C libraries that provide functionality of Akka, Guava, or Java persistence. On the other hand, nothing in Java-land beats Qt, Cocoa, or Eigen. But I agree on interoperability. Interoperability within JVM-land is pretty great. But it is far easier to write a good binding for a C library in e.g. Python, Ruby, Go, or Haskell, than it is in JNI.