On 8 July 2016 at 18:56, Gary Gregory <garydgreg...@gmail.com> wrote:
> On Fri, Jul 8, 2016 at 10:46 AM, Bhowmik, Bindul <bindulbhow...@gmail.com>
> wrote:
>
>> On Fri, Jul 8, 2016 at 11:37 AM, sebb <seb...@gmail.com> wrote:
>> > On 8 July 2016 at 18:31, Gary Gregory <garydgreg...@gmail.com> wrote:
>> >> On Fri, Jul 8, 2016 at 10:07 AM, Marcelo Vanzin <van...@cloudera.com>
>> wrote:
>> >>
>> >>> 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.
>>
>> One option could be to go the Eclipse way, the way they handle SWT
>> distributions which have native components[1]. Thinking more about it,
>> that might even be a better option given that the different binary
>> components may need to be built on different OSes.
>>
>> And from a consumption standpoint, if the user is using Maven, they
>> could use profiles to select the correct dependency. I have done
>> something like this for SWT on a project:
>>
>> <dependency>
>> <groupId>org.eclipse.swt</groupId>
>> <artifactId>${swt.artifact}</artifactId>
>> <version>${eclipse.swt.version}</version>
>> <scope>compile</scope>
>> </dependency>
>>
>> <profile>
>> <id>win64_x8664</id>
>> <activation>
>> <os>
>> <family>windows</family>
>> <arch>x86_64</arch>
>> </os>
>> </activation>
>> <properties>
>> <swt.artifact>swt-win32-win32-x86_64</swt.artifact>
>> </properties>
>> </profile>
>> <profile>
>> <id>linux64_x8664</id>
>> <activation>
>> <os>
>> <family>unix</family>
>> <arch>x86_64</arch>
>> </os>
>> </activation>
>> <properties>
>> <swt.artifact>swt-gtk-linux-x86_64</swt.artifact>
>> </properties>
>> </profile>
>>
>>
> Yeah, that seems like a more normal way to go.
>
> We've been making changes for 1.0 for a little while now (not _that_ long)
> but this would be a big change because the Maven coordinate business.
>
> Let's see what the rest if the community thinks.
>
> I am concerned as I've already stated as to what the current scheme means
> went Windows DLL support is done. It does not seem OK to include >1 native
> library in the jar.
Another possibility for the first release is to avoid the problem
entirely, by only releasing source.
AIUI many Linux distros rebuild from source anyway.
We would need to ensure that the build instructions are clear, and
that the code produced a sensible error message if the JNI code is not
found.
This could include a URL to the latest build instructions/FAQ (like Maven does).
But longer term it might be better to release the JNI binaries
separately from the Java binaries.
This would allow new OSes to be added without having to re-release everything.
> Gary
>
>
>> - Bindul
>>
>> [1]
>> http://download.eclipse.org/eclipse/downloads/drops4/R-4.6-201606061100/#SWT
>>
>> >>>
>> >>> 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?
>> >>>
>> >>
>> >> The JNA code is in place, it's just much slower than the JNI path.
>> >
>> > Have you managed to get it going on Windows?
>> >
>> > So far I have failed.
>> > It's tricky getting JNA to find the crypto DLL, and then it hangs for
>> > me on the ERR_load_crypto_strings() call.
>> > [Or it is so slow that it seems like it is hanging]
>> >
>> > I was able to get SSLeay_version(int type) working in a simple app
>> > that does not do the ERR_load call.
>> > But if I leave out the ERR_load from OpenSslNativeJna.java the tests
>> still hang.
>> >
>> >> Gary
>> >>
>> >>
>> >>>
>> >>> --
>> >>> Marcelo
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> >>> For additional commands, e-mail: dev-h...@commons.apache.org
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> >> Java Persistence with Hibernate, Second Edition
>> >> <http://www.manning.com/bauer3/>
>> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> >> Spring Batch in Action <http://www.manning.com/templier/>
>> >> Blog: http://garygregory.wordpress.com
>> >> Home: http://garygregory.com/
>> >> Tweet! http://twitter.com/GaryGregory
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> > For additional commands, e-mail: dev-h...@commons.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
