Option to filter out libjvm.so from output .jars

[mboes]

The JAR's produced by jarify (and by extension sparkle) are always large. Even for a small "hello world" app, on NixOS one can count on an output size of about 32 MB. Upon closer inspection, it turns out that the bulk of the space comes from stuff that could be excluded.

Here's what I did:

$ stack exec jarify <some-haskell-exe-that-uses-jni>
$ unzip <some-haskell-exe-that-uses-jni>.jar
$ unzip jarify-app.zip
$ du -sh * | sort -h
[...]
5,2M    libgtk-x11-2.0.so.0
11M libHSbase-4.9.1.0-ghc8.0.2.so
15M libjvm.so
31M jarify-app.zip

So about a third of the space is eaten up by base. Not much we can do about that. libjvm eats up another big chunk. But why are we including libjvm.so in the packaging? Surely that's already provided by the JVM instance that loads the JAR.

Moreover, it turns out that libjvm.so is but the tip of the iceberg. Notice the libgtk above. lddtree from the pax-utils package tells us where it comes from: it's a transitive dependency of libjvm.so. As is in fact libX11.so and a whole host of other graphical libs.

So if we cut out libjvm.so and all dependencies, we could significantly reduce the number of libs in the JAR, presumably reduce the packaging time, and get a 3x reduction in size in this particular example.

cc @robinbb

[mboes]

So if we cut out libjvm.so and all dependencies, we could significantly reduce the number of libs in the JAR, presumably reduce the packaging time, and get a 3x reduction in size in this particular example.

Urgh... was comparing apples and oranges: compressed and uncompressed sizes. The total uncompressed size is 116MB, of which only about 64MB are Haskell code. The bulk of the rest is libjvm.so dependencies.

[facundominguez]

Probably this should be generalized to any libraries listed by the user.

With sparkle we are sometimes excluding various system libraries from the zip. e.g. libdl.so, libc.so, libpthread.so, libm.so, libz.so, libstdc++.so, libgcc_s.so.