Hi
1) yes this can be an issue, but usually in a JVM context you'd rather add
threads to one JVM instead of running concurrent JVMs.
2) In the current iteration of indigenous there is a defined path for a
given JNI resource so it'll create only one file in /tmp and reuse it on
the following runs.
On Tuesday, March 24, 2015 at 1:46:23 PM UTC-4, Jason Felice wrote:
>
> I'm a little weirded out by writing binary code out of a jar to a
> temporary directory; on the other hand, this does improve distribution,
> doesn't it? I imagine all sorts of potential problems, though: 1) multiple
> copi
I'm a little weirded out by writing binary code out of a jar to a temporary
directory; on the other hand, this does improve distribution, doesn't it?
I imagine all sorts of potential problems, though: 1) multiple copies of
the program overwrite the same file (if a predictable name is used), and
als
Hi
I'm not sure what "Avi" is in this context, maybe what you're looking for
is a way to package and run native JNI code from an uberjar ? I recently
released https://github.com/pguillebert/indigenous that may help in this
purpose. You still need to find a maven artifact providing the native
libra
I would like to break the JNI part out of Avi and make it a dependency and
- hopefully - use it via maven and leiningen like any other dependency.
I've come across a bunch of ways of doing this, but they all seem somewhat
... desperate. Does anyone have an example of something that works -
multi-
