Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.java > #9851 > unrolled thread

Advice regarding Java packages for SimpleITK

Back to article view | Back to linux.debian.maint.java

Contents

  Advice regarding Java packages for SimpleITK Ghislain Vaillant <ghisvail@gmail.com> - 2017-08-05 10:20 +0200
    Re: Advice regarding Java packages for SimpleITK Emmanuel Bourg <ebourg@apache.org> - 2017-08-09 00:20 +0200
      Re: Advice regarding Java packages for SimpleITK Ghislain Vaillant <ghisvail@gmail.com> - 2017-08-10 11:20 +0200
        Re: Advice regarding Java packages for SimpleITK tony mancill <tmancill@debian.org> - 2017-08-10 15:10 +0200
          Re: Advice regarding Java packages for SimpleITK Emmanuel Bourg <ebourg@apache.org> - 2017-08-10 22:30 +0200
          Re: Advice regarding Java packages for SimpleITK Matthias Klose <doko@debian.org> - 2017-08-11 00:20 +0200
            Re: Advice regarding Java packages for SimpleITK tony mancill <tmancill@debian.org> - 2017-08-11 00:50 +0200
        Re: Advice regarding Java packages for SimpleITK Emmanuel Bourg <ebourg@apache.org> - 2017-08-10 22:40 +0200

#9851 — Advice regarding Java packages for SimpleITK

Dear all,

I am in the process of packaging SimpleITK [1] for Debian which provides 
several language bindings around the ITK C++ library using swig.

[1] https://github.com/SimpleITK/SimpleITK

So far, I have only taken care of the common C++ library and Python 3 
bindings, but Java is also supported and used by the ImageJ v2 stack 
optionally. Consequently, I'd like to provide an additional binary 
package for Java, and wanted to consult the team on how best to handle it.

The build system uses CMake to generate the bindings. If Java is 
enabled, the following files are generated:

/<<PKGBUILDDIR>>/SimpleITK-build/Wrapping/Java/build/javadoc/*
/<<PKGBUILDDIR>>/SimpleITK-build/Wrapping/Java/build/org/itk/simple/*class
/<<PKGBUILDDIR>>/SimpleITK-build/Wrapping/Java/lib/libSimpleITKJava.so
/<<PKGBUILDDIR>>/SimpleITK-build/Wrapping/Java/org/itk/simple/*.java
/<<PKGBUILDDIR>>/SimpleITK-build/Wrapping/Java/simpleitk-1.0.1.jar
/<<PKGBUILDDIR>>/SimpleITK-build/Wrapping/Java/simpleitk-javadoc-1.0.1.jar
/<<PKGBUILDDIR>>/SimpleITK-build/Wrapping/Java/simpleitk-source-1.0.1.jar

I was wondering which files should be installed (and to which location) 
to produce corresponding Java packages which are policy compliant.

Thanks in advance,
Ghis

[toc] | [next] | [standalone]

#9866

On 08/05/2017 10:16 AM, Ghislain Vaillant wrote:

> I was wondering which files should be installed (and to which location)
> to produce corresponding Java packages which are policy compliant.

Hi Ghislain,

As I understand you'll need two binary packages for the Java bindings:

* libsimpleitk-java (arch: all), with simpleitk-1.0.1.jar installed in
/usr/share/java and a versionless symlink in the same directory (I
suggest using a javahelper debian/*.jlibs file to handle this operation).

* libsimpleitk-jni (arch: any), with libSimpleITKJava.so in a multiarch
path (for example /usr/lib/x86_64-linux-gnu/jni/)

You'll have to ensure the .so file isn't included in the jar, this may
require some tweaking of the library loading code.

Emmanuel Bourg

[toc] | [prev] | [next] | [standalone]

#9869

On 08/08/17 21:56, Emmanuel Bourg wrote:
> On 08/05/2017 10:16 AM, Ghislain Vaillant wrote:
> 
>> I was wondering which files should be installed (and to which location)
>> to produce corresponding Java packages which are policy compliant.
> 
> Hi Ghislain,
> 
> As I understand you'll need two binary packages for the Java bindings:
> 
> * libsimpleitk-java (arch: all), with simpleitk-1.0.1.jar installed in
> /usr/share/java and a versionless symlink in the same directory (I
> suggest using a javahelper debian/*.jlibs file to handle this operation).

Ack, I'll look into javahelper. I have only dealt with maven-based 
packaging so far.

> * libsimpleitk-jni (arch: any), with libSimpleITKJava.so in a multiarch
> path (for example /usr/lib/x86_64-linux-gnu/jni/)

Ack.

> You'll have to ensure the .so file isn't included in the jar, this may
> require some tweaking of the library loading code.

I am not sure what you mean here, though that might be because of my 
personal ignorance of how JNI works. Could you be a bit more explicit 
please?

I have also looked at similar packages using swig to generate Java 
bindings. src:vtk6 [1] does provide separate java and jni packages as 
you are proposing, but src:gdcm [2] does not. I have got to say, I am a 
bit confused.

[1] https://packages.debian.org/source/sid/vtk6
[2] https://packages.debian.org/source/sid/gdcm

Cheers,
Ghis

[toc] | [prev] | [next] | [standalone]

#9870

[Multipart message — attachments visible in raw view] — view raw

On Thu, Aug 10, 2017 at 10:18:24AM +0100, Ghislain Vaillant wrote:
> On 08/08/17 21:56, Emmanuel Bourg wrote:
> 
> > You'll have to ensure the .so file isn't included in the jar, this may
> > require some tweaking of the library loading code.
> 
> I am not sure what you mean here, though that might be because of my
> personal ignorance of how JNI works. Could you be a bit more explicit
> please?
> 
> I have also looked at similar packages using swig to generate Java bindings.
> src:vtk6 [1] does provide separate java and jni packages as you are
> proposing, but src:gdcm [2] does not. I have got to say, I am a bit
> confused.
> 
> [1] https://packages.debian.org/source/sid/vtk6
> [2] https://packages.debian.org/source/sid/gdcm

Hi Ghis,

I took a look at gdcm and understand the source of the confusion.
Instead of building an arch:all .deb for the Java bits of the JAR and a
separate arch:$arch .deb for the native library for JNI, this package is
building an arch:$arch -java package.  From the output of debc:

libgdcm-java_2.8.2-3_amd64.deb
------------------------------
 new debian package, version 2.0.
 size 493632 bytes: control archive=791 bytes.
     696 bytes,    18 lines      control
     287 bytes,     4 lines      md5sums
 Package: libgdcm-java
 Source: gdcm
 Version: 2.8.2-3
 Architecture: amd64
 Maintainer: Debian Med Packaging Team <debian-med-packaging@lists.alioth.debian.org>
 Installed-Size: 1208
 Depends: libc6 (>= 2.14), libgcc1 (>= 1:3.0), libgdcm2.8, libstdc++6 (>= 5.2)
 Suggests: java-virtual-machine
 Section: java
 Priority: optional
 Homepage: http://gdcm.sourceforge.net/
 Description: Grassroots DICOM Java bindings
  Grassroots DiCoM is a C++ library for DICOM medical files. It is
  automatically wrapped to python/C#/Java (using swig). It supports
  RAW,JPEG (lossy/lossless),J2K,JPEG-LS, RLE and deflated.
  .
  Java bindings to the GDCM DICOM library. It allows developers to use
  GDCM from Java environment.
drwxr-xr-x root/root         0 2017-08-07 07:28 ./
drwxr-xr-x root/root         0 2017-08-07 07:28 ./usr/
drwxr-xr-x root/root         0 2017-08-07 07:28 ./usr/lib/
drwxr-xr-x root/root         0 2017-08-07 07:28 ./usr/lib/x86_64-linux-gnu/
drwxr-xr-x root/root         0 2017-08-07 07:28 ./usr/lib/x86_64-linux-gnu/jni/
-rw-r--r-- root/root    862712 2017-08-07 07:28 ./usr/lib/x86_64-linux-gnu/jni/libgdcmjni.so
drwxr-xr-x root/root         0 2017-08-07 07:28 ./usr/share/
drwxr-xr-x root/root         0 2017-08-07 07:28 ./usr/share/doc/
drwxr-xr-x root/root         0 2017-08-07 07:28 ./usr/share/doc/libgdcm-java/
-rw-r--r-- root/root      7698 2017-08-07 07:28 ./usr/share/doc/libgdcm-java/changelog.Debian.gz
-rw-r--r-- root/root     24031 2017-08-07 07:28 ./usr/share/doc/libgdcm-java/copyright
drwxr-xr-x root/root         0 2017-08-07 07:28 ./usr/share/java/
-rw-r--r-- root/root    330154 2017-08-07 07:28 ./usr/share/java/gdcm.jar


This has the result of building a separate .deb for every architecture
[0], which will function as expected up until the time that a user needs
multi-arch, at which point the libgdcm-java:amd64 and libgdcm-java:i386
(or whatever arch) packages will fail to co-install because they both
contain the same JAR file in /usr/share/java/.

That is, this approach "works" in the non-multi-arch case, but should be
avoided.

Cheers,
tony

[0] https://packages.debian.org/unstable/libgdcm-java

[toc] | [prev] | [next] | [standalone]

#9873

On 08/10/2017 03:09 PM, tony mancill wrote:

> That is, this approach "works" in the non-multi-arch case, but should be
> avoided.

It also wastes space on the Debian mirrors, since the 300ko of gdcm.jar
is duplicated in each arch specific package (19 times, so it uses 6MB
instead of 330KB).

Emmanuel Bourg

[toc] | [prev] | [next] | [standalone]

#9876

On 10.08.2017 09:09, tony mancill wrote:
>   Java bindings to the GDCM DICOM library. It allows developers to use
>   GDCM from Java environment.
> drwxr-xr-x root/root         0 2017-08-07 07:28 ./
> drwxr-xr-x root/root         0 2017-08-07 07:28 ./usr/
> drwxr-xr-x root/root         0 2017-08-07 07:28 ./usr/lib/
> drwxr-xr-x root/root         0 2017-08-07 07:28 ./usr/lib/x86_64-linux-gnu/
> drwxr-xr-x root/root         0 2017-08-07 07:28 ./usr/lib/x86_64-linux-gnu/jni/
> -rw-r--r-- root/root    862712 2017-08-07 07:28 ./usr/lib/x86_64-linux-gnu/jni/libgdcmjni.so
> drwxr-xr-x root/root         0 2017-08-07 07:28 ./usr/share/
> drwxr-xr-x root/root         0 2017-08-07 07:28 ./usr/share/doc/
> drwxr-xr-x root/root         0 2017-08-07 07:28 ./usr/share/doc/libgdcm-java/
> -rw-r--r-- root/root      7698 2017-08-07 07:28 ./usr/share/doc/libgdcm-java/changelog.Debian.gz
> -rw-r--r-- root/root     24031 2017-08-07 07:28 ./usr/share/doc/libgdcm-java/copyright
> drwxr-xr-x root/root         0 2017-08-07 07:28 ./usr/share/java/
> -rw-r--r-- root/root    330154 2017-08-07 07:28 ./usr/share/java/gdcm.jar
> 
> 
> This has the result of building a separate .deb for every architecture
> [0], which will function as expected up until the time that a user needs
> multi-arch, at which point the libgdcm-java:amd64 and libgdcm-java:i386
> (or whatever arch) packages will fail to co-install because they both
> contain the same JAR file in /usr/share/java/.

no, if the package is marked M-A: same and the gdcm.jar is bit-by-bit identical
across architectures, then the package can be installed. However I'm not sure
that we enforce such jar archives.

> That is, this approach "works" in the non-multi-arch case, but should be
> avoided.
> 
> Cheers,
> tony
> 
> [0] https://packages.debian.org/unstable/libgdcm-java
> 

[toc] | [prev] | [next] | [standalone]

#9877

On Thu, Aug 10, 2017 at 06:13:18PM -0400, Matthias Klose wrote:
> On 10.08.2017 09:09, tony mancill wrote:
> > 
> > This has the result of building a separate .deb for every architecture
> > [0], which will function as expected up until the time that a user needs
> > multi-arch, at which point the libgdcm-java:amd64 and libgdcm-java:i386
> > (or whatever arch) packages will fail to co-install because they both
> > contain the same JAR file in /usr/share/java/.
> 
> no, if the package is marked M-A: same and the gdcm.jar is bit-by-bit identical
> across architectures, then the package can be installed. However I'm not sure
> that we enforce such jar archives.

Thank you for the clarification.  However the libgdcm-java package is
*not* marked Multi-Arch: same.  I don't know if the JARs are identical
yet, but there's still the issue of duplicating the same binary again
and again in the mirrors.  So I maintain that we should avoid arch:any
-java packages unless there are other circumstances that it.

[toc] | [prev] | [next] | [standalone]

#9874

On 08/10/2017 11:18 AM, Ghislain Vaillant wrote:

> I am not sure what you mean here, though that might be because of my
> personal ignorance of how JNI works. Could you be a bit more explicit
> please?

Libraries using native code adopt various strategies to load the
external library. Sometimes the .so/.dll is provided separately from the
jar, but some libraries include it inside the jar (for example JNA does
so, the jar contains several libraries for various platforms), the
library is extracted from the classpath and copied into a temporary
directory before being loaded. If your library does so, you have to
shortcut the extraction mechanism and load directly the native library
from the filesystem (the multiarch path is already on the OpenJDK path,
so it's just a matter of calling System.loadLibrary("foo")).

Emmanuel Bourg

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.java

csiph-web