[PATCH] Shrink .jar/.zip by a further 3-5%

[Stereo]

​https://github.com/JOSM/josm/pull/83 does it for macOS; other platforms could be done with the same utility.

[gaben]

Hmm, does it make sense for a jar file? I mean, it is read and costs extra CPU cycles.

[taylor.smock]

I've briefly looked at this in the past, and I haven't felt that it was worth shrinking the jar/zip by 3-5% by adding another optimizer (we already run imageoptim on the images on Mac). At the upper end, we would save ~3.75 mb on a 75 mb download, which people should download once a month or so. If we were running into bandwidth limits, I'd probably change my tune, but I haven't heard anything about that (which doesn't mean anything).

Yes, we try to keep our size down (the jar file by itself is 15.5 mb, and we've written code when libraries providing that functionality were too large), but I feel that it isn't worth it to add another moving part to the release process.

Size (bytes)	Compression	File	Version
15806411	93.5%	josm-custom-optimized.advcomp.jar	r18502-custom
16273803	96.3%	josm-tested.jar	r18463
16286932	96.3%	josm-latest.jar	r18502
16713619	98.9%	josm-custom-optimized.jar	r18502-custom
16898447	100%	josm-custom.jar	r18502-custom

So ant dist-optimized doesn't really decrease the size of the jar file, while advzip -z -4 does trim a bit more than 1 MB.

FTR: two images (12 MP, ~3 mb each) is more than the amount of space we would save by using advzip on the downloads with the JRE bundled in. So I don't know if it is "worth it" from an end user perspective either.

I'll leave this open for other maintainers to give their two cents.

[Stereo]

Dirk, before closing issues with a patch with no comment like that, do you wonder how that might come across to the people who have offered their free time for JOSM?

[stoecker]

What should the comment be? Taylor's extensive analysis of 2 years ago still stands and nothing new has been said, so that I now close the ticket? I think that's obvious.

[taylor.smock]

Today, here are some stats from the jar:

Size (bytes)	Compression	File	Version
7707560	44.5%	josm-custom.no-deps.no-resources.jar	r18990-custom
15725661	90.8%	josm-custom.no-deps.jar	r18990-custom
16161960	93.3%	josm-custom-optimized.advcomp.jar	r18990-custom
16856669	97.3%	josm-tested.jar	r18969
16865073	97.3%	josm-latest.jar	r18990
17115982	98.8%	josm-custom-optimized.jar	r18990-custom
17322427	100%	josm-custom.jar	r18990-custom

The compression difference with respect to the "official" jars is 95.8% (-694709 bytes or -0.66 MiB). This is for something that most users will be downloading once a month.

With all that said, we could decrease the size of the jar for webstart users by extracting the dependencies and adding them to the JNLP files (additional <jar/> stanzas). We'll probably want to build a jar without dependencies once we add a module-info.java file, and we should be able to modify the jpackage scripts to generate the appropriate installers. We could even extract the resources to their own jar(s) (I'm pretty certain this would work). And if we ever modularize JOSM, the user could only redownload the changed modules instead of the entire application.

In short, the best way to decrease the amount of data downloaded by users would be to push those users towards the JNLP, flatpak, or debian repos and have multiple jar resources. This would require quite a few more "moving parts". So I'm not certain it is worth it, especially since most users are going to be downloading background imagery and OSM data to make JOSM useful anyway.

EDIT: There is a plugin for ​maven that will autogenerate the appropriate JNLP files apparently.

[stoecker]

NOTE: We have a strip feature which removes unneeded translations and the signature information for the supplied jars:

Example: Current tested version:

full	16856669	100%
de-only	12997770	77%
de-only-unsigned	12349626	73%

Nearly nobody uses this. As you already wrote: A few % is not helpful when it makes the build process more complicated.

Same for modules. It makes this much more complex and will produce additional errors and people simply don't care about such size differences anymore.