commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcelo Vanzin <van...@cloudera.com>
Subject Re: [CRYPTO]1.0.0 Release Plan
Date Fri, 08 Jul 2016 17:07:11 GMT
Answering based on old knowledge of this code, but I don't believe it
has changed...

On Fri, Jul 8, 2016 at 9:36 AM, Gary Gregory <garydgregory@gmail.com> wrote:
> The delivered jar file contains a native .so file, and this .so file is
> _extracted_ and _installed_ on the user's machine at runtime? See
> NativeCodeLoader.extractLibraryFile().

It's not really installed, but copied to a temp location. There might
be flags to configure a permanent location (which would bypass this
code that finds the library inside the jar), but I don't remember if
that was added to crypto.

This feature is borrowed from Snappy's java bindings, and is pretty
helpful on distributed applications where a "launcher" app starts
processes on a whole bunch of different machines (and needs these
libraries).

> Does this mean that the jar will contain all possible native formats (.so,
> .dll, what about 32 vs. 64 bit, or are we only dealing with 64 bit?) and
> extract the right one at runtime for the current platform? Seems wasteful
> in space but portable and clever.

That's the goal if multiple OSes are to be supported; I'm not sure how
easy it would be to achieve with the current build system available
(haven't really looked into it), but I have ideas of how to hack
something like that in maven (using a few separate jobs per OS + a
final job to collect everything).

I've heard comments here about using JNA, so maybe this whole
discussion will eventually become moot?

-- 
Marcelo

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message