[zeromq-dev] jzmq: embedding native library in JAR
armando.singer at gmail.com
Sun May 29 23:48:42 CEST 2011
On May 27, 2011, at 2:26 PM, Karl Ostendorf wrote:
> We're soliciting feedback for a proposed change to jzmq. Please read
> below and vote. A decision will be made after one week.
It seems like a good idea but I don't think it helps me :)
It's common to build java libs in a dev environment that's different from
production. For example, dev on windows, deploy on linux. In my case,
dev on OS X, deploy on Solaris.
There's no way I'm running maven on my production/staging nodes :) I use
the traditional method of using a release management engine for this kind
of thing. Everything is compiled and ready to go snapshotted every node.
Also, I'd want to be sure that a lib built on a different os doesn't get
inadvertently pushed to production. To the unwitting user, they're just
pushing a normal jar, but there's a sneaky arch specific lib in there. So
I guess that case should be handled gracefully, then fallback to using
java.libary.path. But maybe it's better to default to not having the arch
specific binary included, and leaving a compile option to do it so there's
no step of copying the lib, trying to load it, error handling & falling back.
However, the option of having JNI binaries for multiple platforms would be
super useful. But it seems like a pain to maintain. I wouldn't complain though.
I would definitely want OS X and Solaris x86_64 and Sparc binaries in there
and it would have to include Windows, BSD, and Linux variants as well.
That's 5 or 6 OS's, 2 or 3 compilers, and multiple architectures for each.
It would also ensure that the JNI libs are in sync, as you say.
So my vote would be: +1 if multiple binaries are in there. -1 if it puts
one binary in there by default. Neutral if it's a non-default option in
build so people can do this if they want.
Oh, and thanks for taking the time to look into making jzmq lib creation
> The change is to package the native jzmq JNI library inside the JAR
> file instead of installing it in the system alongside the zmq library.
> The slightly modified new build process would require that the JNI
> library be built before the JAR file is built. At runtime, the JNI
> library is extracted to a temp file and loaded however if the library
> is not found inside the JAR the code will revert to searching the
> java.library.path system property. This relives users of having to
> mess around with java.library.path either by setting it manually or by
> making sure that the JNI library is installed into one of the
> predefined locations. A couple other projects that use JNI do this as
> well perhaps most notably the JDBC driver for sqlite.
> Besides not having to set java.library.path the new build process also
> ensures that the JNI library remains in sync with the Java code as the
> two pieces must now be built at the same time. It also allows JARs to
> be built that contain JNI binaries for multiple platforms (they are
> stored in the JAR by arch/os). A possible drawback is that such JARs
> might not contain a binary for a user's particular platform or not be
> version compatible - a problem that might be hard to diagnose - and
> yet easy to fix by simply building it from scratch on the target
> Finally, this is only a change in the packaging of the artifacts, the
> API remains unchanged. Any feedback would be welcome.
> Karl Ostendorf
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
More information about the zeromq-dev