Bug 64 – better JNI handling

Bug 64 - better JNI handling


Summary:	better JNI handling

Status:	RESOLVED FIXED

Product:	Fiji
Classification:	Unclassified
Component:	Debian Packages
Version:	unspecified
Hardware:	PC Linux

Importance:	P2 normal
Assigned To:	Mark Longair

URL:

Depends on:
Blocks:

Reported:	2009-07-07 21:38 CDT by Johan Henriksson
Modified:	2011-03-23 15:56 CDT
CC List:	0 users

See Also:

Description Johan Henriksson 2009-07-07 21:38:31 CDT

it must be possible for other packages to add JNI directories. this is a proposed method used with the debian imagej package together with micromanager-ij:

in
/usr/share/imagej/jni/
there is one file for every JNI-directory to include. these are combined
like this when launching imagej:

jni=-Djava.library.path=$(cat /usr/share/imagej/jni/* | tr '\n' ':')

to get the flag with all the paths. this way, additional JNI-directories can be added in other packages without modifying the imagej package.

Comment 1 Johannes Schindelin 2009-07-09 18:45:38 CDT

We cannot do it that way; not only do we support other operating systems, we also support other distributions.

Comment 2 Johan Henriksson 2009-07-09 22:25:34 CDT

(In reply to comment #1)
> We cannot do it that way; not only do we support other operating systems, we
> also support other distributions.
> 

different distributions and hence package systems call for different solutions. the proper solution is to only have one package system and one distribution but that's beyond us :(

Comment 3 Mark Longair 2009-07-10 14:47:51 CDT

I'm happy to add something similar to the Debian / Ubuntu package, though,
since /usr/bin/fiji is just a shell script.  There are a few other issues
to sort out before I can produce new packages, but expect this to happen
shortly...

Comment 4 Johannes Schindelin 2009-11-12 02:17:24 CST

Blindly adding all paths in $DIR/jni/ slams the door regarding fiji-all.  Besides, we are competent to come up with a proper solution.

And the solution is definitely not thinking about a unified packaging system; in addition of ignoring other platforms in a rather blatant way, it also ignores users' needs.  But I probably misunderstood, and this suggstion was meant as a (not particularly funny) joke.

Comment 5 Mark Longair 2009-11-16 19:37:53 CST

(In reply to comment #4)
> Blindly adding all paths in $DIR/jni/ slams the door regarding fiji-all. 
> Besides, we are competent to come up with a proper solution.

What is your preferred solution?  The source and binary Debian packages
already have to differ from the standard Fiji source tree in many ways
in order to conform to packaging policy, so I don't see that there's a big
problem with this one-line change to make it easier for people to build
other Debian packages that depend on fiji.  (Obviously I'm not suggesting 
that this change be included in fiji master.)  If you have a better solution
in mind that would work across all platforms, that would be great, of course.

Comment 6 Johannes Schindelin 2010-03-11 13:51:51 CST

FWIW I have started what I consider a proper fix in the 'native-libs' branch of fiji.git, where the Fiji launcher inspects the available files in $FIJI_ROOT/lib/ and its subdirectories recursively, and adds all the directories in which libraries for the _current_ platform are found.

As you can see, I am not a particular fan of the name "jni/", because it is actively wrong for the 3rd party libraries we need to ship, too. So let's take "lib/".

Comment 7 Johannes Schindelin 2011-03-23 15:56:36 CDT

This has been addressed in the highly successful ImageJ2 hackathon in Madison. Please see the release notes: http://pacific.mpi-cbg.de/cgi-bin/gitweb.cgi?p=fiji.git;a=blob;f=RELEASE-NOTES;h=fc55cd6a57c928772eb21e5b7bfe387bfcd4b87c;hb=9f715add85081e65e1471469337086e1c132b673#l384 (there will be proper documentation on the Fiji Wiki, once I find the time to add it; it will be part of http://pacific.mpi-cbg.de/Fiji_Build_System).