[fedora-java] /usr/lib/jni support in Fedora

[Florian Weimer]

On 07/29/2014 06:18 PM, David Walluck wrote:
> On 07/29/2014 11:34 AM, Omair Majid wrote:
>> If it helps, changes we manage to push into OpenJDK should show up
>> sooner or later in proprietary JDKs. That said, I agree, a scheme that
>> makes it harder to use proprietary JDKs would undo a lot of work Fedora
>> (and JPackage) have put into the Java packaging guidelines.
>
> I have to admit, I am really not following the proposed change here nor
> the reason for it.
>
> I can say that the reason for moving the jni libdir is that libraries in
> %{_libdir} are dynamically linked vs. dlopened like JNI libs are.
>
> Otherwise, %{_jnidir} has always been %{_prefix}/lib/java (even on
> 64-bit) as it was created before multiarch support. After which, I
> believe certain Linux distros may have changed it to %{_libdir}/java,
> but on Fedora it seems to be %{_prefix}/lib/java.

As far as I understand it, you are not allowed to place DSOs in 
%{_jnidir}, you have to use %{_jnidir}/%{name} instead.  So adding 
%{_jnidir} to the default search path will not help at all.

In reality, both approaches exist:

  /usr/lib/java/cvc4/libcvc4jni.so
  /usr/lib/java/cvc4/libcvc4jni.so.2
  /usr/lib/java/cvc4/libcvc4jni.so.2.0.0
  /usr/lib/java/gdal/libgdalconstjni.so
  /usr/lib/java/gdal/libgdalconstjni.so.1
  /usr/lib/java/gdal/libgdalconstjni.so.1.16.2
  /usr/lib/java/gdal/libgdalconstjni.so.1.17.1
  /usr/lib/java/gdal/libgdalconstjni.so.1.18.0
  /usr/lib/java/gdal/libgdaljni.so
  /usr/lib/java/gdal/libgdaljni.so.1
  /usr/lib/java/gdal/libgdaljni.so.1.16.2
  /usr/lib/java/gdal/libgdaljni.so.1.17.1
  /usr/lib/java/gdal/libgdaljni.so.1.18.0
  /usr/lib/java/gdal/libogrjni.so
  /usr/lib/java/gdal/libogrjni.so.1
  /usr/lib/java/gdal/libogrjni.so.1.16.2
  /usr/lib/java/gdal/libogrjni.so.1.17.1
  /usr/lib/java/gdal/libogrjni.so.1.18.0
  /usr/lib/java/gdal/libosrjni.so
  /usr/lib/java/gdal/libosrjni.so.1
  /usr/lib/java/gdal/libosrjni.so.1.16.2
  /usr/lib/java/gdal/libosrjni.so.1.17.1
  /usr/lib/java/gdal/libosrjni.so.1.18.0
  /usr/lib/java/libjnilasso.so

(This is the complete list for the current Fedoras, unless I botched 
something.)

But as there is no benefit from using the prescribed directories, the 
libraries are scattered all over the place:

  /usr/lib/accumulo/libaccumulo.so
  /usr/lib/arc/libjarc.so
  /usr/lib/bluecove/2.1.1-SNAPSHOT/libbluecove.so
  /usr/lib/bluecove/2.1.1-SNAPSHOT/libbluecove_arm.so
  /usr/lib/bluecove/2.1.1-SNAPSHOT/libbluecovez.so
  /usr/lib/bluecove/2.1.1-SNAPSHOT/libbluecovez_arm.so
  /usr/lib/bolzplatz2006/libirrlicht_wrap.so
  /usr/lib/bolzplatz2006/liblwjgl.so
  /usr/lib/brltty/libbrlapi_java.so
  /usr/lib/cvc3/libcvc3jni.so.5.0.0
 
/usr/lib/eclipse/plugins/org.eclipse.core.filesystem.linux.arm_1.4.100.v20140325-0646/os/linux/arm/libunixfile_1_0_0.so
  …
  /usr/lib/vtk/libvtkViewsInfovisJava.so
  /usr/lib/vtk/libvtkViewsJava.so.5.10.1
  /usr/lib/vtk/libvtkVolumeRenderingJava.so.5.10.1
  /usr/lib/vtk/libvtkWidgetsJava.so.5.10.1
  /usr/lib/zorba-java/libzorba_api.so
  /usr/lib/zorba-java/libzorba_api_java.so
  /usr/lib64/accumulo/libaccumulo.so
  /usr/lib64/arc/libjarc.so
  /usr/lib64/bluecove/2.1.1-SNAPSHOT/libbluecove_ppc64.so
  /usr/lib64/bluecove/2.1.1-SNAPSHOT/libbluecove_s390x.so
  /usr/lib64/bluecove/2.1.1-SNAPSHOT/libbluecove_x64.so
  …
  /usr/share/spring/AI/Interfaces/Java/0.1/libAIInterface.so

-- 
Florian Weimer / Red Hat Product Security