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 <garydgreg...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
