JeroMQ: Native Java implementation of ZeroMQ | Hacker News Reader

JeroMQ: Native Java implementation of ZeroMQ

github.com

68 pointsiamtechaddict22 comments

What was wrong with ZeroMQ that a port to Java fixes?

Enterprise ready.

Platform-specific native libraries are annoying.

If your code runs on the JVM, it should run on, well, the JVM. It shouldn't run partly on the JVM and partly on the host machine, since that breaks the purpose of using the JVM.

JVM is a platform.

I don't get this logic. Native libraries are annoying? You can run zeromq (and most, what you would probably call "native," libraries) on almost any platform. Just change your compiler target. The JVM? Not so much. Try running that on an ipod and see where that gets you. Or many embedded devices for that matter.

Not to mention you need the JVM installed too and believe me when I say there are plenty of us who are sick of the JVM and its incessant auto-updater.

> Try running that on an ipod and see where that gets you.

Easy, just use RoboVM or Aicas

> Or many embedded devices for that matter.

There are lots of commercial JDKs that compile directly to native code.

Most of the embedded devices that cannot be targeted by Java wouldn't support running something like ZeroMQ anyway.

You do realize that nobody will write an application in Java for the purpose of using ZeroMQ?

Instead they have an application already written in Java, or some other compelling reason to write the application in Java. Given that there is already a dependency on the JVM, it is silly to add another dependency on a particular host platform. It is silly to force the compile process to become aware of the host platform, when it otherwise wouldn't need to be.

Is it just me, or do these performance numbers lead anyone else to believe that JeroMQ is more performant than ZeroMQ? I can probably believe that running on a modern JVM would buy you a little bit of an advantage, but these numbers seem like JeroMQ is roughly 20% faster. (I'm reading lower latency and higher 100K msgs/sec)

JNI is not considered to be a performant solution. Copying bytes across the jvm/c boundary is expensive. Depending on how the bindings are implemented (direct vs undirect ByteBuffers for example) you could easily see drastic differences in performance at high through put.

The interesting thing was the comparison looked like pure c++ vs java. GC can give you better throughput than a naive memory allocator if you are willing to deal with the unpredictable pauses.

But for a Java developer looking to make use of ZeroMQ, that comparison wouldn't make sense as they already are taking on the burden of the JVM.

One possibility is that in the JeroMQ test, they allocated enough memory for the JVM so that GC wasn't as expensive as explicitly dealing with memory management in the C++ test.

When using the native ZeroMQ from Java you summon the C hell. While the idea of JVM is that it is, well, platform independend, you have to break it in order to fit the ZeroMQ dlls. For instance, I remember that first of all you had to compile it for all platforms (Windows, Linux), then ensure the 32/64bit compatibility, then when building you have to keep track of it when preparing your releases. Having JeroMQ jar is just making all those problems dissapear.

Android.

Would it be reasonable to use zeromq in an app to communicate with a server?

Seems reasonable to me. Its efficient approach to throughput would be well suited to the way mobile internet works.

The JVM is an isolationist ecosystem. It does not really run non JVM code sanely, so they reinvent the world (often very well). It is a pity in many ways as it creates duplication of effort.

There is an interesting new effort to make a performant JVM ffi though https://groups.google.com/forum/#!forum/jvm-ffi

One jvm, one way to monitor it, one way to deploy it, one way to upgrade it, one way to recover it.

These are some of the things about code that stays inside the jvm bounding box that I personally find valuable. It's one of the ways we keep our operational burden down.

It's a high price, but the community has surprisingly deep solutions.

Yes, it took many years, and there are good technical reasons. Other communities rewrite everything in their language for less technically good reasons.

It divides all the code into JVM, Posix and Windows (and a few other things) that don't share ideas much; some of the better ideas get ported in one direction or the other, many do not.

used it in a project, and totally recommend it. There was no single glitch when switching from JNI-based ZeroMQ binding to the JeroMQ jar.

How is performance in comparison?

There's a performance comparison in the wiki:

https://github.com/zeromq/jeromq/wiki/Perfomance

Reply on news.ycombinator.com