Packaging JNI extensions

[Jason Felice]

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-platform and all?

Thanks

-Jason

[Philippe Guillebert]

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 library (for several platforms if you need that). Let me know if indigenous can help ;)

Hope that helps

Philippe

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Philippe

[Jason Felice]

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 also have a security race, or alternately 2) litering the /tmp/ directory with bunches of libs.  And also 3) this will hurt startup performance, which is important in my case.

This means that I would have to take on building this for all of the binary platforms, which is a chore; and (again) on the other hand, it's a chore that would allow other apps to never have to have this problem.

(Avi is a console-based editor, the JNI portion is an ncurses wrapper.)

[Fluid Dynamics]

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 copies of the program overwrite the same file (if a predictable name is used), and also have a security race, or alternately 2) litering the /tmp/ directory with bunches of libs.  And also 3) this will hurt startup performance, which is important in my case.

This means that I would have to take on building this for all of the binary platforms, which is a chore; and (again) on the other hand, it's a chore that would allow other apps to never have to have this problem.

(Avi is a console-based editor, the JNI portion is an ncurses wrapper.)

You're also likely to run afoul of host security configuration. A lot of admins/OSes don't permit extracting binaries to /tmp and running them as a lot of malware does this as a step in the infection process, first hijacking a host process such as a browser and then writing a bunch of code out to a temp file, which is then executed to perform further malicious actions or is hidden with a rootkit and added to the boot sequence.

My own machines here won't run binaries from any of the Windows temp directories, as a defense against (among other things) the nasty Cryptowall and related malware.

[Philippe Guillebert]

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.

3) If you care about startup performance, clojure on the JVM is already not really light :)

About security and execution of binaries from /tmp, I thought linking dynamic libs and executing files from /tmp were considered differently but I'm not familiar with the way Windows deals with it.

Philippe