Reaching out to people who now how to shrink non-Android JARs after the fact (this is for Fabric-modded Minecraft).
This is for containerization. I've done the low-hanging fruit (small base images, multi-stage build, small JVM with jlink), and I'm down to an image size of ca 550 MiB. The JARs in the image are the biggest size contributor, and I don't know what to do further. Any help is appreciated :)
@nausicaea JARs are ZIP files in disguise. You could try increasing the compression level on them, assuming the Java tools allow for that. Alternatively the same could be done with a standard ZIP tool (unpack, then repack) provided you give the result the right extension afterwards (and then double-check Minecraft/Java accepts the new file).
550MiB is huge either way. Most mods run to less than a hundredth of that. Is there something massive that doesn't need to be there?
@lagomoof Thanks for your tip on recompressing the JARs. I had thought of that, but I was hesitant to modify them.
I'm thinking aloud for a bit:
The size contributors in the image are:
- 9 MiB Alpine base image
- 49 MiB Minecraft dependencies (JARs) in ./libraries
- 18 MiB Minecraft server JAR
- 17 MiB Custom datapacks (11)
- 38 MiB Custom mods (37)
- 92 MiB Fabric cache
- 22 MiB Fabric launcher, Opentelemetry and Jolokia JARs
- 60 MiB JDK
This sums up to 305 MiB, which matches approx. what `dive` reports about the image. Docker however reports an image size of 574 MiB, so I don't know where that huge discrepancy stems from.
My Docker image pulls in all the required JARs during the image build. Maybe that's something I could defer to container startup. Concretely, I should probably not store the fabric cache, the server JAR and dependencies in the image. Maybe, I can also fetch the Mods/Datapacks at startup, although that would require hitting Modrinth every time a container starts.
nausicaea
lagomoof