[zeromq-dev] jzmq: embedding native library in JAR

[Karl Ostendorf]

Hi Armando,

By default only the JNI binary for the development platform is
included in the JAR. Additional binaries must be added manually with
zip without maven.

@Gonzalo, perhaps it would be a good idea to allow embedded JNI
binaries as an optional action rather than a mandatory step for the
Maven build. Then we can keep the current behavior of using
java.library.path but allow using an embedded binary if the extra step
has been taken to add one to the JAR. I can reduce the scope of my
pull request to only touch the static initializer in ZMQ.java as well
as App.java to list the arch/os of the current platform should one
want to know where to embed a library.

It would be cool to build a jzmq.jar with binaries for multiple
platforms though. If we could find a place to host it and agree on the
platforms to include that would make it very easy to use.

Regards.

Karl Ostendorf
http://ostendorf.com



On Sun, May 29, 2011 at 23:48, Armando Singer <armando.singer at gmail.com> wrote:
> On May 27, 2011, at 2:26 PM, Karl Ostendorf wrote:
>> Hello,
>>
>> We're soliciting feedback for a proposed change to jzmq. Please read
>> below and vote. A decision will be made after one week.
>
> Hi Karl,
>
> 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
> better!
>
> Cheers,
> Armando
>
>>
>> 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
>> platform.
>>
>> Finally, this is only a change in the packaging of the artifacts, the
>> API remains unchanged. Any feedback would be welcome.
>>
>> Regards.
>>
>> Karl Ostendorf
>> http://ostendorf.com
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>