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.
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
