Hacker News Reader

Comment by a8da6b0c91d | Hacker News Reader

> 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.

View on HN

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.

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.

For enterprise applications usually you would use REST. And that is pretty easy, almost automatic.

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?

There's no need to interface cpython and java. Looks like jython is already faster than cpython, so just use it, interface is ok.

Then you can't use C libraries with it.

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.

>> 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

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.

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.

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

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.

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!

"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!

Additionally, Unicode is a nightmare in Java.

Did you ever tried it in C and C++?

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

[2] http://ejohn.org/blog/html-5-parsing/

> 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.

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 ;)

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.

So why are the banks moving to Java and .NET for real time transactions?

https://github.com/LMAX-Exchange/disruptor

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-...

Reply on news.ycombinator.com