Java Packaging Guidelines - .so in JARs?

[Alex Scheel]

Per $SUBJ, I was looking for guidance from the Java community about
embedding .so files within JARs.

I found these docs:

https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/#_applicab...

Which seem to have conflicting commentary on this:

 - A Java package uses JNI if it contains a .so file. Note that this file can
   be embedded within JAR files themselves.
 - JNI shared objects MUST be placed in %{_libdir}/%{name}

As long as the JAR for the application is played in %{_libdir}/%{name}/%{name}.jar,
does this mean that the .so can be placed within the JAR?


The benefit to .so-in-JAR is that the JAR always knows where to find the .so,
even if the user installs multiple versions of the same package, or, worse,
copies JARs from different systems around.


Wondering what the community's thoughts are,

Alex

[Andrew Haley]

On 2/12/20 8:57 PM, Alex Scheel wrote:
>  Per $SUBJ, I was looking for guidance from the Java community about
>  embedding .so files within JARs.
>
>  I found these docs:
>
>  https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/#_applicab...
>
>  Which seem to have conflicting commentary on this:
>
>   - A Java package uses JNI if it contains a .so file. Note that this file can
>     be embedded within JAR files themselves. 
 - JAR files using JNI or containing JNI shared objects themselves
   MUST be placed in %{_jnidir} and MAY be symlinked to
   %{_libdir}/%{name}.

>   - JNI shared objects MUST be placed in %{_libdir}/%{name}
>
>  As long as the JAR for the application is played in
>  %{_libdir}/%{name}/%{name}.jar, does this mean that the .so can be
>  placed within the JAR? 
Yes. This is explicitly permitted by the rule above.

>  The benefit to .so-in-JAR is that the JAR always knows where to find
>  the .so, even if the user installs multiple versions of the same
>  package, or, worse, copies JARs from different systems around.
>
>
>  Wondering what the community's thoughts are, 
Hidden shared objects have to be unpacked somewhere in order to be
used. If they're unpacked somewhere private they won't be shared. And
the runtime code will need to find the correct shared object, the one
relevant to the machine in use. I've seen this break on new
architectures.

So, generally it's not such a great idea to hide shared objects in
JARS, but it's not absolutely forbidden because we know that sometimes
this is what Java programs do and we don't want to burden packagers
unduly.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671