Library size increased 230% from v3 to v4

[bdw429s]

The system tray 3.17 dependency was only 3.8 megs in size, but 4.2 has jumped to 9 Megs. This is a pretty big jump and adds a noticeable amount to my tool that bundles System tray. Is there a way to trim down what is bundled? For example, I'd like to not need to pack in the Kotlin runtime just for the system tray library to work.

[dorkbox]

All of the dependencies are either kotlin, or getting changed to kotlin

[dorkbox]

I wouldn't recommend trying to strip the kotlin runtime.

If you don't use any of the workarounds, you can probably remove javassist.

[bdw429s]

So, is there a plan to shrink the size back down to 3.x measurements? It's not the worst thing in the world, I've just always tried to reign in unecessary bloat since this is an embedded tool.

[dorkbox]

The only thing I can think of is using ProGuard to strip out unused classes, which will make the jar super tiny. Don't do this for the SystemTray, but for it's dependencies. There's also something called SlimJar, and you can even setup downloading the dependencies on download (java can run jars from an URL, in addition to from a file)

[dorkbox]

So, is there a plan to shrink the size back down to 3.x measurements? It's not the worst thing in the world, I've just always tried to reign in unecessary bloat since this is an embedded tool.

Once the system tray is using Kotlin, there is a LOT of code that can safely be culled. Exactly how much? I cannot say, but my other projects saw a reduction by 40% or so

[dorkbox]

This conversation is continued in issue #184.

[bdw429s]

Once the system tray is using Kotlin, there is a LOT of code that can safely be culled. Exactly how much? I cannot say, but my other projects saw a reduction by 40% or so

The irony here is that the Kotlin runtimes seem on their own to be nearly as large as the entire SystemTray library before it used Kotlin. So here's hoping that Kotlin replaces 99% of it :)

[dorkbox]

You're right, the topics are divergent.

Have you thought about running pack200 on the jars?

edit: jar's don't compress that well with standard zip/lz/etc algos. Pack200 is the algo to compress them. The JVM should auto-decompress them when loading them.

[bdw429s]

pack200

Yes, I used Pack200 for years and had good results, but I was forced to remove it when Java 14 came out and Pack200 was removed. Oracle made that decision for me :/

https://openjdk.org/jeps/367

It's frustrating because they largely cite jlink and jpackage as the replacement but that doesn't do anything for me for the reasons I laid out in the other ticket. Oracle basically removed a feature that was working perfectly fine on the assumption that my deployments look like something they've envisioned based on native Java apps. (See the "Risks and Assumptions" section in the above linked article)

I know in the world of fast internet, a few megs isn't a lot to download, but I've long since been stymied by how difficult it is to get a Java tool anywhere in the vicinity of things like the Go runtime. Pretty much all Go CLI tools are like 8 MB AND bundle the entire runtime. Heck, an entire GoLang docker image/website can be like 10 Megs. My CLI tool is an 80 MB binary WITHOUT a JRE (now that Pack200 is no longer viable) which extracts to over 300 MB on disk thanks to the glorious excess of OSGI and dozens of modules my user "might need". It's a battle to keep a dockized CFML app under 600 Megs if using Adobe ColdFusion with many of them ringing in our a Gig if no care is taken to shrink them. (My CLI tool that bundles SystemTray is the base for a number of CF Docker images)
Nearly all of Oracle's new tools don't really work in my world when everything is loaded at runtime via OSGI and dynamic URL classloaders/JIT compilation. At the end of the day 5 more Megs from SystemTray won't be the straw that breaks the camels back, but I do try to keep an eye on everything that grows.

[dorkbox]

oh wow.

[dorkbox]

just had an idea.

Strip out the classfile debug info to get a smaller file size.

[dorkbox]

I’m going to close this issue - however the last thought that comes to mind, is that you can safely exclude the JNA specific bindings for os/arch combinations that you know you will not be used (for example, as this in going to run in docker, it’s likely only linux 32/64/arm/aarch64 will be used, it’s unlikely that solaris will be used). This will shave down quite a bit of space.

[bdw429s]

you can safely exclude the JNA specific bindings for os/arch combinations that you know you will not be used

My tool is bundled up as a stand-alone executable that's made to be run on any OS with any CPU architecture as a general purpose development tool and server, so unfortunately there's really nothing I'd be able to safely eliminate.